So I was thinking about how monolithic my classes get a lot of the time. For example, in the Character
class's Jump
method, one may have a reference to a sound effect object and play that. By itself that is fine but when physics, animation, collision, etc. are taken into account, the Jump method gets huge and the Character
class has a lot of dependencies to many different things. Still, this may be fine. However, what if we no longer want a sound to play when the character jumps? Now, we have to find that specific line of code in the jumbled mess of the Jump
code and comment it out or whatever.
So.. I was thinking..
What if, instead, there was some sort of AudioSystem
class and all it did was subscribe to random events it's interested in in other classes. For example, the Character
class may have a Jumped
event (static too, I suppose) that is raised within the Character
class in the method. Then, the Character
class would know nothing about the little sound effect that is played when the character jumps. The AudioSystem
would just be a huge class that the programmer could retreat to to hook up sound effects with certain events that happen in the game through the use of static events. Then, if it got too big it could be separated in to subclasses like EffectsAudioSystem
, BackgroundAudioSystem
, AmbientAudioSystem
, et cetera.
Then, in the options for the game, one could have a checkbox to enable or disable these sorts of sounds and all that would need to be done is just to disable that one system with a simple and single Boolean flag. This idea of systems could also be extended in to things like physics, animations, etc. to the point where most of the game responses resulting from player actions are hooked up through these elaborate and decoupled systems.
Okay, so my question may be a little vague, but how does this sort of thing sound? I haven't really ever heard of much kind of talk about this sort of system. This is all up in my head right now without any coding done so far so perhaps it's one of those "good in theory but not in practice" kind of deals. Would this kind of system work with a larger game or would it eventually break down and become even more of a spaghetti mess than the original system?