Corporate Training Product

Most VR Interaction Systems follow a Command Based Behavioral Design Pattern, where an Controller or interacting object delivers commands to the an Interactable or responding object. This approach is popular because it is intuitive and conceptually is like real life. For example a hand issues a pick up command to a cup, then the hand issues a drop command releasing the cup. However, this approach introduces scalability problems as the hand needs to be aware of all the different commands it needs be capable of. 

​

Instead, I pushed for an Observer Behavioral Design Pattern. This means nearly all of the functional logic belongs to the Observer or Interactable, rather than the Controller. In consequence, the Controller only needs to know commands that wake up an Interactable. The Interactable can then choose whether or not the necessary criteria have been met to begin observation of the Controller. During the Observation state, the Interactable can respond to Controllers state without the controller needing to issue alternative commands. Using our hand and cup analogy, the hand issues a grab command to the cup. The cup responds by entering its Observation state and attaching itself to the hand. The cup then observes the hand and sees that the hand is no longer performing a grab gesture. The cup proceeds to release itself from the hand, falling to the ground. This means when creating new Game Play Mechanics augmentation to Controller Code can be kept to a minimum. Polymorphism allows for new Interactables to be easily created as they can can inherit common functionality from base classes.

​

Fantastic, our ToolKit is now flexible and highly scalable. However if improperly implemented the Observer Behavioral Design Pattern may show a critical flaw. The observer may be continuously observing the Controller without any changes in the Controller's state actually being made. In Unity, the observer may be performing Observations in its Update function. This means wasted message calls, resulting in additional performance left on the table. We eliminate this flaw from causing any possibile problems by introducing a Publisher-Subscriber Relationship between the Controller and the Interactor. By exposing C# Event Delegates inside the Controller for each major state change that can occur. Now when the observer enters its Observation State, it can subscribe to the different events that notify it of changes in state that it cares about. This also has a additional benefit to scalability. Instead of writing code respond to changes in state of the Controller as a whole. The programmer can easily create mechanics by picking and choosing between states that its he or she interested in to create different effects. For example, after a drill is picked up it listens for a change in the controllers trigger state in order to activate its motor.