Image from StreetScenes, an attempt to merge the 'simulation' and the 'game' as one.

The 'modelling and Simulation' community, has always distanced itself from the 'gaming' community, the two moving into separate camps, and neither touching the work of the other.

I once came across a snippet from a HCI conference that summed the problem up succinctly, without ever intending to:

"In a simulation, the user has control over the model, but not over the flow. That is, once I've entered my variables and made my changes, the simulation takes over until it is done. In a game, I have less control over the model, but more control over pacing of the game. So, even if there is a simulation running underneath, I am given more opportunity to pause and interact with the underlying simulation at any pace."

The above was the statement and feeling of Kenton White, CTO of Distil Interactive Ltd.

However, it seems to polarise the feelings of both segments of the same industry. Even in talks among experts and fanatics alike, we seem to use the phrase "games and simulations" a lot, almost as if they are two separate, discrete entities.

There are even examples today of people from simulation and modelling companies - long established ones - who have to be sent gaming-based resources direct to their emails, with words filtered out. Purely because the firms concerned consider gaming to be nothing to do with their business model, and set up filters to block and intercept.

The small, almost insignificant point about them actually being two sides of the same coin, often, seems lost.

Consider this, new, third scenario, in adjunct to the two pictured above:

In the initial, simulation set-up, the user has control over the model, able to change variables at will, and set up rules for the simulation to follow. Once the variables are set up and changes complete, the simulation begins. During the running of the simulation, events can be altered by hand, via interaction with the simulation elements in real-time as they progress. There is opportunity to interact with, even pause and change, the underlying simulation at any time.

So, after you have created a simulation of a bridge; you could set it running with a truckload of simulated weight to see what happens. Then, you decide to enter the simulation, and take control of the truck. Zigzagging across the bridge, you turn the radio on, music blaring out, as you see what the vehicle can do, careening about and handbrake turning an 18 wheeler. Said highly unstable truck happens to still be on the bridge, whilst the underlying simulation tries desperately to accurately model what is occurring as it changes in real-time. A swaying motion is set up, the bridge resonating with the vehicle's movement. No harm befouls the bridge.

Eventually more vehicles are added, to see how the bridge handles a distributed load. Still playing with the truck, you aren't paying much attention to the road, and strike a simulated smaller van at high speed. The truck jack-knifes, and the sideswiping heavy load wraps itself round a support column, overstressing the metal.

In a normal simulation, the problem would never have been found, but by adding gaming elements, it is proven, as the bridge comes crashing down, that an accident on the bridge, could very easily cause more than just a blocked carriageway.

Its time to put an end to the belief that games are not simulations, that they are somehow something very, very different. By using elements of both games, and old-style simulation, it is possible to create a third something (which undoubtedly will be pigeonholed as belonging to neither camp, rather than both) which has all the advantages of both mediums, leading to a far superior, far more dynamic, and reliable sim.