VBS2Fusion, another look at the API

Previously on this blog, I covered the VBS2 Application Scripting Interface, or ASI (here). As identified in the paper listed there, there was a need for a proper API to allow a C++ Developer more access and control over VBS2. While details are sketchy, there are a few things we know for certain, one of those being that VBS2Fusion is a separate module that may be purchased by those looking to gain more control over the simulation. Additionally version 1.0 is set to give us an extension to the ASI, with version 2.0 delivering even greater control beyond that.

So what is the benefit to the end-user? it simply allows the decision makers a greater choice when outsourcing development. The API requires less of an understanding of the VBS2 scripting language, instead requiring someone with a sound knowledge of C++. This may sound like a negative, in some respects it may be, but for the most part it allows almost any C++ developer to get in the guts of the simulation. The limitation in the ASI is that, while it allowed the interface between external applications and the simulation, it required that the programmer know and understand the VBS2 scripting language. ASI applications had to use simple script commands, and generally to get more bang for your buck, a script in the scenario or in an addon was required to back up the ASI functionality.

The API now allows the extension of VBS2 through various C++ libraries (some of which opensource), to deliver more functionality. Additionally there also seems to be the implication that VBS2Fusion will allow a greater degree of control over VBS2 Agents adressing a shortcoming in the ASI, which relied on scripted move/doMove commands. A perfect example of what can be done with the API is VBS2 Fires, effectively a heavyweight desktop based call-for fire trainer, which is extensible through hardware as seen in the full-blown call-for fire trainer. VBS2Fires offers an external interface to the instructor allowing them to provide cost effective desktop based training to trainees. The module provides highly detailed exterior and terminal ballistics models, that weren't as easy to simulate until the API came about. This allows you to put the FO into play in the combined arms environment, providing them more opportunity to work directly with units they may be embedded with.

Other possibilities include greater potential for external hardware interfaces that interact directly with the simulation. There would be very few reasons that many crew procedural trainers on the market aren't capable of running VBS2 for visualisation, and as a result allowing direct integration into the combined arms environment VBS2 provides. This goes well beyond even the AVRS capability which has seen success in the Australian Army. Beyond the hardware I'll borrow one example from the flight simulator community, VBS2Fusion may allow access to external weather data to update conditions seen on the ground in VBS2 itself.

To the soldier, and their instructors, this just means that simulation has a chance to have a greater share of the pie in the training continuum. Higher up, VBS2 will have more capability through the API and to organisations with C++ Developers or capable of outsourcing their development, there will be potential there to expand the functionality well beyond what has been seen so far. VBS2Fires is literally just the tip of the iceberg, yet having said that, it is quite an impressive demonstration of the ability of simulation to satisfy a training need.

Jamie.