Investigators: Dr. Rudy Darken, CDR Joe Sullivan, & Erik Johnson
There has recently been much interest in the use of gaming technologies as a potential replacement for traditional visual simulation tools in military simulation and training. We submit that growing interest in gaming engines is not so much an endorsement of gaming technologies for military simulations as much as it is an indicator of serious dissatisfaction with currently available visual simulation tools. While we agree that there is much to benefit from investigating the use of these technologies in our programs, the direct use of gaming engines is problematic for several reasons:
- Gaming companies are not in the business of selling or supporting development software -- they make games. Their gaming engines are their "edge" on other gamers. They guard them closely and want tight control on their use.
- The requirements of making a successful game vice making a successful training or simulation system are vastly different -- we play by a completely different set of rules.
The question remains: How do we reap the benefits of gaming technologies without limiting our capabilities to produce effective training and simulation systems? We believe there is a two-pronged approach to solving this problem.
- Develop a software framework for our systems that supports the software development model gamers use. We need to take a gamer's approach to developing simulation and training software, but this doesn't necessarily mean we use a gaming engine.
- Integrate the functions of constructing a simulation (e.g. identifying what is in it and how it all looks or sounds) and specifying behaviors (e.g. typical combat modeling tools such as JSAF or OneSAF for scenario development).
It seems clear that neither gaming companies nor visual simulation tool vendors have a scalable, usable solution that adequately fits our needs. We make do with what we have, but it seems clear that the interest in gaming engines for military simulation and the slow progress in using them (How many current programs do we know of that are using a gaming engine for visual content?) is evidence that even the gamers don't have the right answer. But this shouldn't surprise us; this isn't their business model. So how can we combine what we like about gaming engines with what we like about visual simulation tools and SAF tools towards a better solution for military simulation in general?
This proposed effort involves the development of a "simulation engine" that leverages the Open Source movement to the greatest extent while providing DoD with a simulation development tool specifically suited to their needs and requirements that mixes the power of gaming engines with the robustness of visual simulations.
There are a great many excellent open source tools available today, none of which solves our problem by itself, but when properly fit together these could create an excellent scalable solution. What the DoD modeling and simulation community needs is a focused effort to fit these open source tools together into a unified API that addresses the unique needs of our programs, and then makes that tool widely available to all DoD programs. We propose a "best of breed" approach to visual simulation tool development using all open source resources. There are several advantages to this approach:· We need not support the code at its lowest level. This is the benefit of using open source tools. Moreover, if one open source tool is better than another, the framework can be built to swap tools such that users do not see the change (hence "best of breed" architecture).
· We can continue to support DoD standards such as DIS/HLA by extending the capabilities supplied by the open source tool.
· There are NO LICENSING COSTS in this model. This is far less expensive than every site paying for the same tools and then paying again when it comes time to deploy. This model simply does not work for DoD anymore.
We believe that game development is clearly more efficient than what we do in visual simulation. There is less redundancy and they tend to have the right people working on the right aspects of the game; behavioral content developers only develop content and write script and code, artists only develop visual and audio content. However, their software is only minimally supported as compared to visuals simulation tools. They do not support DoD interoperability standards. They are usually constrained to a single display with keyboard, mouse or joystick input devices. The proposed simulation engine adopts the gamer's development procedures and combines it with the functionality of visual simulation tools and a cost structure that works for today's DoD programs.
1. Integrate scene graph with high level API to support basic visual simulations.
2. Add audio capabilities, networking (DIS/HLA).
3. Add avatar support, input and output devices.
4. Link to combat model software (JSAF/OneSAF)
5. Support for collision detection and physically-based models· The plan is to migrate away from high cost tools that do not really fit our needs towards this tool which is designed for DoD specifically. Capabilities developed from Task HPE-1 and Task HPE-2 will be integrated into this tool and it will be used in the classroom environment described in Task MS-3 as well. · Eventually, this task should combine with Task NVE-2 (NPSNET-V) where the unique dynamic extensibility capabilities developed there are combined with the high fidelity rendering, audio, and networking capabilities developed here.
