As a former game developer who has worked in the Visual Simulation (VizSim) industry, I'd like to share my experiences. We all have read a lot about serious games companies that apply game technology to VizSim-like training and learning games. As you will see, there are a lot of similarities between the games industry and the VizSim industry that make VizSim companies attractive to game developers. Especially as it seems to be a more respectable and serious job and you'll probably get a thumbs up from your mom.

There are things that make the traditional VIZSIM simulation business different from what you probably will experience in the game business. These differences start with terms used for technology components that you've learned to understand. Prepare to no longer say ‘render engine', but ‘computer image generator' (CIG) instead! The focus of the simulation of the world is different for the VizSim industry but most fundamental techniques are the same.

My impression is that games have superior technology in various contexts that are relevant for both industries. Still, games don't provide the same sort of simulation fidelity that simulators do – partially because there is no need to do so. I'll try to shed some light on more details while explaining the training simulator environment.

The following text is not intended to be a general text about the VizSim industry – I obviously can only tell you how it works where I worked, and how it compared to my time in the game industry.

A few years ago I was working for a games and game technology company as the head of development. Unfortunately this company became defunct with the dot com crash. Since I did not want to relocate my family again, I tried to find a nearby position. On an online job portal, I stumbled across a job ad saying ‘OpenGL' and ‘visualization.' These are among the things I am experienced at, and I applied for the job. Funnily enough four of my former colleagues had also applied for other jobs at the same company, and we all ended up working there.

The company we worked for mainly builds tanks and armored vehicles. They also have a division that builds training simulators for everything that drives on the ground (i.e. cars, trucks, tanks, trains, metros and subways). In addition to driving simulators, they also do training battle simulators for all sorts of tanks. Since people who buy tanks are also interested in training equipment for these tanks, especially simulators, the simulation division profits a lot from its big ‘mother.' This text will mostly cover military simulators since this is what I worked on.

The project I worked on was a networked battle tank simulator. It used 13 PCs per cabin to render 13 different views from inside the tank. The simulated and displayed world was up to 80 x 50 square kilometers big and 110 tanks plus effects had to rendered at constant 30Hz at 4xAA and 1280x1024. Trees and houses in the database were supposed to be destructible. Dynamic craters from artillery impacts and dynamic track marks from all tanks had to be supported. Furthermore, dynamic shadows from all major scene parts due to a moving sun had to be rendered. Lighting with dynamic and moving light sources also needed to work. In addition to normal views, various sensor imaging techniques that simulate IR or light amplifier devices had to be implemented. All of this in isolation was no problem, but given the size of the scene and a visibility range of over 5.5 kilometers the task was demanding.

The budget for a simulator varies a lot depending on the kind of simulator to build. A complicated training simulator with multiple networked cabins has a budget that can be compared to that of a AAA title, or may even exceed a AAA budget. In general, though, the budget for a civil simulator is well below that of a AAA title.

Hardware is an important part of every simulator. A big chunk of the budget for a training simulator is spent for hardware. This means there is less money available for software and asset creation than for an AAA title. For one project the hardware even included the construction of a building that actually contained all the training equipment.

In general the hardware is a cabin (see e.g. http://www.sdtb.kiev.ua/sdtb_train_en.htm) with an interior that is more or less a perfect copy of the cabin of the real vehicle. All switches, steering wheels, knobs and other equipment are present in the simulator cabin, and are functional as in the real vehicle.

For some simulators the cabin is mounted on a hydraulic motion system that provides motions inside the cabin that are perceived as acceleration, deceleration or other forces acting on the vehicle.

	A turret training simulator

Turret training simulators feature a cabin that is actually a copy of the real turret of a simulated tank and can weigh up to several tons (see e.g. http://www.c-its.com/svensk/simulation/CATS_Turret_Leo.html). The turret sits on electrical motors that rotate the turret and its inhabitants based on handles operated by the gunner. Turret trainer hardware also moves the gun up and down and even allows for training reloading of the gun. In addition to the gunner other positions of the tank crew members are also supported and are provided with artificial visuals.

Visualization for simulators does not always happen on monitors, but very often on non-planar projection screens that show edge blended projections of the images computed by several CIG (computer image generator) computers and projected by expensive projectors.

Each simulator features a bunch of computers doing vehicle simulation, physics simulation, sound simulation and visualization. So it's not at all like the hardware environment of a computer game where there is exactly one computer doing all the work. All this hardware needs to be controlled by software, of course, and this is where we begin to see more similarities to game development.

I'll now try to give some insight into the different software components that run inside a simulator – most of run on their own dedicated computer or even on more than one computer. Very often, simulation software is a distributed software system.

The relatively big number of computers in one simulator is a very astonishing thing for a game developer. I still ask myself from time to time – how can one need so many computers for tasks that run on one computer in a typical game? There are obvious reasons for some of the computers to be around, especially for visualization, as we will see later. One thing to consider, though, is OS boundaries – e.g. real-time 3D rendering happens on Windows PCs, whereas the rest of the simulation usually happens on Linux PCs. Most of the simulation software is written in ADA - a semi-dead language that actually is pretty nice if you take a closer look at it. Again, real-time 3D software is written in C++. Although there are ADA compilers for Windows, the simulation people I workede with feel a lot hate and disgust for Windows and simply don't trust it, thus limiting their solution space.

At least one computer per simulator cabin, usually called the ‘Simulation-Host', polls all input switches and handles of the cabin hardware to simulate the inner state of the vehicle. The Simulation-Host also talks to a software component that provides a spatial index for collisions detection and collision response for the physical simulation of position and orientation of the simulated vehicle.

The Simulation-Host learns about the other entities in the simulation world only through TCP/UDP data using the simulation domain standard protocols DIS (short for Distributed Interactive Simulation – see (people.freebsd.org/~jha/aboutdis.html) or HLA (www.informs-sim.org/wsc98papers/227.PDF) using multi-cast or broadcast. Other entities are other simulators or AI vehicles which are called SAFs (Semi Automated Forces) or CGFs(Computer Generated Forces) in the VizSim world.

The rules of DIS are easy; the Simulation-Host is only allowed to tell other simulation participants about its own state changes. It can't for example determine if it has destroyed any other entity by the shot of its main gun. What it is allowed to do is to tell everybody that it has caused a detonation at a specific location. To decide if other entities take damage from this detonation is up to the software simulating the states of these entities.

The Simulation-Host also talks to the computer running the visual systems or CIGs that produce the real-time 3D views for all windows or other viewing devices inside the vehicle. I'll talk more about 3D rendering later. Simulation-Host also talks to a sound system component to produce sounds as heard from inside the vehicle.

The Simulation-Host is what in the games domain is the player object or PC (player character) and its simulation. The SAFs are the VizSim world equivalent to NPCs (non-player characers).

Since the simulation of a tank, all its states, all its optics and other components is pretty complex, a whole computer is allocated to this task. Because a modern tank has a computer that shows a tactical map of its surroundings and a way to transmit tactical symbols to friendly tanks in an encrypted data format, it also needs to be simulated as well as radio messages between all tanks in a scenario.

A few words on physics – the VizSim industry does not seem to use much physics middleware like Havok or MathEngine. They do have pretty advanced custom physics simulation software for tank physics, train physics and so on, but no general rigid body physics software. For a game physics developer, a VizSim company might be a good choice because they are just beginning to explore things like full rigid body physics, soft-body or even cloth simulation. The physics solutions are not as refined in terms of mathematics used – I did not see techniques like adaptive time steps, runge kutta or other integration techniques at work (such as implicit integrators, verlet integrators etc.)

All artificial vehicles (NPCs), aircraft, human characters (usually called DIs – dismounted infantry) are usually simulated by yet another computer. Let's call this computer ‘Battlefield-Simulator.' It does all the motion planning, strategic planning and animation control for AI entities. The algorithms and data structures are the same that are used in the game industry, e.g. A*, influence maps or state machines of various flavors. For the project I worked on, an integration of an AI middleware was one of the ways of trying to cope with the immense size of some of the simulation worlds that were used and showed impressive results.

The world simulation also sends positional and other updates via DIS for all simulation participants to inform them about these entities. Therefore, you could call it the MMOG server of a training simulator. There are examples of simulator scenarios that have featured thousands of participants that were all connected via DIS and were spread across several continents.

AI seems to be the area with the most similarities between games and VizSim. My impression was that games have the more advanced AI technology. One thing to consider though is that not every cool AI produces effects that are good for creating reproducible exercises – which is what an VizSim instructor wants. A game has to look cool and must be fun to play. Training simulations that have the goal to as closely as possible mimic existing technology and real scenes in order to fulfill training objectives. The training objectives are not to make a simulator fun to play with, but to achieve a training goal. The requirements that need to be fulfilled to achieve the training goals might even affect things that games just leave out because they are hard to achieve. This might not be possible if a VizSim customer insists on a specific requirement.