Yes. It is a very efficient way for game systems to communicate with each other. Events help you decouple many systems and make it possible to even compile things separately without knowing of each others' existence. This means your classes can be more easily prototyped and the compilation times are faster. More importantly, you end up with a flat code design instead of a dependency mess.

Another big benefit of events is that they are easily streamed over a network or other text channel. You can record them for later playback. The possibilities are endless.

Another benefit: You can have several subsystems listening for the same event. For example, all your remote views (players) can automatically subscribe to the entity creation event and spawn entities on each client with little work on your part. Imagine how much more work it would be if you did not use events: you would have to place Update() calls somewhere or maybe call view->CreateEntity from the Game logic (where knowledge about the view and what information it requires doesn't belong). It's hard to solve that problem without events.

With events you get an elegant and decoupled solution that supports infinite number of objects of unlimited kinds that can all simply subscribe to events and do their thing when something happens in your game. That's why events are great.

More details and an implementation here.

Yes. It is a very efficient way for game systems to communicate with each other. Events help you decouple many systems and make it possible to even compile things separately without knowing of each others' existence. This means your classes can be more easily prototyped and the compilation times are faster. More importantly, you end up with a flat code design instead of a dependency mess.

Another big benefit of events is that they are easily streamed over a network or other text channel. You can record them for later playback. The possibilities are endless.

Another benefit: You can have several subsystems listening for the same event. For example, all your remote views (players) can automatically subscribe to the entity creation event and spawn entities on each client with little work on your part. Imagine how much more work it would be if you did not use events: you would have to place Update() calls somewhere or maybe call view->CreateEntity from the Game logic (where knowledge about the view and what information it requires doesn't belong). It's hard to solve that problem without events.

With events you get an elegant and decoupled solution that supports infinite number of objects of unlimited kinds that can all simply subscribe to events and do their thing when something happens in your game. That's why events are great.

More details and an implementation here.

Yes it is a very efficient way to have your game systems communicate with eachother. Events help you decouple many systems from eachother and make it possible to even compile things separately without them knowing about eachothers existence. This means your classes can be more easily prototyped and the compilation times are faster - and more importantly: you end up with a flat code design instead of a dependency mess.

Also, one big benefit of events is that you can easily stream them over a network or any other channel. And you can record them and then replay them. The possibilities are endless.

Another benefit is that you can have several subsystems listening to the same event. For example, you can have all your remote views (players) automatically subscribe to the entity creation event and spawn entities on each client with very little work on your part. Imagine how much more work it would be if you did not use events: you would have to place Update() calls somewhere or maybe call view->CreateEntity from the Game logic (where knowledge about the view and what information it requires does not even belong). So without events you end up with a complicated problem that is not easily solved in any other way other than using events.

With events you get an elegant and decoupled solution that supports infinite number of objects of unlimited kinds that can all simply subscribe to events and do their thing when something happens in your game. That's why events are great.

More details and an implementation here: http://stackoverflow.com/a/22703242/2929762

Yes. It is a very efficient way for game systems to communicate with each other. Events help you decouple many systems and make it possible to even compile things separately without knowing of each others' existence. This means your classes can be more easily prototyped and the compilation times are faster. More importantly, you end up with a flat code design instead of a dependency mess.

Another big benefit of events is that they are easily streamed over a network or other text channel. You can record them for later playback. The possibilities are endless.

Another benefit: You can have several subsystems listening for the same event. For example, all your remote views (players) can automatically subscribe to the entity creation event and spawn entities on each client with little work on your part. Imagine how much more work it would be if you did not use events: you would have to place Update() calls somewhere or maybe call view->CreateEntity from the Game logic (where knowledge about the view and what information it requires doesn't belong). It's hard to solve that problem without events.

With events you get an elegant and decoupled solution that supports infinite number of objects of unlimited kinds that can all simply subscribe to events and do their thing when something happens in your game. That's why events are great.

More details and an implementation here.