You should avoid stacking up Music Switch Containers. Although it is supported, it might not behave as you expect.
Music switch containers are transition schedulers, which Transition Matrix may specify rules for any their descendents (down to segments). There
is one Transition Matrix per container, and containers are only aware of their own, not of that of others.
On the other hand, switch containers are able to monitor what segments are playing, even if these segments were scheduled by switch containers below them. When a parent switch container schedules a transition, it takes these segments into account. However, a child switch container cannot perform a transition while its parent already has a transition that is pending, otherwise it would break the logical chain of segments which was used by the parent at the time it scheduled its own transition. Child switch containers always wait for their parents to reach steady state before they can even schedule a transition.
Consequently, a good interactive music design should use more than one level of switch containers if and only if:
- The state groups to which they are registered are logically independent. For example, GameMode [Menu, Game] and InGameState [Stealth, Stress, Fight] are somewhat independent, whereas PlayerHealth [Good, Bad] and PlayerWeapon [Strong, Weak] are probably not.
- You can clearly identify which state group has precedence over the other when it comes to scheduling transitions. For example, GameMode obviously has preceedence over InGameState: players stop caring about what happens in the game when they switch to the game menu. The GameMode switch container would thus be the parent of the InGameState switch container.
Refer to Understanding the Interactive Music Engine for more details about transitions scheduling.
