Event Driven Communication in Game Engine - Yes or No?

Question

As I am reading book Game Coding Complete (http://www.amazon.com/Game-Coding-Complete-Third-McShaffry/dp/1584506806/ref=sr_1_1?ie=UTF8&qid=1295978774&sr=8-1), the author recommend Event Driven communication among the all game objects and modules.

Basicaly, all the living game actors and object should communicate with the key modules (Physics, AI, Game Logic, Game View, etc..) via internal event messaging system. This would mean designing efficient event manager as well.

My question is, whether this is proven and recommended approach. If it is not properly designed, it might mean consuming a lot of CPU cycles, which can be used elsewhere. This is especially true, if the game is targetted for mobile platform.

What is your opinion and recommendation, please?

Answer 1

Cut and paste of my comment that was suggested I make it a full answer. I have added in a bit more here to actually try and flesh it out into an answer.

Yes, plain and simple.. Communication needs to happen and while there are situations where 'Are we there yet?' type of polling is required, you generally are wasting time having things check to see if they should be doing something else, when you can have them react to things they are told to do... Plus... a well defined communication pathway between objects/systems/modules helps significantly in multithreaded/process/core/computer setups

Also, over on Stack Overflow I gave a general high level view of an event messaging system I have used from school into professional gaming titles and now non-gaming products, refined a bit each time to their specific usage of course, hehe..

EDIT: To address the question in the comments of how do you know which objects should get the message, the objects themselves should Request to be notified about the 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 would want a pool of these callback registration objects and an effective way to add/remove them from lists (I personally have used self ordering arrays (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) for the most part).

EDIT: If you want 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. This link is also in the stack overflow post on this topic linked above.

Hope this helps clear up your latest concern :)

Answer 2

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 3

An operating system is build to be stable, efficient and as fast as possible since it is a real time application. Why would you say that an operating system has less contraints than a video game ?

Answer 4

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 5

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.

Answer 6

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 7

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 8

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.