Timeline for Per-Frame Function Calls versus Event Driven Messaging in Game Design
Current License: CC BY-SA 2.5
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 2, 2012 at 7:12 | comment | added | michael.bartnett |
In C++, function pointers can't be bound to objects (since it's just a feature inherited from C). So member function pointers cause a lot of grief and headaches, so people end up implementing some sort of IEventListener abstract class that just has an HandleMessage(IEvent evt) pure virtual function. (similar to ActionListener in Java). Functors can help, but still cause problems since you have to make them friends of your class if you want to access private members.
|
|
| Dec 2, 2012 at 7:11 | comment | added | michael.bartnett | @jhocking The "function pointers for some reason" bit was referencing using them in C++ (I made that assumption since that's what Game Coding Complete assumes). I'm not a true C++ guru, but I've only seen them useful for global callbacks. If you're writing in AS3, Python, Javascript, Lua, Ruby, Scala, Clojure, a .NET language, etc. then function pointers are the way to go (thank god for delegates in .NET). | |
| Dec 1, 2012 at 4:46 | comment | added | jhocking | 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. | |
| Jan 26, 2011 at 17:17 | comment | added | Bunkai.Satori | 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. | |
| Jan 26, 2011 at 17:07 | comment | added | michael.bartnett | 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.). | |
| Jan 26, 2011 at 16:58 | comment | added | Steve H | 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. | |
| Jan 26, 2011 at 15:49 | comment | added | Bunkai.Satori | 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? | |
| Jan 26, 2011 at 15:23 | history | answered | michael.bartnett | CC BY-SA 2.5 |