Monday, October 19, 2015

architecture - 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:




  • 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



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.



No comments:

Post a Comment

Simple past, Present perfect Past perfect

Can you tell me which form of the following sentences is the correct one please? Imagine two friends discussing the gym... I was in a good s...