What are some good articles or tutorials that talk about how game engines should be structured? Some thing like this, [url]http://www.sfml-dev.org/wiki/en/tutoriels/gqe_en[/url].
EDIT: My life is almost complete, I've been rated dumb by layla, all that's left is Soda.
I'd like a good article about that too.
I don't really understand your question. But I'm guessing you want to make your own game engine?
Have you tried looking up the documentation for DirectX development and the one for OpenGL?
I don't have any links to post. But I'm sure if you google it you will find something.
I mean like the structure of the program, like when should I process events? When should I load stuff?
You could go crazy with progress bars/threading, but I'm hoping you're wanting to start out slow.
Load stuff at the top of main, and (I'm assuming you're using Windows) use an infinite loop to process Windows messages (aka the standard Windows application).
Then, you can create your own timer to fire periodic events in that infinite loop, or use SetTimer() and the WM_TIMER message to fire periodic events. By "periodic event", I mean think/tick/render frames.
For help using these messages/functions, Google search function names with "inurl:msdn" at the end for quick documentation.
Also, you're probably going to want to break up your code into objects. How you break your code up depends heavily upon what kind of game you're trying to make. Since you're making what appears to be an all-purpose engine, you will have only a vague idea of how to break up your code, and even then, it may be overly-complicated or too restrictive...I strongly recommend you have at least a rough idea of how your game will play first.
Pretty much what Night-Eagle said, it depends on the type of game you're making. Almost 100% of the time, you'll have a main loop that renders everything defined as visible. Depending on how you want to go, you can either have the logic run in the main loop, before rendering, or you can spin off other threads to do your work then either push the changes to the main thread or have the main thread poll for changes every frame.
Beyond that, organization of game code and data differs wildly between different games. In an FPS, it's best to leave the concept of a house as something for the artists, where in an RTS, it should be an object with multiple settings and the ability to interact with it.
However, I generally find it best to come up with a generic Entity class that'll contain whatever is needed for the absolute basics of the object (position, angle, etc.), then have any other object in the game inherit from that Entity and add on whatever it needs (ie physics, specific abilities). It keeps things organized. Then again, I'm just a few months into my first game, and it's for Android, so we're writing it in Java. You'll definitely be doing things differently in C/C++, but I still think keeping things object-oriented will be better overall.
[QUOTE=Jookia;27627193][cpp] shared_ptr<IEngineLayer> engine = createEngineLayer();
while(engine->run() == false) ;[/cpp]
Keep things abstracted.[/QUOTE]
[cpp]
shared_ptr<IEngineLayer> engine = LayerFactory<IEngineLayer>::CreateInstance();
while(engine->run()->Compare<bool>(false)) ;
[/cpp]
You never know, you might decide to change the types some day.
Sorry, you need to Log In to post a reply to this thread.
