Hello everyone!
I've been looking for a while, and learning, how the event driven paradigm works (mainly reading a book called 'game code complete'). It seems to be the best way to make videogames, so I am trying to create an abstract library with an event manager and a game state manager and all that staff. With that, I will have a static game core, common for each game I make. At least that is the idea.
But a lot of doubts came to me when I found out that there is not a classic game loop. I understand how the event system works internally (input system sends an event, the ones who care process it and send new events, etc.) but I'm sure there must be a loop somewhere in order to send a tic-event every few milliseconds. Plus, it is said that in this paradigm the flow isn't structured, it depends on the previous events; as I see it, it's just a huge switch-case sentence. But once again, I don't know...
So, I would be really pleasured if anyone could explain a bit and put some examples about the actual flow of an event driven videogame, as well as the structure of the core and classes.
Thanks guys!
Event Driven Management
-
pestaa
- Gnoblar
- Posts: 14
- Joined: Wed Aug 10, 2011 10:11 pm
Re: Event Driven Management
Ogre is not a game engine, this is why you don't find a main loop. It provides a convenient way to fake it through `startRendering()`, but all games outgrow it sooner or later.
Either you implement the event management stack (in which the wiki can help you out), or pick a premade game engine tailored with Ogre to boost the progress.
Either you implement the event management stack (in which the wiki can help you out), or pick a premade game engine tailored with Ogre to boost the progress.
-
jacmoe
- OGRE Retired Moderator

- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: Event Driven Management
That's not really what he's asking.pestaa wrote:Ogre is not a game engine
He wants to know what the main loop does in an event driven engine - and that's an interesting question.
Not a lot of Ogre in that question. Which is why he aptly chose the Off-topic forum for it.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
gardevil7
- Gnoblar
- Posts: 5
- Joined: Wed Aug 17, 2011 4:04 pm
Re: Event Driven Management
As jacmoe sais, my question isn't really about ogre. Although my idea is creating my own event driven game engine (and first understand it) for ogre, the skeleton could be used for any other non-ogre games, I gess. What I want to know is how the flow goes, because thinking in a game loop is easy, but with events is harder.
This is a scheme of the code I made for a kind of ogre game engine:
It is a normal game loop updated every few milliseconds, and as far as I know, this is a normal windows application loop (event driven):
but the readEvent() method blocks the program waiting for an event (usually an input one). My question is, how should an event driven game be structured so it works with events but doesn't block? Because physics, AI, etc. act without user input, they don't have to wait any event (except for a tic-event or something every iteration, I suppose)
This is a scheme of the code I made for a kind of ogre game engine:
Code: Select all
currState = startState;
while (currState != exitState) {
readInput();
updateOrChangeState();
renderOneFrame();
}Code: Select all
while (event != quit_event) {
readEvent();
processEvent();
}-
pestaa
- Gnoblar
- Posts: 14
- Joined: Wed Aug 10, 2011 10:11 pm
Re: Event Driven Management
I apologize for judging quickly, you two are right, I didn't notice what section I'm in. 
I too had a similar train of thoughts, but settled with a traditional main loop quite soon. The reason for that is simple, there are already a couple of threads Ogre starts at the beginning, I saw no point in making the input handling non-blocking. I put the effort where it can pay off -- picking proper containers and algorithms.
I still believe unnecessary parallelism is premature optimization. I have a main loop with a blocking input handling inside it, which is stupidly fast anyway. The difference in your case would be an event system with a blocking main loop inside it.
Of course, if you're talking about any application other than a game, I'm full ears and eager to learn.
I too had a similar train of thoughts, but settled with a traditional main loop quite soon. The reason for that is simple, there are already a couple of threads Ogre starts at the beginning, I saw no point in making the input handling non-blocking. I put the effort where it can pay off -- picking proper containers and algorithms.
I still believe unnecessary parallelism is premature optimization. I have a main loop with a blocking input handling inside it, which is stupidly fast anyway. The difference in your case would be an event system with a blocking main loop inside it.
Of course, if you're talking about any application other than a game, I'm full ears and eager to learn.
-
jacmoe
- OGRE Retired Moderator

- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: Event Driven Management
I think this is a good place to start:
http://altdevblogaday.com/2011/08/17/sc ... o-scripts/
And be sure to follow the link to the Gamedev.net topic (even though I have yet to read that).
It might give you some ideas how to use an event driven system.
http://altdevblogaday.com/2011/08/17/sc ... o-scripts/
And be sure to follow the link to the Gamedev.net topic (even though I have yet to read that).
It might give you some ideas how to use an event driven system.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
gardevil7
- Gnoblar
- Posts: 5
- Joined: Wed Aug 17, 2011 4:04 pm
Re: Event Driven Management
Thank both of you for your replies, i've been reading and googling (or however it's said) some articles and I perfectly understand now the event communication between classes. Now I reached to a possible solution to my question:
This way, there is a main loop which does NOT block, and everything can be updated in every iteration if needed (like AI or physics). Plus, the consumeEvents method generates more events that in the next iteration will be processed, and so on.
For example, in a shooter game: the user fires a weapon, so the readInput method generates a fire_event, the bullet created with that event will move thanks to the tic_event and in the end will trigger a hit_event if hurts an enemy. With that event, the NPC will run away following a path and, as the bullet, he'll move basing on the tic_event, and so on...
What do you people think, could this be a good aproximation to a game event loop?
Code: Select all
while (game_running) {
readInput();
postEvent(tic_event);
consumeEvents();
renderOneFrame();
}For example, in a shooter game: the user fires a weapon, so the readInput method generates a fire_event, the bullet created with that event will move thanks to the tic_event and in the end will trigger a hit_event if hurts an enemy. With that event, the NPC will run away following a path and, as the bullet, he'll move basing on the tic_event, and so on...
What do you people think, could this be a good aproximation to a game event loop?
-
pestaa
- Gnoblar
- Posts: 14
- Joined: Wed Aug 10, 2011 10:11 pm
Re: Event Driven Management
What I fail to see (undoubtedly due to my lack of experience) is the way `consumeEvents()` do not block. Is `libevent` on Unix such a package that could make that function async? How does the whole package look put together?
-
gardevil7
- Gnoblar
- Posts: 5
- Joined: Wed Aug 17, 2011 4:04 pm
Re: Event Driven Management
The code I've written is theorical, there is not a lib that implements it. I would like to do it myself.
The way consumeEvents() would work is with two event queues. The events are in one of the queues, consuming one by one, and the events thrown are put in the other queue. The next iteration the queues switch, so the one full with events is consumed while the empty one fill with the thrown ones, and so on. You could notice that the first (or the last) event processed is always the tic_event.
I think that will do the trick, what do you think?
The way consumeEvents() would work is with two event queues. The events are in one of the queues, consuming one by one, and the events thrown are put in the other queue. The next iteration the queues switch, so the one full with events is consumed while the empty one fill with the thrown ones, and so on. You could notice that the first (or the last) event processed is always the tic_event.
I think that will do the trick, what do you think?