The VRSimulator is designed to integrate fairly seamlessly into your VR experience. Remember, it's not meant to be a production-grade asset, however it is meant to be extensible and flexible to help you simulate your VR experience as comprehensively as possible.

Scripting Reference & Intellisense

We have thoroughly documented all of the public/static members, properties, methods, classes, etc. that are included in the VRSimulator.  This scripting reference is available to you:

• here in this user manual, and;
• within Visual Studio Intellisense.

In Visual Studio, you can get helpful suggestions, guidance, and commentary on the VRSimulator's exposed properties and methods just by starting to type. Visual Studio will provide helpful tooltips and suggestions so that you can both autocomplete bits of code and peek into the underlying documentation about whatever you're working with.

Namespaces

The VRSimulator is designed to operate within the Immerseum namespace, and it too has received a namespace of its own (perhaps unsurprisingly, Immerseum.VRSimulator).

When scripting with the VRSimulator, you can either reference stuff using its fully formed name or you can also use the handy C# using directive:

// Fully-formed approach - kind of long, difficult to read, and annoying.
using UnityEngine;

public class myClass : MonoBehavior {
    bool hmdConnected = Immerseum.VRSimulator.HMDSimulator.isHMDConnected;
}

// With a using directive - short and sweet.
using Immerseum.VRSimulator {
    bool hmdConnected = HMDSimulator.isHMDConnected;
}

Design Approach

When designing the VRSimulator, we have adopted a number of design approaches that have a significant impact on our scripting interfaces:

1. Singletons where we can.  Logically, you should only ever need one VRSimulator in your VR scene. Therefore, we're enforcing this in our design of the VRSimulator, where by design it applies the singleton pattern wherever appropriate.
2. Static where we can.  In order to make the VRSimulator hard to break and easy to work with, our classes only expose the properties that you're likely to use. For those classes that apply the singleton pattern, those properties are exposed as static properties so you don't need to worry about navigating to instances and the like.
3. Read-only properties are good. Many of the properties exposed by the VRSimulator are the kind of properties that are calculated on-the-fly based on the state of your system, the state of your user, the state of the VRSimulator, etc. Since they're the kind of properties you'd never need to set, they're exposed only as read-only properties. This includes the configuration settings.
4. Configuration via the editor.  Applying our philosophy of read-only properties are good properties, we don't let you edit (most) configuration settings programmatically. Configuration settings should be managed through the Unity Inspector to maintain stability and maintainability of your VR scene. (See: Configuring the VR Simulator)
5. I love a good Event. The VRSimulator is built on an event-driven model. Many of these events are publicly exposed, which allow you to "piggyback" on the VRSimulator's events and respond accordingly. This makes it really easy for you to layer your functionality in on top of the VRSimulator's, and thus make a really seamless integration between your code and our code. (See: Event Reference)
6. Abstracted and Extensible Input & Movement.  We've invested a fair bit of effort to come up with a comprehensive input and movement system that - by default - should be able to simulate most kinds of movement in your VR environment. But we know you might want to do your own thing and get creative with your inputs, with your reactions to inputs, with your movement, with everything. That's why we built an abstracted input / movement model that lets you modify, extend, or replace it altogether. (See: Configuring Input & Movement)

2017 Copyright © Immerseum Inc. All rights reserved.