6 ms·

Wrong. I like using an event driven architecture in games as opposed to an update driven one. There is no concept of staleness in a single player game running o

Wrong. I like using an event driven architecture in games as opposed to an update driven one. There is no concept of staleness in a single player game running on one machine. Many of the concepts the author mentions simply do not exist in that context. In games, event driven = some event happens, all the logic that needs to execute in response to that happens immediately, as opposed to, for example being put on a blackboard and dealt with in some other update loop. The reason a lot of games have frame-perfect bugs / exploits / glitches is because they use an update-driven architecture. So its possible that for one frame after certain things happen the game is in an inconsistent state.

alexchamberlain 8y ago
To be fair, the author did state it is distributed event-driven architectures several times. You can find these outside of a web context quite easily.
pyrale 8y ago
Imo, the problem is not with the title being too broad, but with your experience with event-driven architectures being too narrow. The author talks about general cases, and while respecting his rules in your particular situation is not going to give you much, it isn't going to cause trouble either. On the other hand, if you try to disrespect these advices in a different problem, you may run into huge problems, because the simplifications you made don't hold.
jayd16 8y ago
You do run into the same issues in something like a game. Lets say you have a character doing some animation clip and at the end you want to run some callback. That character could be killed by the player or the player could quit to the main menu or any number of things. Now your callback is stale. You have to deal with cleaning it up, ensuring it does actually fire if you need it to, and handling any issue with the now deceased character.
- everyone 8y ago
  Wrong again. You are obviously commenting about an area you are not familiar with. That is a very weird scenario. You dont want stuff like animation affecting logic. The game logic should never be affected no matter what the animations are doing. But if for some bizarre reason you did have that scenario, a way of doing it using a typical game engine approach would to put that callback at the end of a coroutine. If the character dies then no matter what is is you definitely dont want that callback to fire, (There shouldnt be logic being affected by an animation, but if that character is dead then it shouldnt be affecting anything at all) part of your game engine would be that coroutines do not run on things which have been destroyed.
  - jayd16 8y ago
    Man, you're the one who said you were using events for game dev not me. Coroutines or events, the idea that you need to reconsider your state when execution returns is still valid advice. Tying a courtine to a game object's life cycle _is_ managing the event state. Its clearly not a weird scenario when entire game engines are based around this principle.
    - everyone 8y ago
      Well as I said having some logic executed by an animation would be doing things backwards... Most of the points in the article are about using an event driven architecture in the world of distributed systems, where the messages triggering events are delayed by a certain amount, can be lost, malformed, or different to what the receiver expects. None of that applies to a single program running on one machine. Thats why using an event driven architecture for a game is so great. I never have to worry about most of the stuff in the article. Also (as opposed to the more common Update driven model) if I do a good job its possible for my games logic to be flawless, it can be impossible for it to be in an illegal or weird state. So an event driven architecture in a game is fantastic for that reason, and the article is quite useless when it comes to event driven architecture in games. I'm sure its fine for event driven architecture in distributed systems, but the title is certainly too broad. Like with many of the articles posted here, CRUD / web devs forget there are other fields of programming.

alexchamberlain 8y ago

To be fair, the author did state it is distributed event-driven architectures several times. You can find these outside of a web context quite easily.

pyrale 8y ago

Imo, the problem is not with the title being too broad, but with your experience with event-driven architectures being too narrow. The author talks about general cases, and while respecting his rules in your particular situation is not going to give you much, it isn't going to cause trouble either. On the other hand, if you try to disrespect these advices in a different problem, you may run into huge problems, because the simplifications you made don't hold.

jayd16 8y ago

You do run into the same issues in something like a game. Lets say you have a character doing some animation clip and at the end you want to run some callback. That character could be killed by the player or the player could quit to the main menu or any number of things. Now your callback is stale. You have to deal with cleaning it up, ensuring it does actually fire if you need it to, and handling any issue with the now deceased character.

everyone 8y ago
Wrong again. You are obviously commenting about an area you are not familiar with. That is a very weird scenario. You dont want stuff like animation affecting logic. The game logic should never be affected no matter what the animations are doing. But if for some bizarre reason you did have that scenario, a way of doing it using a typical game engine approach would to put that callback at the end of a coroutine. If the character dies then no matter what is is you definitely dont want that callback to fire, (There shouldnt be logic being affected by an animation, but if that character is dead then it shouldnt be affecting anything at all) part of your game engine would be that coroutines do not run on things which have been destroyed.
- jayd16 8y ago
  Man, you're the one who said you were using events for game dev not me. Coroutines or events, the idea that you need to reconsider your state when execution returns is still valid advice. Tying a courtine to a game object's life cycle _is_ managing the event state. Its clearly not a weird scenario when entire game engines are based around this principle.
  - everyone 8y ago
    Well as I said having some logic executed by an animation would be doing things backwards... Most of the points in the article are about using an event driven architecture in the world of distributed systems, where the messages triggering events are delayed by a certain amount, can be lost, malformed, or different to what the receiver expects. None of that applies to a single program running on one machine. Thats why using an event driven architecture for a game is so great. I never have to worry about most of the stuff in the article. Also (as opposed to the more common Update driven model) if I do a good job its possible for my games logic to be flawless, it can be impossible for it to be in an illegal or weird state. So an event driven architecture in a game is fantastic for that reason, and the article is quite useless when it comes to event driven architecture in games. I'm sure its fine for event driven architecture in distributed systems, but the title is certainly too broad. Like with many of the articles posted here, CRUD / web devs forget there are other fields of programming.