Game loop and processing game objects

[moron123]

Hi. First of all I would like to say that I'm a beginner in programming and I only have some basic C++ knowledge. Yet, I always wanted to make "something" or to try at least, considering the fact that I am not a smart person and programming is not for everyone. Second thing is I don't really know if this forum is a proper place for my question but I hope nobody will yell at me.

Simply I wanted to learn how even simple games work, how it is done when it comes to programming etc. I started writing something like a naive "framework" or maybe a "game engine", so I could try to create a simple game on top of that. I read a lot of articles and posts about various aspects of game development but I am still confused.

Ok, let's get to the point. Currently I have my code split into several classes ("modules") which are responsible for their tasks and grouped in the main "engine" class so they can work together. I have something like a "GameSceneCollector" which collects activated game scenes. A "GameScene" is a base class that can be used to write game scenes. Each one contains its own "GameSceneCollector" which means that scenes can be nested and separated inside various scenes. Each scene also contains three "GameObjectCollectors" - one for inputtable, one for updateable, and one for renderable objects. A "GameObjectCollector" is very similar to the scene collector but it groups game objects. A "GameObject" is a base class for creating individual game objects which can be processed. In the main loop I am calling three "modules": "inputModule", "updateModule" and "renderModule". Each one processes my main game scene collector and then takes all scenes and recursively iterates through them finally executing "process" method on individual game objects. While "updateModule" and "renderModule" have fixed timings, for example both have set rate to 1 per second, the "inputModule" doesn't have any time condition and runs as fast as it can gathering user input from window.

Now, for example, let's say that I want to create a game console and in my game scene I have created three game objects: "GameConsoleUpdate", "GameConsoleInput" and "GameConsoleRender". All of them are based on "GameObject". I am aware that such a naive separation may be really stupid and senseless in a long shot, but for now I wanted to give it a try. So I am processing "GameConsoleInput" as fast as it is possible, then with a specific timeouts I am processing "GameConsoleUpdate" and "GameConsoleRender". And now my questions come. If I press a button to toggle game console screen how it should be done to avoid input lag? Input is processed immediately, let's say rendering almost also (with a high framerate) but update is limited to be processed only 10 times per second, which makes a 100 ms lag for things that should be done in "GameConsoleUpdate" object.  Where should I contain information indicating that my game console has been opened right now and it should be shown immediately? "GameConsoleInput" object should call only "GameConsoleUpdate" object to change its state, or maybe also "GameConsoleRender" so it should know that its should be drawn in this moment without waiting 100 ms to check its state in the "GameConsoleUpdate" object? As I said, I am really confused with all these separation of concerns ideas and I would like to know how it should be done properly but rather without any fancy design patterns such as ECS.

Sorry for this wall of text but I just wanted to describe my doubts in a clear way. I hope I didn't messed up.

[eXpl0it3r]

This is the SFML forum and not the general gamedev forum. You'll most likely get better answers on dedicated forums like http://gamedev.stackexchange.com or http://gamedev.net

It's also recommended to get a good understanding of C++ before diving too deep, otherwise you'll just keep struggling with basic C++ problems without actually realizing it. Here's a good book list.

And as a last advice: Don't over engineer your things. Go the most simplest way, only implement what you nee right now and create a game, not an engine.

[ChronicRat]

and create a game, not an engine.

This is the most important advice and the most hard to follow. =)

[StormWingDelta]

and create a game, not an engine.

This is the most important advice and the most hard to follow. =)

I agree on this.  The idea is to make the game first and create the game engine from the things you see that you need later. So if you make the game you'll have your engine without realizing it.