GraphicsDevice = GetGraphicsDevice("OpenGL");
while(GraphicsDevice->Active())
{
GraphicsDevice->Clear();
GraphicsDevice->Draw();
GraphicsDevice->End();
}
How should a game engine work?
Author
Hello everyone.
This is something that i alone just cant figure out (yes, i'm THAT dumb).
I've been working on a game engine for the past 2 years and about 3 months, but i keep failing at the most critical point: How should the user use the game engine?
So let's say i've got some fancy-pants engine done, it's working well, but now it's time to give access to the users of the engine. What should i do? Should i allow the user to do things like:
Or should i do something different? How exactly should a game engine give access to it's users for the creation of games?
Sorry if this sounds like a stupid question, but i'm having quite a hard time thinking of a decent answer...
Thank you for your time regarding this message, and have a nice day!
I think this is a classic example of why you should have spent the last 2 years writing games, not an engine.
If you had you would know how the pieces of a game fit together and thusly how to extract bits to form an 'engine'.
If you had you would know how the pieces of a game fit together and thusly how to extract bits to form an 'engine'.
You should come up with a logical and consistent api. I would look at how the other game engines do it to get an idea(ogre,crystal space etc.) Though I wouldn't copy it whole cloth because then what is the point of using yours?
Author
Phantom, i did make games, my problem is (i hate it when i cant explain myself in my first post) that i want to make it "so easy to use" that i end up messing up in the end.
I've been able to make simple first person shooters, "online games" (more like online worlds), "demos", and other things, but my problem is that i try to make it "so very easy" that i end up with no idea on what to do.
But i think i should just give the user access to the code i myself use when making games, do you think that's the way to go?
I've been able to make simple first person shooters, "online games" (more like online worlds), "demos", and other things, but my problem is that i try to make it "so very easy" that i end up with no idea on what to do.
But i think i should just give the user access to the code i myself use when making games, do you think that's the way to go?
Quote:Original post by stonemetalNever mind the fact that copying code from an open source project and making out like it is yours would be illegal :-)
You should come up with a logical and consistent api. I would look at how the other game engines do it to get an idea(ogre,crystal space etc.) Though I wouldn't copy it whole cloth because then what is the point of using yours?
Ok here's a few tips:
1. Never over simplify. Making games is technical, you should allow the user to do technical things when he needs to.
2. Make your interfaces clean, intuitive, logical and most of all, comment everything.
3. Do the basics well. Memory management, error reporting, helper utilities / etc should all be perfect.
4. Dont kid yourself, this engine is probably mostly a learning tool, but make games alongside the development of the engine. It will help you learn how it needs to work, figure out what the missing features are, and make it perfect!
Good luck, it's not easy :-)
Author
Quote:Original post by TheGilb
Never mind the fact that copying code from an open source project and making out like it is yours would be illegal :-)
Too true.
Quote:Original post by TheGilb
Ok here's a few tips:
1. Never over simplify. Making games is technical, you should allow the user to do technical things when he needs to.
I always try to make whatever i do easy to use, maybe i think about the users of the engine as some sort of "hai i dun want 2 code plz" guys. Can't believe it took me this long to figure that out. =/
Quote:Original post by TheGilb
2. Make your interfaces clean, intuitive, logical and most of all, comment everything.
My engine (previous version) had over 20k lines of comments, for doxygen documentation. >_>
Quote:Original post by TheGilb
3. Do the basics well. Memory management, error reporting, helper utilities / etc should all be perfect.
I wouldnt say it's perfect, but the Memory Management system, Logger, and helper functions were pretty good.
Quote:Original post by TheGilb
4. Dont kid yourself, this engine is probably mostly a learning tool, but make games alongside the development of the engine. It will help you learn how it needs to work, figure out what the missing features are, and make it perfect!
I usually just make demos, my deviantart page has a lot of demos as screenshots and flash videos, and i'm constantly adding features to it. Problem is, i oversimply things when i want to complete it...
Quote:Original post by TheGilb
Good luck, it's not easy :-)
Yes it's not. And thank you!
It wouldn't be illegal if he open sourced his engine as well.
It takes a certain amount of sophistication to successfully be a programmer, so don't be afraid to allow things to be complicated. However try to avoid "Mechanical complication", that is functions should provide clean logical actions there should never be a certain order functions have to be called in such as screen create, screen init, screen set settings, screen reinit that will break unless called in that very specific order(sure creation before first use can be expected but in the example every function after create should not exist, creation should produce a working object). If I have to mechanically call things in order it should be automated. If there can be a reason for the mechanical path provide both a default easy path and the broken up step by step path. In your example there is a clear, draw, end that sounds like something that will always be performed in that order why should I be bothered with having to type repetitive code?
Another thing if you are writing this engine for others you will be hard pressed to get it 100% right with out the involvement of others. Try to clean up and document the api and release it if you are going to do so. If it is a pet project not meant for outside consumption then try documenting it as if you expected others to use it, any time during the tutorial that you can't explain why the next step isn't hidden in the current step then you need to polish that section of the api.
It takes a certain amount of sophistication to successfully be a programmer, so don't be afraid to allow things to be complicated. However try to avoid "Mechanical complication", that is functions should provide clean logical actions there should never be a certain order functions have to be called in such as screen create, screen init, screen set settings, screen reinit that will break unless called in that very specific order(sure creation before first use can be expected but in the example every function after create should not exist, creation should produce a working object). If I have to mechanically call things in order it should be automated. If there can be a reason for the mechanical path provide both a default easy path and the broken up step by step path. In your example there is a clear, draw, end that sounds like something that will always be performed in that order why should I be bothered with having to type repetitive code?
Another thing if you are writing this engine for others you will be hard pressed to get it 100% right with out the involvement of others. Try to clean up and document the api and release it if you are going to do so. If it is a pet project not meant for outside consumption then try documenting it as if you expected others to use it, any time during the tutorial that you can't explain why the next step isn't hidden in the current step then you need to polish that section of the api.
What are your goals with this engine? To build games with, or to release it to the public?
Either way, it looks like you're a perfectionist and haven't figured out the problems of that attitude yet. I've got the same issue, but I'm actively fighting it. Things don't need to be perfect, they just need to do their job. That's not an excuse for poor coding, that's a reminder not to waste time perfectioning things that already forfill their purpose well enough. If you want to build a game, then get a game done. There will always be rough edges. That's ok, it's normal. I can't name a single game that was absolutely perfect.
As for easy to use, the only way to find out is to put it out in the open. In the announcements board, there's two guys who are working on a 2D game engine, Agen. From time to time they're releasing a new build. For me, it's pretty interesting to see their progress, for them it's pretty usefull to receive feedback every now and then.
Either way, it looks like you're a perfectionist and haven't figured out the problems of that attitude yet. I've got the same issue, but I'm actively fighting it. Things don't need to be perfect, they just need to do their job. That's not an excuse for poor coding, that's a reminder not to waste time perfectioning things that already forfill their purpose well enough. If you want to build a game, then get a game done. There will always be rough edges. That's ok, it's normal. I can't name a single game that was absolutely perfect.
As for easy to use, the only way to find out is to put it out in the open. In the announcements board, there's two guys who are working on a 2D game engine, Agen. From time to time they're releasing a new build. For me, it's pretty interesting to see their progress, for them it's pretty usefull to receive feedback every now and then.
"clear -> draw -> end" seems like a perfectly sound implementation to me, with the "clear" method being optional, of course. The engine won't know how many objects you intend to "draw," so you have to tell it when you're done. This is intuitive to graphics programmers and shouldn't be changed. Otherwise, I agree that obligatory steps should be consolidated whenever possible. This is the path DirectX has been following. I still get chills thinking about device initialization in DX7. Brrrr.
How about
That's the base would handle the generic loop (you still might want to give some access to eg. clear) and application would just update what it needs.
BTW. I have no idea how a game engine should work [ignore].
class MyApp : public engine::Application {public: void initialize() { ... initialize stuff ... }; void update() { ... update loop ... }; void finalize() { ... get rid of stuff ... };};int main(){ Base asdf(new MyApp);}BTW. I have no idea how a game engine should work [ignore].
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
