Computer war games have considerable training potential, but more
often than not require significant modifications before they gain
acceptance by the military and generate any profits for the developers.
That’s the experience of Jim Lunsford, a senior simulations
designer for Mak Technologies, in Cambridge, Mass. Lunsford served
as an infantry officer and a tactics instructor at the Army’s
Command and General Staff College.
He is also familiar with commercial off-the-shelf (COTS) software.
Based on his experiences as an instructor, Lunsford created “Decisive
Action,” a division- and corps-level hobby war game that has
also been used by the U.S. Army.
Lunsford suggested a path for both government project officers
and the designers of COTS software to follow in developing training
aids for the military.
Project officers should identify the specific need that can be
fulfilled by a COTS war game, he explained. “You don’t
want to end up having something that doesn’t have a real purpose
for it,” warned Lunsford. Game designers and companies have
a natural tendency to claim that their games can be used by the
military, but that doesn’t guarantee that they have actual
training value, he said.
Project officers also need to beware of broad designs that attempt
to satisfy so many needs that they satisfy none. As for COTS developers,
“always remember you are building a military trainer first,”
Lunsford says. Any future plans to base an entertainment version
off the militarized version must be secondary.
The government project officer must clearly and concisely define
the requirements, including the intended training audience, training
and learning objectives and the intended training environment. The
requirements document should only be a few pages. Anything longer
will be so complicated that the project will not be finished on
time and within budget, he cautioned.
Mutual understanding is key, Lunsford added. The requirements document
should be clear enough to let COTS developers know exactly what
they’re getting into before they commit to the project. At
the same time, developers not accustomed to working with the government
need to understand that the process is slow, frustrating and confusing.
It can take a long time to get paid, he said, noting that contract
deliverables must be submitted on time.
Using the requirements document as a starting point, the project
officer and developers need to reach an agreement over what exactly
is being created, contract deliverables and the work schedule. Avoid
“requirements creep,” he stressed.
He said the developer must have sufficient time visiting and meeting
with the customer to understand his needs, training environment
and culture. The developer should also observe first-hand whatever
military training that the simulation is supposed to enhance or
replace. Everyone must understand that no major decisions may be
made without agreement from all parties, he said.
Developers, Lunsford stressed, should stay focused on the training
audience and training objectives and use appropriate fidelity. What
doesn’t need to be explicit can be abstracted.
“If you’re building a sim to train a division commander,
then you don’t need to model the specifics of a TOW missile,”
Lunsford said. “If he’s not going to be involved in
the decision to launch a TOW, then why model it?”
Design the graphic user interface for the military trainee, not
for another engineer or a civilian gamer, he said. Most military
personnel prefer a plain Windows interface to a cool-looking one,
The project officer and developer must participate in spiral development,
he asserted. Create sequential prototypes that are tested by users.
Incorporate feedback into the next prototype, Lunsford explained.
He advised developers to remember that at the end of the contract,
they must deliver a reliable, working trainer that achieves its
intended purpose. If not, everyone has failed. Also understand that
it will not be perfect, he said. It’s almost a guarantee that
more dollars will be needed to enhance and modify the trainer once
customers have a chance to use it.
He also recommended that developers budget time and money to train
the trainer. Like all tools, a simulation is only as effective as
the instructor using it. “Trainers need a bunch of skills
sets,” Lunsford said. “I normally spend a full day training
Trainers don’t just need to know how to run the simulation.
They also need to understand the concepts behind it. Equally important,
they need to know how to handle technical support issues to keep
the simulation functioning, he noted.
Lunsford believes that the best results come from COTS projects
where the developers and government action officers are familiar
with both gaming and gaming technology.
“They know what they want. They have an expectation that’s
more realistic than someone who doesn’t know what a game is
about. If someone doesn’t have the experience, they depend
more on the developer to provide strong input.”
Lunsford emphasized that a COTS project include a subject matter
expert. “You need a team with a good mix of talent, including
a good military expert who also understands gaming technology. If
you’re developing on your own without adequate support, you
focus on the details, and that’s what really bogs you down.
What helps is finding someone who can help you focus on what is
critical,” he advised.