Page 1 of 1
Event Driven Management
Posted: Thu Aug 25, 2011 10:56 am
by gardevil7
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!
Re: Event Driven Management
Posted: Thu Aug 25, 2011 7:24 pm
by pestaa
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.
Re: Event Driven Management
Posted: Thu Aug 25, 2011 8:18 pm
by jacmoe
pestaa wrote:Ogre is not a game engine
That's not really what he's asking.
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.
Re: Event Driven Management
Posted: Fri Aug 26, 2011 9:55 am
by gardevil7
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:
Code: Select all
currState = startState;
while (currState != exitState) {
readInput();
updateOrChangeState();
renderOneFrame();
}
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):
Code: Select all
while (event != quit_event) {
readEvent();
processEvent();
}
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)
Re: Event Driven Management
Posted: Fri Aug 26, 2011 10:11 pm
by pestaa
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.
Re: Event Driven Management
Posted: Sun Aug 28, 2011 4:48 am
by jacmoe
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.
Re: Event Driven Management
Posted: Mon Aug 29, 2011 12:30 pm
by gardevil7
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:
Code: Select all
while (game_running) {
readInput();
postEvent(tic_event);
consumeEvents();
renderOneFrame();
}
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?
Re: Event Driven Management
Posted: Wed Aug 31, 2011 7:33 pm
by pestaa
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?
Re: Event Driven Management
Posted: Wed Aug 31, 2011 11:44 pm
by gardevil7
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?