this has been needed for a long time :-) kudos for actually getting around to it. im sure theres a large number of aspiring game developers on this forum who need something like this :)
man this was fast! I agree with chrisname though it could do with some more detail, first thing that springs to mind is a list of graphics and sound APIs
Games are often very similar in design. You might consider:
*A resource management example with (a/some) popular API(s).
*An example showing ways to get user input (and network input?)
*A game loop that makes use of the OO game structure. All of the examples I've seen so far on any sites are set up in a huge block in a procedural-like way.
This article has the potential to grow into something amazing, as chrisname said, it just needs the details rather than a broad overview.
...
/**
* Run the game
* \return On success, true is returned. On error, false is
* returned.
*/
publicstaticbool MainLoop()
{
new LogEntry(String.Format("Game start - Press {0} any time to quit",
Controls.ToString(Controls.Exit)));
Game.Running = true;
while (Game.Running) {
Game.Window.UseVerticalSync(Game.UseVerticalSync);
if (Clock.GetElapsedTime() >= 500) {
Game.FrameRate = Game.FrameCount * 2;
Game.FrameCount = 0;
Game.Clock.Reset();
}
Game.HandleInputs();
/*
* There's no UpdateObjects() function because that's done in
* HandleInputs (this is a spaghetti game engine, the "Game" class
* is quite neat and tidy (mostly) but when you get to the internals,
* none of it makes sense)
*/
Game.UpdateWindow();
Game.FrameCount++;
}
returntrue;
}
....
I put in a small example of what a game loop is like. I haven't had much time to work on this today. I plan on adding much more though, just not all at once.
There aren't many tutorials out there that actually show how concepts are used in an actual game. There are many "dumbed down" tutorials that only show how the API's work, but nothing showing how to neatly tuck the concepts away in a maintainable object oriented unit. It's ultimately up to the game developer to figure out how to do that, but why not have a few examples of this as well?
I looked at your example game loop and I can't think of a single game I've made which updated every loop. My game loop always goes something like this
1 2 3 4 5 6 7 8 9
long currentTime = clock();
if ( currentTime - m_prevTime > m_tickRate )
{
UpdateGame(); // update game if one tick has passed
CheckCollisions(); // also only need to check collisions after movement
m_prevTime = currentTime;
}
DrawGame(); // but draw as often as possible, to achieve the highest possible fps
that's missing a lot of stuff like input, but you get my drift, you shouldn't be updating a game every game loop or the speed of the game will depend on how fast your computer is
@quirky
I'm not experienced in game design, but isn't there a point at which the frame-rate should be capped so your game isn't eating up the whole CPU? Putting the thread to sleep for X milliseconds per iteration seems like a good idea in my head. X milliseconds changing with how quickly the last frame was displayed to keep a stable FPS.
ah i didnt spot that call to sleep, ok that makes sense, but still it only draws once per update so it doesnt leave room for movement interpolation for example. Whether you want to limit the framerate will also depend on platform i guess.
@quirckyusername: I see what you mean, but if nothing moved, why redraw anything? I could understand if you had some animations running in the background, but as noted, my example is just the basics.