Events are extremely helpful for decoupling systems. For example, in The Sims Medieval, we have a class called DeathManager that manages all the sim deaths that occur. When a sim dies, the DeathManager is responsible for locking the sim in the Expire interaction, summoning Death (the grim reaper), and then dealing with the final clean up of destroying the Sim object. Right before the sim object is destroyed, it sends an event that anyone can listen to called kSimDied. That way, any system that cares can handle the death appropriately. If the sim was a professional sim, the profession manager can remove him, if the sim was a role sim or quest sim, the role system can remove him and choose another to take his place.

Without events, the death manager would have to know about every single system that cares about sim death. It really doesn't need to care about households, lots, family inventory, the bouncer system, the role system, the profession system, etc. If we decided to rip out the role system entirely or refactor it, we'd have to update the DeathManager as well. With events, we don't have to touch it. We simply stop listening for the death event, or perhaps have someone else listen for it. The point is, the DeathManager class is now decoupled from the rest of the code.

Of course, this comes at the price of obfuscation. Sometimes it's not clear what caused a particular event to fire or why someone perhaps didn't respond to it. Since events are often saved and processed elseware (like in EventMgr::VUpdate()), you can't easily trace the call stack back.

Another nice thing about events is that you can distribute processing across multiple frames. For example, let's say you have 100 events in your queue. You can loop through those events and keep processing them until some set amount of time has elapsed, then bail and continue processing the events next frame. You have to be careful that you don't starve your event system and lose events to slow frame rate.

-Rez

Game Programming is 2 parts art, 1 part science, and 1 part luck. Your question falls within the art side. You learn what needs events and what doesn't through instinct and trial & error, mostly. There's no hard & fast rule.

Regarding key presses, I do send an event for each keypress and mouse movement in my personal engine. I did something very similar on Rat Race back at Super Ego Games. I'm not sure how The Sims Medieval does, but I *think* we send events as well (I'm an AI programmer so I don't really have to deal with the input system).

If you think about it, input events are pretty rare too. A game runs at about 30 frames per second. How often is a keypress going to really change? Even if the player is constantly moving the mouse, that's still only one event per frame. In my personal engine, I have a limit. If the player simultaneously generates more input events than that limit, I ignore the extra ones.

The other nice thing about using input events is that they can be saved off along with the game time and random number generator seeds. By using this data, you've just created a simple little replay system.

-Rez

(edit: Spellcheck + Grammercheck = Win)

Rez seems to me game programming is 2 parts art, 2 parts science, 3 parts hard labor, 2 parts frantic debugging, and about 6 parts luck.

Hahaha! Fair enough, that's probably a bit more accurate. Some part of that is also dealing with stupid software. If I get that "Visual Studio is busy, please be patient" pop one more time, someone is going to have to die.

By the way, where did all my stars go? Shouldn't I have stars under my screenname? Did I overrun the star variable so now I have negative stars?

-Rez