Page 1 of 1
Is this a good idea for a general purpose game engine?
Posted: Thu Oct 30, 2008 6:15 am
by unholysavagery
Let me start by explaining how objects are created, I have a max script exporter that exports the mesh, bones, collision data, animations, textures, shaders, and a lua script out to a single file that we will call an object.
First the engine loads a lua script that creates a window then creates a render target from the window and you can add objects to the render target. The render target acts as a scene in which you can drop objects in or load them from a map and it will all be controlled by the physics library and the lua script that it was exported with. Then they are rendered to the render target, you can even create a render target from a texture.
To decrease scripting overhead I am doing everything on events. Now I'll show you a sample of the lua script to help you understand better:
function On_Start()
RenderTarget = CreateRTFromWindow( CreateWindow( "Debug", 0, 0, 640, 480, "Debug.ico" ) )
Actor = CreateActor( RenderTarget, "Data/Objects/female.eo", Translate( 0, 0, 0 ) )
end
function On_WindowClose(Window)
Exit()
end
function On_KeyEvent(key)
if key == 27 then
Exit()
end
end
Also I should add that objects are loaded when they are referenced and unloaded when they are no longer referenced, for instance if you remove a actor that's the only one referencing that object then the object will be released.
What do you think about this idea and should I change anything about it?
Re: Is this a good idea for a general purpose game engine?
Posted: Thu Oct 30, 2008 9:24 am
by Falco Girgis
In my own personal, humble opinion, it sounds like win. I would tap that.
Re: Is this a good idea for a general purpose game engine?
Posted: Thu Oct 30, 2008 11:33 am
by M_D_K
Personally I try to keep Render functions and window creation out of Lua. Its the engines job to do. I use config files for window creation. Actors can be created in scripts or engine side, personally(again) i create my actors engine side and the lua script only handles how that object will behave(movement, speed etc.)
One thing though I wouldn't give the scripts the ability to kill the app(especially if the scripts are exposed to the end user)
Other than what i said its a good way to go. I like the way you handle the objects sort of a mark and sweep in the object manager cool
Re: Is this a good idea for a general purpose game engine?
Posted: Thu Oct 30, 2008 11:49 am
by Falco Girgis
Yeah, that's something that I couldn't really evaluate. What is your goal here? Are you trying to make an engine that, once compiled, is completely Lua driven?
The way it looks is that you're making almost an entire game library/engine where the entire game is written in Lua. I'm not saying that this is a bad thing at all, on the contrary, that's pretty kick ass. It's like a low-level game library specifically for Lua programmers.
I'm just trying to understand how much you're trying to delegate to Lua here. For example, our engine is still going to be that of a 2D RPG, despite the special priveleges that Lua gets. Is yours completely general purpose?
edit: the topic title says general purpose. I'm a dumbass, haha.
edit: I'm curious as to how the Lua scripter is going to be creating these triggered events.
Re: Is this a good idea for a general purpose game engine?
Posted: Thu Oct 30, 2008 12:45 pm
by M_D_K
GyroVorbis wrote:edit: the topic title says general purpose. I'm a dumbass, haha.
I totally missed that. I know that an App for the PSP called LuaPlayer does that it just provides things like draw functions, access to wifi, input all that stuff. Then all you gotta do is write a script.
http://www.luaplayer.org/ <-- open source so people can learn
Re: Is this a good idea for a general purpose game engine?
Posted: Thu Oct 30, 2008 1:00 pm
by Falco Girgis
M_D_K wrote:GyroVorbis wrote:edit: the topic title says general purpose. I'm a dumbass, haha.
I totally missed that. I know that an App for the PSP called LuaPlayer does that it just provides things like draw functions, access to wifi, input all that stuff. Then all you gotta do is write a script.
http://www.luaplayer.org/ <-- open source so people can learn
That's really badass. I think there's some sort of Dreamcast equivalent as well.
It looks to me like that's almost what he's doing here (not sure if it's intentional or not). He's making one hella powerful Lua system regardless.
Re: Is this a good idea for a general purpose game engine?
Posted: Thu Oct 30, 2008 1:52 pm
by M_D_K
totally! I'd use that engine if I didn't love C++ so much
Re: Is this a good idea for a general purpose game engine?
Posted: Thu Oct 30, 2008 2:25 pm
by unholysavagery
M_D_K wrote:Personally I try to keep Render functions and window creation out of Lua. Its the engines job to do. I use config files for window creation. Actors can be created in scripts or engine side, personally(again) i create my actors engine side and the lua script only handles how that object will behave(movement, speed etc.)
One thing though I wouldn't give the scripts the ability to kill the app(especially if the scripts are exposed to the end user)
Other than what i said its a good way to go. I like the way you handle the objects sort of a mark and sweep in the object manager cool
Actually I gave it control over the windows so you can create multiple windows, this is so you can close windows and still have the application running. I even have input functions being checked on a hidden window so it's independent of if you have a window up or not, so you could even make a keyboard spying program with it. lol
Re: Is this a good idea for a general purpose game engine?
Posted: Thu Oct 30, 2008 2:30 pm
by unholysavagery
GyroVorbis wrote:edit: I'm curious as to how the Lua scripter is going to be creating these triggered events.
It's already doing almost everything I explained and this is how it calls the trigger events:
luaL_dofile(g_Lua, "default.lua");
lua_getfield(g_Lua, LUA_GLOBALSINDEX, "On_Start");
if(lua_isfunction(g_Lua, -1)) lua_call(g_Lua, 0, 0);
lua_settop(g_Lua, 0);
Basically just runs the script once and then calls the functions from the stack when the event happens.