Summary
This experiment art of a project I was part of during
my time at the Swedish Defense Materiel Administration, FMV.
The goal was to make a proof of concept demonstration of the feasibility to inject a very highly detailed, non real time, damage assessment simulation into the game-play of a training tool roughly equivalent to the commercial game ARMA II in order to asses vulnerability of various platforms in a somewhat realistic tactical setting. The training tool is called Virtual Battlespace and at this time it was at version 2, VBS2.
The experiment
My job was to develop the VBS2 side of the experiment which had the role of being the server side of the experiment and included:
- Develop a C++ plugin to the scripting interface of VBS2 to act as network server.
- Co-develop the protocol to communicate with the other part called AVAL.
- Implement the resulting damage as best possible in VBS2.
The first step was to analyze what real world processes would be affected and how that
was represented in VBS2.
The image below shows the major phases of what takes place when a tank
fire a round at a target.
Here is a breakdown of the sequence:
- At A, a round is fired
- Between A and B is called internal ballistics and is of great importance as this is
where important properties as the projectiles speed and rotation is established. - The phase between B and C, just when the projectile leaves the barrel and starts it
trajectory through air, is called Transitional ballistics. This is important as it
influences accuracy and can have a significant effect on the projectiles velocity by
interactions with the atmosphere and the out-rush of gases from the barrel. - Between C and D the projectile is only affected by environmental effects
such as wind and obstructions and follows a fully deterministic trajectory unless it
hits an obstruction or is a powered and/or guided missile. This is known as
external ballistics. - Terminal ballistics occur between D and E in the figure. This phase deals with
what happens shortly before and including the physical impact. - The chain of events set in motion by the terminal ballistics determines if any
damage is caused to the vehicle and if so what types of effect it has, represented
by F.
In this sequence we were quite happy with how VBS2 was doing things up to point D. So,
this was where the focus of my modifications and integration of the external tool would
happen.
Developing the Solution Concept
At first, I assumed VBS2 handled this somewhat like this:
The straightforward approach would be to aim for something like the modified version
showed below. The concept would be to introduce a new actor, an arbitrator, that catches the Detonation message and does its own damage calculations based on the kinematic state of the projectile at detonation and what type of projectile it was.
Then it would in turn tell the target what kind of damage it got, if any.
The idea being that we could run AVAL in another process or even on another computer
communicating asynchronously over a socket connection. In a previous project I had
developed a plug-in that communicated with another system, so I knew this was possible
using VBS2s scripting interface.
Detailing the Concept
I researched what events, functions and properties in the VBS2 engine and assets that related to weapons fire and taking damage.
The result was that it should be possible to implement something close to the concept I had envisioned. The revised concept now looked like this:
Modifying the VBS2 Assets
In VBS2 each vehicle is packaged as a reusable asset that can then be freely instantiated in
a scenario. To make the system work I had to add script code to existing assets and create
a new version that inherits the original and overrides what is needed.
An initialization script is run by the engine each time the asset is instantiated if present, I
used that to prepare each vehicle with event handlers for the built in HitPart event that is
triggered when the vehicle is damaged, and the custom event AvalDamageReport that will
contain the result of a single hit as calculated the AVAL damage assessment program.
This is not the final version of the code but looking at it I, one thing I would have done
differently is to factor out a subroutine or two to handle the repeating damage
simulations.
Lessons Learned
It was a fun project to do and it worked out quite well in the end. We successfully demonstrated that this could be done and utilized to get a more accurate simulation of vehicle damage in a tactical environment.
One of the most persistent challenges was a constant fight against the game AI to suppress it. VBS2 has a a rather capable scripting system that allows for some pretty impressive extensions of the base programs capabilities but unfortunately I could not figure out how to reliably control the AI and some oddities was a result of that.
One problem that showed up in testing was that some vehicles seemed much less effective than others. It turned out that at first modest damage, the AI had the crew leave the vehicle and thus never fired back. This was difficult to suppress as we could not pick and choose what parts of the original AI to run, so either we had to disable it all and build a new one or we could react to what it did and reverse that. We did the latter but it was not quite satisfactory.
Another problem was dealing with coordinate systems that did not match, local and
global coordinates etc.
The lack of standardization was also a major obstacle.