Event-driven Communication in a Game Engine: Yes or No?

Question

I am reading Game Coding Complete and the author recommends Event Driven communication among game objects and modules.

Basically, all living game actors should communicate with the key modules (Physics, AI, Game Logic, Game View, etc.) via an internal event messaging system. This means having to design an efficient event manager. A badly designed system eats CPU cycles, especially affecting mobile platforms.

Is this a proven and recommended approach? How should I decide whether to use it?

Answer 1

This is an expansion of my comment to a full answer, as suggested.

Yes, plain and simple. Communication needs to happen and while there are situations where 'Are we there yet?'-type polling is required, having things check to see if they should be doing something else generally wastes time. You could instead have them react to things they are told to do. Plus, a well defined communication pathway between objects/systems/modules boosts parallel setups significantly.

I've given a high-level overview of an event messaging system over on Stack Overflow. I have used it from school into professional gaming titles and now non-gaming products, adapted to the use case every time of course.

EDIT: To address a comment question on how do you know which objects should get the message: The objects themselves should Request to be notified about events. Your EventMessagingSystem (EMS) will need a Register(int iEventId, IEventMessagingSystem * pOjbect, (EMSCallback)fpMethodToUseForACallback) as well as a matching Unregister (making a unique entry for an iEventId out of the object pointer and callback). This way, when an object wants to know about a message it can Register() with the system. When it no longer needs to know about the events, it can Unregister(). Clearly, you'd want a pool of these callback registration objects and an effective way to add/remove them from lists. (I've usually used self ordering arrays; a fancy way of saying they track their own allocations between a pool stack of unused objects and arrays that shift their sizes in place when needed).

EDIT: For a completely working game with an update loop and an event messaging system, you might want to check out an old school project of mine. The Stack Overflow post linked above also refers to it.

Answer 2

My opinion is that you should just start making your game and implement what you're comfortable with. As you do that you'll find yourself using MVC some places, but not others; events some places, but not others; components some places, but inheritance others; clean design some places, and crufty design others.

And that's OK, because when you're done you'll actually have a game, and a game is way cooler than a message-passing system.

Answer 3

Messages generally work well when:

1. The thing sending the message doesn't care if it gets received.
2. The sender does not need to get an immediate response back from the receiver.
3. There may be multiple receivers listening to a single sender.
4. Messages will be sent infrequently or unpredictably. (In other words, if every object needs to get an "update" message every single frame, messages aren't really buying you much.)

The more your needs match that list, the better of a fit messages will be. At a very general level, they're pretty good. They do a good job of not wasting CPU cycles just to do nothing unlike polling or other more global solutions. They are fantastic at decoupling parts of a codebase, which is always helpful.

Answer 4

A better question is, what alternatives are there? In such a complex system with properly divided modules for physics, AI, etc., how else can you orchestrate these systems?

Message passing does seem to be the "best" solution to this problem. I can't think of alternatives right now. But there are plenty of examples of message passing in practice. In fact, operating systems use message passing for several of their functions. From Wikipedia:

Messages are also commonly used in the same sense as a means of interprocess communication; the other common technique being streams or pipes, in which data are sent as a sequence of elementary data items instead (the higher-level version of a virtual circuit).

(Interprocess communication is the communication between processes (i.e. running instances of programs) within the operating system environment)

So if it's good enough for an operating system, it's probably good enough for a game, right? There are other benefits as well, but I'll let the Wikipedia article on message passing do the explaining.

I also asked a question on Stack Overflow, "Data structures for message passing within a program?", which you might want to read over.

Answer 5

Great answers so far from James and Ricket, I only answer to add a note of caution. Message passing / event driven communication is certainly an important tool in the developer's arsenal, but it can easily be overused. When you have a hammer, everything looks like a nail, and so on.

You absolutely, 100%, should be thinking about the flow of data around your title, and be fully aware of how information is passing from one subsystem to another. In some cases message passing is clearly best; in others, it may be more appropriate for one subsystem to operate over a list of shared objects, allowing other subsystems to also operate on the same shared list; and many more methods besides.

At all times you should be aware of which subsystems need access to which data, and when they need to access it. This affects your ability to parallelise and optimise, as well as helping you avoid the more insidious problems when different parts of your engine become too closely entwined. You need to be thinking about minimising unnecessary copying around of data, and how your data layout affects your cache usage. All of which will guide you to the best solution in each case.

That being said, pretty much every game I've ever worked on has had a solid asynchronous message passing / event notification system. It allows you to write succinct, efficient maintainable code, even in the face of complex and quickly changing design needs.

Answer 6

Yes. It is a very efficient way for game systems to communicate with each other. Events help you decouple many systems and make it possible to even compile things separately without knowing of each others' existence. This means your classes can be more easily prototyped and the compilation times are faster. More importantly, you end up with a flat code design instead of a dependency mess.

Another big benefit of events is that they are easily streamed over a network or other text channel. You can record them for later playback. The possibilities are endless.

Another benefit: You can have several subsystems listening for the same event. For example, all your remote views (players) can automatically subscribe to the entity creation event and spawn entities on each client with little work on your part. Imagine how much more work it would be if you did not use events: you would have to place Update() calls somewhere or maybe call view->CreateEntity from the Game logic (where knowledge about the view and what information it requires doesn't belong). It's hard to solve that problem without events.

With events you get an elegant and decoupled solution that supports infinite number of objects of unlimited kinds that can all simply subscribe to events and do their thing when something happens in your game. That's why events are great.

More details and an implementation here.

Answer 7

Well, I know that this post is quite old , but I could not resist.

I recently built a game engine. It uses 3d party libraries to rendering and physics, but I wrote the core part, that defines and processes the entities and game logic.

The engine surely follows a traditional approach. There is a main update loop that calls update function for all entities. Collisions are directly reported by callback on the entities. Communications between entities are made using smart pointers exchanged between entities.

There is a primitive message system, That processes only a small group of entity to engine messages. Those messages are preferable to be processed at the end of a game interaction ( example is a entity creation or destruction ) because they can mess with the update list. So , at the end of each game loop, a small list of messages are consumed.

Despite the primitive message system , I would say that the system is largely "update loop based".

Well. After using this system, I think that it is very simple, fast and well organized. The game logic is visible and self contained inside entities, not dynamic like a message quewe. I really would not to make it event driven because in my opinion event systems introduce unnecessary complexity to the game logic , and make the game code very difficult to understand and debug.

But, I also think that a pure "update loop based" system like mine have some problems too.

For example, In some moments, one entity may be at a " do nothing state " , may be waiting the player approaching or something else. In most of those cases , the entity burns processor time for nothing and its is better to turn the entity off, and turn it on when a certain event happens.

So, in my next game engine , I am going to adopt a different approach. Entities will register themselves for engine operations, like update, drawing, collision detection and so one. Each of these events will have separated lists of entity interfaces for the actual entities.

Answer 8

From what I have seen, it doesn't seem to be very common to have an engine completely based on messaging. Of course, there are subsystems which lend themselves very well to such a messaging system, like networking, GUI, and possibly others. In general though, there are a few problems I can think of:

• Game engines deal with large amounts of data.
• Games have to be fast (20-30 FPS should be the minimum).
• Often it is necessary to know if something has been done or when it will be done.

With the common game developer approach of "it has to be efficient as possible" such messaging system are thus not that common.

However, I agree that you should just go ahead and try it. There certainly are lots advantages with such a system and computing power is cheaply available today.