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

Question

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:

• What are the advantages and disadvantages of the both approaches?
• 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

Answer 1

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.

What are the advantages and disadvantages of both approaches?

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.