|Not a member yet? Register
for full benefits!
'Simulations' and 'Games', Why the Difference?
Image from StreetScenes, an attempt to merge the 'simulation' and the 'game'
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
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
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
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.