Application developers need a robust platform to run VR applications. When running on a modern operating systems, a single process failing does not bring down the entire system. A VR system should behave in much the same way. A single component failure should not result in the entire VR system crashing. With a system as large and complex as a VR system, components are bound to fail or break. A tracker may be unstable, a cable may be loose, or the driver software may just be buggy. However, just because a single component has problems does not mean that it should affect the entire system.
The key to protecting the system from a single component failure is to keep the components of a system separated so that the interface between components can shield the components from failures. The interfaces can then provide a layer of protection between all the components. For example, the system may give a "smart" handle to an input device. The application uses this handle to reference a device instead of using a direct reference. In this way, the system can protect the resource by placing failure detection logic in the handle such that the handle will never return a reference to an invalid device. The application itself can protect itself in this way by using an application harness to separate the application from the VR software system.
VR systems are complex and as such, VR development environments are large and complex software systems. As with any large software system maintenance and correctness become important issues. How can we design a VR development environment so that is maintainable into the future? How do developers test for correctness in a large VR development environment?
Maintenance presents a problem in a large system because of inter dependencies within the software system. In a complex system, it is very difficult to completely understand every part of the system. If system components are highly intertwined, changes in one component could affect the correctness of another component. These dependencies are often very difficult to predict and take into account.
Maintenance is simplified by breaking the system up into many separate self-contained code modules. Each of these modules presents a single interface that can be accessed by other modules in the system. By breaking the system up into small chunks, it is possible for system designers to make changes within a module without affecting code outside the module.
Testing correctness in a large system is important because you need some level of confidence that the system will work. A common way to manage this is to separate the major system components into separate entities that can be individually tested and verified. The idea is that if a system is made up of many components and each of these components individual works correctly then, the combined system will work correctly (assuming the linking code works correctly). To test such a system, the components should be tested at many levels of granularity. For example in an object-oriented system you may want to test at object, module, and sub-system levels.