I'm wondering how effective it would be to implement event handlers in game objects rather than processing everything in a "ProcessEvents," or similarly named, routine. What I'm asking is how effective would it be to add, for instance, OnDeath, OnHeal, OnAttack, OnBeingHit, etc and so on events onto my game object code and manipulate the object data and state like that rather than processing everything in a single routine in each game loop? Would this ease overall object computation and management and let me use the built-in event system in .NET or would it, in fact, complicate things? Or, is it what I "should" have been doing all along?

My current hunch is that it would make programming the individual objects a bit more laborious but it could actually help scaling and such. Given that each objects events would be specific to that object it would make maintenance a tad easier as well as a change to the object code would update all its instances. Of course, conformity could be enforced by interfaces or abstracts so it wouldn't be a big deal from a code management perspective, really.

Thanks.

In general, it's a viable option, but won't be more scalable/performant. It tends to allow easier refactoring, adding new entities, reuse of entities and easier/more intuitive uptake by new developers. It tends to hurt debugging a lot, reuse of core components, and doing anything that can't be done in isolation or should be done all at once (an area of effect spell for example).

Like many design decisions, there are upsides and downsides.