next »

[nihilocrat]

Interesting range of opinions here...

I think 'observer'-style events or message passing are indispensible to creating a separation of concerns in your code. I follow my own interpretation of the MVC pattern, in which the Model will dispatch game logic events for the rest of the system to pick up. The key to this system is that the Model does not need to know what is going to happen in an event like "bullet hits enemy", it just needs to dispatch the event with the correct parameters. This is where I find the power of events come in play: you can separate your code into smaller pieces which are easier to manage rather than deciding what everyone should be doing about a game event right when it happens, in a big blob of code and a heap of references to other subsystems. Any other object in the game can choose to push itself onto the Model's stack of event listeners and receive certain events, at which point each object immediately decides what to do about the event.

Of course, this creates a possible conflict in that you don't know the order in which objects will respond to the events, or the order is based on something obscure like the order in which they got pushed onto the event stack. As others have said, you should avoid this conflict by using events for things where the order doesn't matter; if a bullet hits an enemy I don't really care if it gets deleted before or after an explosion graphic is shown, or before or after a sound is played, so long as all these events occur before the next render cycle.

If you want to know what systems have responded to the event, you can simply make the event dispatcher compile a list of objects whose methods it has called or to whom it has sent messages for every event it sends. Honestly, I have not yet seen the need to know this bit of information but it's there if you need it.

[Jason Bakker]

^ Also, you could potentially pass in a "priority" to your event listener add(), so that certain objects will always get called before other objects. Of course, that still doesn't fix the problem where you want one order of calls after one event, but a different, incompatible order after another event... but it may help to minimize the issue. (And at least you should know what will get called first, based on that priority that you pass through.)

Although I'm with nihilocrat in that I haven't run into issues with an unordered event listener list yet either.

[Triplefox]

I don't use events for gameplay in my current game engine, but I might want to add them in the future.

Right now I use markers for everything and have my game loop operate in passes:

• Spawn/despawn
• Determine game state(run simulation, run dialogue, in-game menu, restart scene, etc.)
• Simulation internals: Get input, run physics(entity movement and environment collisions only), run AI systems(mark for spawn/despawn here)
• Render

Every entity maintains a hook into the different subsystems, so they may or may not have physics, AI, or rendering. This gives me broad control over priority, it means entities don't have unnecessary overhead, and it lets me get fine-grained too, as I can always push unique physics, AI, or rendering code into a separately maintained data structure and just reorder which of several similar systems get to go first: "Player AI, then NPC AI, then bullet AI...."

However, where I perceive events coming in handy is in formalizing things I currently do by dumping "magic marker" variables onto the property lists of entities and having the entities test for them. The AI will want to know a variety of things like "Did I get shot? Did I touch a wall? Did switch X get triggered?" and with an event system I can hopefully remove the "set variable/test variable" pairings that currently litter the code to implement those features.