ABSTRACT
Gameplay audio code is actually quite similar in many ways to the code to drive UI elements. Both are representations of game entity state, need to monitor game entity state, respond rapidly to changes, and often require transitional behaviors and lifetimes that don't correspond exactly to those of the underlying game objects. It probably covers a large percentage of all the game sounds since game audio began, and even in more complex games is still a sizable percentage, especially in simpler and smaller scale games. In a game audio context, the Model is solely responsible for providing methods to query the current state of properties of game objects, whereas the View solely manages submission of state to the presentation layer of the audio. The ViewModel binds the two together, providing a way to translate game events and changing gameplay values into the control parameters understood by the game audio engine.
