Is this a good idea for a game engine?
Author
Well I'd like to run an idea by some of you fine programmers on GDNet. My game engine calls a lua script which can create a window, bind DirectX to that window and controls the basic render loop. Like clearing the back buffer and presenting it.
I added this extra control because someone on here made me think about cut scenes and I wanted script control over the menus, not to mention I generally wanted a flexible engine. So anyways it use to load objects from a special file format I made that contains: mesh, textures, shaders, animations, script and convex meshes for the physics engine, then it would load them when the map that was loaded referenced them.
The physics engine would control the object's position and the object's script would allow the object to interact with it's environment such as a trip mine exploding when the player comes close. So now my idea is to create a scene objects in my main script which controls actor objects. All I would need to do is tell it to update and render the scene from the main script to make the engine completely modular but still offer the level of control needed for most games.
You would even be able to have more then one scene running at a time so you could render say a TV inside the game and then have a scene being rendered to that TV's screen texture.
So what I'm asking is can you think of any problems with this idea? Would it offer the level of control needed for any game?
[Edited by - EmptyVoid on October 9, 2008 6:13:59 AM]
You like almost everyone else, like myself have done thousands of times, start in the wrong end. Instead, create a game and let game engine follow, not the other way around. Not that I think you will listen...
Author
Quote:Original post by Zelcious
You like almost everyone else, like myself have done thousands of times, start in the wrong end. Instead, create a game and let game engine follow, not the other way around. Not that I think you will listen...
Well I have made games and no I wont listen! =P
Don't try to discourage me just tell me if you think the concept is good.
The reason he is trying to discourage you is because the concept is most definately not good. I swear i have seen similar posts from you in the past.
Author
Quote:Original post by Dave
The reason he is trying to discourage you is because the concept is most definately not good. I swear i have seen similar posts from you in the past.
Well then tell me whats wrong with it?
Does it work for the game you're implementing with the engine? You are implementing a game using your engine (or preferably, generalising the engine code from a game you're writing) aren't you?
From your description, I'm unclear as to how the feature works - you mention that your script creates a window, but that you can use the feature to render to an in-game TV screen, suggesting that rather than a window you might mean a viewport? Could you clarify the idea a bit further? Leave out details of how things used to work, or what you might do and just tell us what it does do as clearly as possible.
Additionally, don't aim to support any game - pick a type of game and support it well - if you aim to support everything you'll have to settle for doing a lot of things poorly or leaving a load of work to users of your engine rather than being able to focus on specific things and actually doing them well.
From your description, I'm unclear as to how the feature works - you mention that your script creates a window, but that you can use the feature to render to an in-game TV screen, suggesting that rather than a window you might mean a viewport? Could you clarify the idea a bit further? Leave out details of how things used to work, or what you might do and just tell us what it does do as clearly as possible.
Additionally, don't aim to support any game - pick a type of game and support it well - if you aim to support everything you'll have to settle for doing a lot of things poorly or leaving a load of work to users of your engine rather than being able to focus on specific things and actually doing them well.
Author
Quote:Original post by jbadams
Does it work for the game you're implementing with the engine? You are implementing a game using your engine (or preferably, generalising the engine code from a game you're writing) aren't you?
Yes.
Quote:Original post by jbadams
From your description, I'm unclear as to how the feature works - you mention that your script creates a window, but that you can use the feature to render to an in-game TV screen, suggesting that rather than a window you might mean a viewport? Could you clarify the idea a bit further? Leave out details of how things used to work, or what you might do and just tell us what it does do as clearly as possible.
The render target can be a object's texture or a window. There are two types of scripts, one that controls the main loop and another that actually controls the objects in the scene as in each object has a script that tells it what to do.
Inside the main loop is where you would render UI and you basiclly have control over everything. Inside each object's script you only have control over that object and triggers that can tell this object what to do. You can send commands to other objects that activate the triggers.
Here is a idea of how it would work in the main lua script:
SetOutputWindow(CreateWindow( "Debug", 0, 0, 640, 480 ))FullScreen(true)Scene = CreateSceneFromFile("debug.map")i=0while i==0 doDoEvents()ClearOW(0,0,1,0,0)UpdateScene(Scene)RenderSceneToOW(Scene,0,0,640,480)PresentToOW()endYou can say RenderSceneToOT to render to a object's texture.
There are commands in the main script to take control of the objects in the scene, draw bitmap text and draw 2D images.
Quote:Original post by EmptyVoid
Well I'd like to run an idea by some of you fine programmers on GDNet. My game engine calls a lua script which can create a window, bind DirectX to that window and controls the basic render loop. Like clearing the back buffer and presenting it.
You are moving low level logic into a higher level script; not a good idea! All games will have a render loop, so that is something you want to be in the C++ code. Instead, consider making higher level solutions to accomplish what you want. I.e., add the ability to add things to be rendered via the script, remove things, and even switch a "rendering" queue. That way, you can implement your cut screens and menus easily without essentially having to code C++ stuff in LUA. Instead, consider higher level functions like:
AddNewRenderQueue(name)
SetActiveRenderQueue(name)
AddObjectToRenderQueue(name, obj)
RemoveObjectFromRenderQueue(name, obj)
RemoveRenderQueue(name)
That way, your script would be doing something like:
AddNewRenderQueue(title screen)
obj = menu("data/menus/main menu")
AddObjectToRenderQueue(name, obj)
SetActiveRenderQueue(title screen)
And assuming in some menu script that is executed on an event.
if(event == New Game)
AddNewRenderQueue(level 1 load)
...
SetActiveRenderQueue(level 1 load)
Then in the script that is called when the event for loading is completed:
RemoveRenderQueue(level 1 load)
AddNewRenderQueue(level 1)
...
SetActiveRenderQueue(level 1)
And so on. That's just a pseudo code example of what I'm suggesting. The idea is though, the actual render looping takes place in the EXE where it really should go.
Next, the whole window creating and such should be in the main application as well. Instead, set the settings via your scripts. I think you are moving too much functionality into the scripting logic. It is possible to script everything into LUA, but if you are going to do that, why even use C/C++ to begin with? You should instead just be using LUA alone.
So as you continue on, you should define some base interface for the game that is common for all games. Don't design around specific features though. Abstract out the common systems that scripts need to be aware of, such as input events, window events maybe, rendering related things, etc...
Finally just consider this - all you are doing right now is making it so people have to code in LUA, not C++. If you make your modularity generic engine, you are just making less base code that has to be written, but that's just a framework. If you want an engine, you will need to target a specific genre of games, you can't suite them all.
So, identify what type of games your engine will be used for. You can't say "any" either [lol]. Consider how games such as Pong, Breakout, Tic-Tac-Toe, Pacman, Mortal Combat, Final Fantasy whatever, Diablo, Starcraft, Counter Strike, etc.. would be implemented using your engine. Obviously there is a distinction between 2D and 3D as well, games that need positional sounds and just sound, games that need physics and those that do not.
If you do not try to solve one problem well, you will end up with a solution that can't solve any problem. Think why would people want to use your engine over what is already there. Even if it was just for yourself, consider why you would want to use it over something else that is already out there, from a non-dev perspective.
Finally make sure you can defend your decisions with a convincing argument as to why you are doing things a particular way. If you can't, chances are you don't really know why you are doing something and that something could possibly be done in a better way as pointed out by whoever is critiquing your work. [wink] Good luck!
Author
Quote:Original post by Drew_BentonQuote:Original post by EmptyVoid
Well I'd like to run an idea by some of you fine programmers on GDNet. My game engine calls a lua script which can create a window, bind DirectX to that window and controls the basic render loop. Like clearing the back buffer and presenting it.
You are moving low level logic into a higher level script; not a good idea! All games will have a render loop, so that is something you want to be in the C++ code. Instead, consider making higher level solutions to accomplish what you want. I.e., add the ability to add things to be rendered via the script, remove things, and even switch a "rendering" queue. That way, you can implement your cut screens and menus easily without essentially having to code C++ stuff in LUA. Instead, consider higher level functions like:
AddNewRenderQueue(name)
SetActiveRenderQueue(name)
AddObjectToRenderQueue(name, obj)
RemoveObjectFromRenderQueue(name, obj)
RemoveRenderQueue(name)
That way, your script would be doing something like:
AddNewRenderQueue(title screen)
obj = menu("data/menus/main menu")
AddObjectToRenderQueue(name, obj)
SetActiveRenderQueue(title screen)
And assuming in some menu script that is executed on an event.
if(event == New Game)
AddNewRenderQueue(level 1 load)
...
SetActiveRenderQueue(level 1 load)
Then in the script that is called when the event for loading is completed:
RemoveRenderQueue(level 1 load)
AddNewRenderQueue(level 1)
...
SetActiveRenderQueue(level 1)
And so on. That's just a pseudo code example of what I'm suggesting. The idea is though, the actual render looping takes place in the EXE where it really should go.
Next, the whole window creating and such should be in the main application as well. Instead, set the settings via your scripts. I think you are moving too much functionality into the scripting logic. It is possible to script everything into LUA, but if you are going to do that, why even use C/C++ to begin with? You should instead just be using LUA alone.
So as you continue on, you should define some base interface for the game that is common for all games. Don't design around specific features though. Abstract out the common systems that scripts need to be aware of, such as input events, window events maybe, rendering related things, etc...
Finally just consider this - all you are doing right now is making it so people have to code in LUA, not C++. If you make your modularity generic engine, you are just making less base code that has to be written, but that's just a framework. If you want an engine, you will need to target a specific genre of games, you can't suite them all.
So, identify what type of games your engine will be used for. You can't say "any" either [lol]. Consider how games such as Pong, Breakout, Tic-Tac-Toe, Pacman, Mortal Combat, Final Fantasy whatever, Diablo, Starcraft, Counter Strike, etc.. would be implemented using your engine. Obviously there is a distinction between 2D and 3D as well, games that need positional sounds and just sound, games that need physics and those that do not.
If you do not try to solve one problem well, you will end up with a solution that can't solve any problem. Think why would people want to use your engine over what is already there. Even if it was just for yourself, consider why you would want to use it over something else that is already out there, from a non-dev perspective.
Finally make sure you can defend your decisions with a convincing argument as to why you are doing things a particular way. If you can't, chances are you don't really know why you are doing something and that something could possibly be done in a better way as pointed out by whoever is critiquing your work. [wink] Good luck!
I like the idea but it just seems like a lot of work for little if any gain. For instance when I just clear and present the screen this is my FPS:
4400 FPS(main loop in script)
4400 FPS(main loop in C++)
There is no difference and I still have not converted the script to binary. I mean I'm sure there will be a small drop in frame rate when the script is more complex but would it really even be noticeable?
The following is just opinion, and contains no 'fact' in the absolute and inarguable sense. Two things.
First, the user does not need [nor likely want] explicit control over the internal flow of your engine processes as is described here. Creating a window is one thing, but stuff like explicitly clearing the render target, or explicitly presenting the render target to the screen, are needlessly low level for a game engine's abstraction to scripting.
Secondly, you are restricting the sort of tricks you can play by allowing your user this sort of explicit control, thus implying either a lot of overhead involved in performing optimization passes on your scripts, or letting the users have their way in all cases. What I see here contained in the suggested semantics of your script is that the back buffer is cleared, THEN the scene is updated, THEN the scene is rendered, THEN it is displayed, in that specific order. Cementing yourself to an order like this means you remove a lot of the dirty tricks you can play, such as implementing a render split to take advantage of dual core systems, or virtually any other trickery behind the scenes. Maybe you have defined your scripting semantics differently, but from the looks of things, exposing this depth of control through scripting means you are submitting control of things to the user that a competent programmer could better optimize away. OR, you make your users worry about all this mess [which appears to be the route you're taking], which removes the value of using a high level and simple scripting system in the first place.
The other option of course is to just say that you will take your user's input as suggestions, and deviate where you see fit.... but that opens up a whole new can of worms with respect to the soundness of your optimizations and the effects of the optimizations on debugging.
It's unnecessary, needlessly low level, and just makes a mess of things. It also ties your hands behind your back with respect to optimization. From the way you describe your physics system interaction, which is more appropriately high level, it isn't entirely clear what level of abstraction you are using your scripting for, which presents another problem.
First, the user does not need [nor likely want] explicit control over the internal flow of your engine processes as is described here. Creating a window is one thing, but stuff like explicitly clearing the render target, or explicitly presenting the render target to the screen, are needlessly low level for a game engine's abstraction to scripting.
Secondly, you are restricting the sort of tricks you can play by allowing your user this sort of explicit control, thus implying either a lot of overhead involved in performing optimization passes on your scripts, or letting the users have their way in all cases. What I see here contained in the suggested semantics of your script is that the back buffer is cleared, THEN the scene is updated, THEN the scene is rendered, THEN it is displayed, in that specific order. Cementing yourself to an order like this means you remove a lot of the dirty tricks you can play, such as implementing a render split to take advantage of dual core systems, or virtually any other trickery behind the scenes. Maybe you have defined your scripting semantics differently, but from the looks of things, exposing this depth of control through scripting means you are submitting control of things to the user that a competent programmer could better optimize away. OR, you make your users worry about all this mess [which appears to be the route you're taking], which removes the value of using a high level and simple scripting system in the first place.
The other option of course is to just say that you will take your user's input as suggestions, and deviate where you see fit.... but that opens up a whole new can of worms with respect to the soundness of your optimizations and the effects of the optimizations on debugging.
It's unnecessary, needlessly low level, and just makes a mess of things. It also ties your hands behind your back with respect to optimization. From the way you describe your physics system interaction, which is more appropriately high level, it isn't entirely clear what level of abstraction you are using your scripting for, which presents another problem.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement