In order to be usable, the VR development environment must provide support for the physical hardware devices in the local VR system, but almost as vital is how well the toolkit abstracts away the details of the low-level hardware interfaces. Do devices of the same type share the same interface, or are there specific APIs for each one? This comes into play when replacing hardware. For example: If an application has been using tracking system A, but a newer, better tracking system B becomes available, will the application have to be modified to take advantage of it? Preferably, the environment will support this with a change in a script or configuration file, without requiring any application re-coding.

A well-designed hardware abstraction is very important. While a less generic interface might be better able to take advantage of a device’s unusual features, the generic interface makes the application more portable and easier to upgrade, maintain, and understand. While major changes, such as replacing a joystick with a glove, might require rethinking the user interface, smaller changes, like switching one tracking system for another or changing between models of HMDs, should not require changes to the VR application itself.

The development environment should allow developers to easily extend the VR software system using simple programming interfaces. Users need to be able to extend the system when an application requires the use of customized interaction devices. For example, when creating a vehicle simulation application, it may be necessary to support a customized device that mimics the interaction methods of the vehicle being simulated. These devices commonly have non-standard hardware, which means the application developer needs to add a custom device driver to the VR system.

In addition to being easy to extend, developer should be able to add support for the custom devices without possessing expertise about the internals of the rest of the VR software system. Instead, they should only need to know about a small subset of the system that they can use to add device support in a straightforward manner. By allowing developers to easily extend the system, the development environment is able to change and adapt quickly to new advances in VR systems.

Extending the development environment’s functionality should not require any changes or rebuilding of current applications; extensions should be transparent to current applications. Current applications should be able to take advantage of the new extensions simply by changing the configuration parameters of the system. The configuration system parameterizes the settings of the VR system that is being used. This also means that an application compiled for use at one location’s VR system can be distributed to another location and run on the second VR system without requiring any changes to the application. Instead, the users only need to provide the configuration parameters for the new system.

An extendable parameterized VR system leads to applications that have longer lifetimes. I have personally experienced applications that have been running perfectly fine for years, but then the VR system changes and requires an update to the development system. This in turn requires all applications to be re-compiled. This is fine as long as the source code is available, someone knows how to compile it, and someone has the time, knowledge, and tools to do so. In any other case, this task can range from difficult to impossible. In a production setting, this problem is worsened by the fact that any downtime is costing the company. This problem can be avoided entirely by designing the VR development environment to allow extensions to be transparent to the applications.