# Per-Frame Function Calls versus Event Driven Messaging in Game Design

The traditional game design, as I know it, uses polymorphism and virtual functions to update game objects states. In other words, the same set of virtual functions are called in regular(ex: per-frame) intervals on every object in the game.

Recently, I discovered, that there is another - event driven messaging system available to update states of game objects. Here, the objects usually are not updated on per-frame basis. Instead, a highly efficient event messaging system is built, and game objects get updated only after receiving valid event message.

Event Driven Game Architecture is well described in: Game Coding Complete by Mike McShaffry .

Could I kindly ask for help with the following questions:

• Where is one better over the other?
• Is Event driven game design universal and better in all areas? Is it therefore recommended for usage even in mombile platforms?
• Which one is more efficient and which is more difficult to develop?

To clarify, my question is not about removing polymorphism completely from a game design. I simply wish to understand the difference and benefit from using event driven messaging vs regular(per-frame) calls to virtual functions to update game state.

Example: This question caused a bit of controversy here, so let me offer you example: According to MVC, the game engine is divided into three main parts:

1. Application Layer (Hardware and OS communication)
2. Game Logic
3. Game View

In a racing game, the Game View is responsible for rendering the screen as quickly as possible, at least 30fps. Game View listens for player's input too. Now this happens:

• Player presses fuel pedal to 80%
• GameView constructs a message "Car 2 Fuel Pedal Pressed to 80%" and sends it to Game Logic.
• Game Logic gets the message, evaluates, calculates new car's position and behavior and creates the following messages for GameView: "Draw Car 2 Fuel Pedal Pressed 80%", "Car 2 Sound Acceleration", "Car 2 Coordinates X, Y" ...
• GameView receives the messages and processes them accordingly
• where did you find? some links or reference? i don't know this approach (but i know quite weel design pattern in general, and i advice a good use of object orientations principles in general), but i think event based one is better.. think of evolution in network systems: from polling to asynchronous calls.. it is optimized in computations and in abstraction level – nkint Jan 26 '11 at 11:46
• Hi Nkint, thank you for your comment. I basically wished to compare event driven communication vs calls to virtual functions. I will modify my question a bit. Btw, take a look at this link containing game desing patterns: gameprogrammingpatterns.com. – Bunkai.Satori Jan 26 '11 at 11:55
• Maybe I'm being dumb, but how are you going to make a messaging system work without using polymorphism? Aren't you going to need some kind of base class (abstract or otherwise) to define your event receiver interface? (Edit: assuming you're not working in a language with proper reflection.) – Tetrad Jan 26 '11 at 15:13
• Also, efficiency is going to be highly tied to implementation details. I don't think "which one is more efficient" is a question that can be answered in its current form. – Tetrad Jan 26 '11 at 15:14
• Game objects need to tick. Game objects need to communicate with each other. Those two things both need to happen. The first you don't do with messaging because it's redundant (you probably have a list of all the objects somewhere, just call update on them). The second you can do with messaging for various reasons. – Tetrad Jan 26 '11 at 17:32

I'm a full believer in necessity being the mother of invention. I do not like to code anything unless its need is clear and well-defined. I think that if you start your project by setting up an event messaging system, you're doing it wrong. I believe that only once you've created and tested your infrastructure and have all the pieces to your project as well-defined, working modules should you focus on how you're going to connect these modules to each other. Trying to design an event messaging system before you understand the shape and needs of each module is out of order.

I think some people would argue that there are good messaging systems out there ready to be installed and used. Perhaps this is true. Certainly the performance of a custom-build solution specifically tailored to your needs would be greater than a general-purpose message bus. The big question is - how much time are you going to spend building a messaging system rather than using something that has already been built. Obviously, if you could find some sort of event system with exactly the feature set you need, then it's a pretty easy decision. This is why I make sure that I understand exactly what I need before I make that decision.

Where is one better over the other?

We could talk about memory and resources here. If you're developing for any hardware with limited resources, it's certainly an issue to use a event system that will cut into that significantly. Really, though, I think the issue comes down to what you need, which as I mentioned already is something that you don't know until you see what all the pieces look like. If you have enough experience building these systems that you know in advance exactly what all the pieces are going to look like, then you can answer this question in advance as well. I'm guessing you don't have this experience, since you wouldn't be asking this question if you did.

Is Event driven game design universal and better in all areas? Is it therefore recommended for usage even in mobile platforms?

Universal and better in all areas? A pretty blanket statement like that is easily rejected. Anything that adds overhead needs to be carrying its share of the workload. If you're not using events enough to warrant the overhead of the design, then it's the wrong design.

Which one is more efficient and which is more difficult to develop?

Efficiency depends on how its implemented. I think that a well-developed traditional design will out-perform an event-based system any day of the week. This is because communication between pieces can be micro-managed and made super efficient. Of course, this also makes it more difficult to design from the standpoint of experience and time required to complete it and make it more efficient. On the other hand, if you lack this experience or don't have the time to develop the application well, then using an event based design that suits your needs will be more efficient. If you have custom event needs that doesn't easily fit into an event-based structure, this could make the event-based structure very difficult to design - especially to keep the design efficient.

• Hi Eric, thank you for your detailed opinion on my question. As I read your's and other's responses, implementing event messages probably does not cause a miracle in overall game performance increase. Instead it is going to complicate things a lot. I would like to see some more answers, before closing this question. As the the whole book covered this topic, it looked like a good idea to consider. I am not very sure, if the decision to use or not to use messages can be made in the middle of the project. If event messages are used, I would say, the overall object design must be adjusted too. – Bunkai.Satori Jan 26 '11 at 15:38
• I disagree. If the overall object design is well encapsulated, it should be flexible enough to be used in any kind of framework. I have been able to swap out communication methods in large projects with very little work because each piece was well encapsulated. – Erick Robertson Jan 26 '11 at 18:18

I think you're comparing apples and oranges here. Polymorphism isn't replaced by messaging at all. You would probably want events/messaging to connect loosely coupled components. Eg. to send a message from an entity when a collision occurs, to update the player score or maybe to trigger a sound-effect. So that these individual classes don't know the other classes and just send out and/or handle messages.

But your game is most likely going to have an update loop somewhere and since you have that update loop, it can easily be used to update all game entities that need to be updated every frame as well. This doesn't prevent you from using messaging though...

If you have some sort of structure where you add/remove game-entities, you can just as well include them in your update loop instead of dispatching an update message to them every frame. So why not call update on your game entities directly while you're using messaging to connect different sub-systems of your game? I also like the Signal/Slot concept (see qt example) for event-like systems.

Bottom line: There's no better approach, nor are they exclusive.

• Hi, Bummzack. Finally, the first answer arrived. Thank you for that :-) When I mentioned Event Driven Architecture, I meant a MVC system with three key layers: Appliaction, GameView, GameLogic. All the communication between these trhee would be done via messaging. This is significantly different as the traditional system with update loop. Every system has different architecture, some advantages and disadvantages, and they have different performance cost. I therefore believe, one would be slightly better in some areas. After good analysis, we should be able to conclude which one is better. – Bunkai.Satori Jan 26 '11 at 13:32
• I fail to see why this is any different? You'll need an update loop somewhere and that will probably update the Controller if you want to stick with MVC. Then the controller can message the model and the view.. but since the controller usually knows view and model, it could also update them directly. But this is not replacing any polymorphism. Your question and assumptions sound very theoretical.. maybe back them up with some example code or some references? – bummzack Jan 26 '11 at 13:58
• The above mentioned book, Game Coding Complete, recommends event messaging over direct calls to virtual methods. Although, the messaging system looks more complex, its advantage is, that every game object does not need to check the game world. Game world is checked by game logic only once, and then only those objects are addressed which are supposed to change their states. This is one difference, and can mean cost savings. If you decide that your game objects will communicate via messages they won't be called each frame - therefore the two approaches are mutually exclusive. – Bunkai.Satori Jan 26 '11 at 14:42
• Up-voted for an answer that reflects Tetrad's comments below the original question. @Bunkai.Satori The 'game world is checked only once' is the update loop, everything that needs updating gets it. The Event Messages are meant to be the seldom done but still key things in the engine (PlayerDied, MonsterDied, etc) that checking for every frame in an Update() loop would be a waste on but they are most likely to be generated by the Update() loop itself. – James Jan 26 '11 at 19:28
• If you've got the Second Edition, look at the chapter named Controlling the Main Loop. It should be named the same thing in the 3rd edition. That should really answer your question. – Ray Dey Jan 26 '11 at 20:23

This started as a comment to bummzack's answer, but got long.

Unless you actually make it asynchronous (dispatch events on a new thread), your objects are still getting the memo synchronously. Assuming your event dispatcher uses a basic hash table with a linked list in a cell, the order will be the order in which objects were aded to that cell.

Further, unless you decide to use function pointers for some reason, you still are using virtual function calls since each object getting a message must implement IEventListener (or whatever you call it). Events are a high level abstraction that you build using polymorphism.

Use events where you find yourself having to call a laundry list of methods for various in-game happenings in order to synchronize different systems in the game or where various objects and systems' reaction so said happenings are not able to be clearly defined or you want to add more reactions to said happenings in the future.

They are a great tool, but like bummzack said, don't assume that polymorphism and events solve the same problem.

• Hi Bearcdp, thanks for your reply. It makes sense to me. There is one thing in my mind, that votes for event messages: say, there are 200 ojects in the scene. If you use per-frame function calls on all objects, you have to check all 200 objects for colision every frame (an example; of course the call intervals can be managed.) With event messaging, the gameworld is examined only once. If there are 5 collisions, only 5 objects get notified by messages about collision event, instead of 200 collison detection tests with per-frame calls. What is your opinion? – Bunkai.Satori Jan 26 '11 at 15:49
• examine the gameworld?? what does that mean? It would have to mean running the same 200 checks to isolate the 5 that it needs to send messages about. With the virtual function concept, the gameworld is only being checked once too (each object's function in turn), and then moves onto only the 5 that need state changes... without the overhead of a messaging system. – Steve H Jan 26 '11 at 16:58
• Listen to Steve H, the world doesn't collide itself. I primarily use events for high level happenings, such as PlayerJump, EnemyHit. For handling efficiency of collision checking, you need choose a data structure to organize the physical location of objects in your game so you can prioritize which objects need and need not be checked for collision. Once you've determined all the pairs of objects which have collided, then you can dispatch an event with the relevant collision data (the two objects, velocity/position/normals data, etc.). – michael.bartnett Jan 26 '11 at 17:07
• Hi Steve and Beardcp, thanks for your comments. What you wrote makes sense. It looks like there can be many possible implementations of event messaging system. There can be the pure replacement of the per-frame virtual function concept, as the book mentioned above says so. However, the messaging system can coexist with the per-frame virtual function concept as well, as you say. – Bunkai.Satori Jan 26 '11 at 17:17
• Why do you say "for some reason" in reference to function pointers? That's pretty much how I implemented an event system the times I've written one from scratch (I work in languages that have first-class functions but it's the same idea; pass the function to the event hub object and that object maps listener functions to events) so I'm wondering if there's a disadvantage to that approach. – jhocking Dec 1 '12 at 4:46

I would say that choosing one or the other is pretty wrong. Some objects need calling every frame- some don't. If you have an object you want to render, you need to make a render call to it every frame. Events can't make this change. The same is true for any time-based physics objects- you must call them every frame.

However, I don't make calls every frame to my object management objects, or my user input objects, or anything like that. Mass virtual calls to every object on frame is a terrible idea.

The design used for any particular object should be based on the needs of those objects, and not based on some ideology for the system as a whole.

Edited to be more clear on my first sentence.

• Hi DeadMG, let me explain: In the above mentioned case, the design is divided among three main parts: Appliaction layer (hardware access), Game Logic, Game View. What gets rendered per frame basis is the Game View. However, when Game View records an user input (ex. brake pedal pressed in chasing game) it send a message "Car 2 Brake Pressed" to Game Logic for processing. Game Logic evaluates this action, calculates behavior of the car, and sends message to the Game View: "Car 2 Block Tires", "Car 2 Move to X, Y". This way it is not needed to check per frame, if brake was pressed on every car. – Bunkai.Satori Jan 26 '11 at 18:21
• @Bunkai: So you have some designs that are event-driven and some designs that are called each frame. That pretty much agrees with my answer. – DeadMG Jan 26 '11 at 18:23
• I am happy to find understanding with you, as this question was a bit controversial here today :-) – Bunkai.Satori Jan 26 '11 at 18:27