 Serious
Game Design Traps
By Tim Carter (12 April 2007)
At the 2005 Serious Games Summit (which I did not report on
on my site), I remember one presenter saying something I thought
odd. He was promoting the making of serious games and said (to paraphrase):
Imagine if schools, instead of waiting for interesting new
games to come out, actually commissioned the making of these
games. An image jumped out at me when I heard this - a scene
from English class in high school. I saw myself watching the
teacher. We were studying authors. Plays. Stories. I remember my
love of that. Nobody commissioned those playwrights. Nobody
commissioned those authors to write a book that would be used to
teach children, teenagers, adults the important things of life.
They did it for the love of it - they took the initiative.
That's not to say they did it purely out of charity, but the
point I'm making is it isn't so easy as just ordering it done
and then watching it be done. There's a creative dimension to
it. And that entails understanding the creative process, which
involves risk. You can get it done - complete, working, on the
disc or hard drive ready for delivery or download for payment -
but the educational power it is intended to have still might
not be there.
That's the risk.
The idea promoted by the speaker seems to have gained a footing among organizations
now scrambling to get into serious games. Need to teach particle
physics, math, the history of the Renaissance, or the impact of
the printing press? Hey, just commission a game development
company and do it? Right? Simple.
Well... as a person who's been on the front lines of serious
game design I'd have to say no, it ain't that simple. (They used
to say this about writing screenplays: hey, anyone can use a
word processor so it must be easy, right? No. It isn't easy.) And there
are some pretty awful serious games coming out now.
What are some of the traps that can lead to a completed,
graphically beautiful but ultimately valueless serious game?...
The "Game-Based Technology" Trap
To me this is probably the number one trap of would-be
serious game designers. Often they are already involved in the
modeling and simulation industry, or conventional training, they
see these new games, and realize how cool the technologies are.
So they believe that if they just take those technologies and
graft it onto the same old same old, that makes them a good serious
game developer.
Well, I'm sorry but it doesn't.
There is this tremendous temptation to look at serious games
as, essentially, a byproduct of technology. Why wouldn't there
be: technology provides such beautiful graphics, and people
essentially believe what they see (computer graphics).
Technology is a huge barrier to entry for computer serious
games. If you can master that barrier, at least you can get the
game out there.
But here's the question: Once you get it out there, does
it have legs? Does it work in its guts? Does the audience
buy it and does it lead to real training benefit? Or is it just
really good-looking, graphically-beautiful (pardon my English)
garbage?
I worked for one of the premiere serious game companies,
BreakAway, and most people don't realize that a core
strength of that company is that it is staffed with ex-boardgame
designers from Avalon Hill. You may sneer at this, but not if
you are a game industry veteran. AH designers and their ilk,
back in the day, would typically spend a year researching and
designing a game - be it about the advance of civilization, or
sports management, or a Napoleonic battle, or a WWII campaign,
or a simulation of building a railroad company, or what have
you. When you do this, you think in clear terms how to build
meaningful game design. Today many AH games appear complicated
compared to the current generation of boardgames, but they came
out in a time before computers. I still like to play them now
and then - they still ring true (and some of today's boardgames
I find a little oversimplified). Many of the AH veterans went on
to work at Firaxis (and other companies) and have been
responsible for a lot of quality computer games.
The point here is to understand the difference between game
design and game programming. Knowing how to use the technology
is not going to save you from making a really bad game,
one that looks great in screenshots, and runs stably, but
still finds itself collecting cobwebs because nobody uses it.
The "Think-Tank" Trap
Having a PhD doesn't qualify you to make games. Being able to
study them and being able to design them are two different
things. Think of all the premiere game designers out there, like
Will Wright, Sid Meier and so on. How many work for schools?
I'm not sure where people get the idea the greatest advances
in game design come from schools. (Yes, some great technology
advances have come from parties linked to, or fresh out of,
universities - think Havok - but that's not the subject here.) If you
look at history you see they come primarily from independent
developers. I suppose this myth comes from the notion that if a
person knows how to teach a subject that qualifies them to make
a game about it. Well, Socrates never wrote anything down
(leaving that bit to his protégés) - he was a much better
teacher than an author.
There is just something about the academic environment that
can slow things to a snail's pace.
When I worked for Washington Hospital Center on
Code Orange, I saw they
specifically emphasize practical, real-world action and
experience over classroom-oriented dialect, theoretical musing
and so forth. They generally take a dim view of partnering with
universities on research (even though they are a teaching
hospital) because they are involved in emergency medicine and
prefer practical training. In that world you have to learn how to act fast because if you
don't, people die. The best way to do that is to get out of the
classroom and into the real world.
But to some official funders there is a comfort-level
associated with putting R&D money into an official institution
versus a small garage startup. (At least they know the funds
won't be blown on beer.) Yes, it's true a lot of brilliant
students come out of universities. But universities also have a
lot of "career students" - people with lots of great ideas but
no clue how to apply them to the real world; or people who love
to take problems apart to study them, but are unable to make the
leap of then translating this knowledge into a creative and
beautiful work with syntax and form. A game is not a dissection
of a subject, like a textbook or a course (though dissection of
its subject is necessary in the research phase). It is a
creative work that assembles its knowledge into a single form, a
form that needs to flow and hit the road running. If you want to
define it in terms of technology development think of science
versus engineering. The universities are more interested in the
science of things - making prototypes only to learn about
something. The engineers, on the other hand, are in it to make
robust products that can be practically used in the real world.
I find it a little dismaying seeing all these R&D dollars
being offered to games provided their developers are attached to
educational institutions. The world's best game designers are
out in the field, not dreaming in ivory towers.
(Addendum: There seem to be some schools that are getting out
of the Ivory Tower trap, and tackling the issue of making stuff
out in the real world - for example, having practical policies
that encourage - not merely tolerate - the development and
marketing of useful intellectual property while in the classroom
/ lab environment. I also note Guy Kawasaki puts particular
emphasis on the benefits of engineering schools - though he is
mainly focused on straight-up software development projects,
which are a little different than games and serious games - so
respect that opinion. Anyway, the main point is that, school or
no, my opinion is the focus needs to be on getting in the
trenches - delivering practical, working stuff.)
The "It's All About Graphics" Trap
This one is straightforward. A confusion of game design with
graphics. It's a trap professional game designers fall into
as well.
This one is not about technology - though it is close to that.
It's about superficiality. It's about the temptation to think
that because something is good-looking it is also good.
According to Jung's theory of the personality (which gave us
terms such as introvert versus extrovert, the Meyers-Brigg
Personality Test, and so on - and everyone has a little of all
the personality types), the sensory personality type has this
flaw: it doesn't go under the surface; it tends to judge things
based on appearances. Applied here, going ga-ga over graphics is
a superficial reaction. It's sensational, in the most
literal definition of the word.
This, too, is why I cannot espouse tabletop game design
enough. It forces you to design efficiently at the gameplay
level, and when you show the prototype to the client you can't
hide behind the graphics - the client instantly gets to look
under the hood.
If you look under the hood of many computer games you will
find they are rife with tricks that players never realize are
being played. For instance, in the original Sim City,
people were just amazed at the traffic simulation - when your
city builds up in density you can get problems with traffic
congestion. They asked Will Wright how did he model that? Well,
turns out all he did was set a "traffic level" on the streets
immediately bordering any zone; a level that would increase with
the zone's property value. So naturally if you have
narrow streets running between high-value zones, you'll get
traffic congestion. That's it. He didn't compute little people
driving from the residential to the commercial or industrial
zones at 9am, then back at five.
That was a "cheat" - a game design device. Now, no pro game designer is going to
tell you you must design without these tricks, abstractions and
other devices. That is part of the creativity of game design.
Knowing how to design an elegant system using certain design
devices that achieve the result you're looking for. In the
traffic congestion example, it would achieve basically the
design's objective: force the player to consider the width of
their streets in their targeted high-value zones. It's not
totally realistic but it doesn't have to be, the same way when
you watch a movie characters will make several key discoveries
all within one five minute scene, even though that never happens
in real life (it provides a less disjointed experience for the
viewer than, say, cutting to several different times and places
within a five minute viewing span).
But you have to face these devices and question them,
whether they are appropriate and, in serious games, whether they
lead to real training. When you rely on graphics over gameplay,
you are making something facile.
In the serious games world, the promotional materials are
full of pretty graphics. Want to get funding to make a game about
dolphin training? Build a shallow graphic prototype with a 3D
dolphin swimming around a tank and you're probably a lot more
likely to get funding than if you build an in-depth tabletop
prototype that accurately reflects the actions and feedback of dolphin training. Sure, the tabletop is more useful to
the core problem of game design, you get to play it right away
to see if it tests out, and you can always build
the graphic layer on top of the core gameplay it delivers
(whereas if you achieve the graphics layer first you are nowhere
near over the main hurdle of gameplay), but the funders -
overworked, with tons of other meetings and decisions to deal
with - will
merely note that if it's a tabletop you can't see the little
dolphin swimming around...
I have come to realize that graphics in serious games are
well-suited to layperson-oriented educational purposes, such as
encyclopedia, issues of National Geographic, that sort of thing.
You take someone who knows nothing about a subject - say doing a
space walk in orbit - and put them into a high-fidelity 3D
version of it they will go from zero knowledge to a medium level
very rapidly. The problem is, in my experience, graphics are not
nearly enough if you're doing a product to do expert-level
training - they can't make up for thin design. In our space walk
graphics will
show you what it's like to float around the outside of the Space
Shuttle, but it won't show you key details such as that when you
work in space the air pressure in your suit forces the fingers
of your gloves outward, a force your fingers need to work
against, greatly increasing fatigue in doing hands-on work like
making repairs. The graphics won't show you key things you need
to focus on - that stuff can only be provided by research and
game design.
I
remember a serious game about pandemics where you spent time
walking about picking up basic items, such as prophylactic
doses, rubber gloves and whatnot. So you spend all this time
doing "boilerplate" actions, but how does this help get to the
bottom line of what you need to know to deal with a pandemic? In
a pandemic, you need to analyze outbreak clusters, where people
have been, who they have had contact with, mortality levels,
contagion levels, incubation periods, and so on. Design a game
about this and you need to cut to the chase: time spent picking
up rubber gloves is a waste (yes, you need rubber gloves during
an epidemic, but I don't need to make a high fidelity game to
train you how to use rubber gloves).
If you want to provide insightful and expert-level training you need to do a
lot, lot more than provide pretty graphics.
The Sensory Blandness Trap
This one is in some ways the opposite of the above. Here you
have a computer game so devoid of beautiful visual (and audio)
detail, and/or so limiting in what it permits you to do as a
player, that it is bland and boring. It takes away your ability
to really author your experience in the game in a freeform way.
"Choose your own adventure" games fall into this trap. "There
has been a terrorist bombing. A person shows up, not appearing
to be hurt, but very quiet with a pallor. He faints in front of
you. Do you A.) initiate ABC procedures on him?, or B.) call
security to get this guy, who is obviously faking, out of the
way of your real patients?" This example I wrote to blatantly
illustrate how much these kind of games make you "go through the
motions": you don't drive the game, the game just pulls you
along and once in awhile you give an input. Net result: boredom
and limited learning. For example, you obviously choose "A" in
this situation (the guy probably has a tiny shrapnel wound, is
now be bleeding internally into his belly). The problem, though,
is this game doesn't hit the real issues.
The example above is about triage - sorting out casualties
based on priority. When you train healthcare providers in
disaster triage, this stuff isn't what they need to know. (Why?
Because they already know it!, having done umpteen many
Friday-night shifts in emerg.) What they need to know is stuff
you can provide with exciting game development - an experience
that looks, sounds and smells real. The explosion has gone off
in downtown whereever; you are at the closest hospital,
and now a hundred walking wounded and walking worried are trying
to force their way into the emergency department. That is
the triage situation. You are never going to presented with a
discrete, isolated classroom situation where you are standing
there in a nice calm environment, waiting for a victim come to
you; a victim comes up, and then you do a cut-and-dried medical
assessment of them. No. You are going to have ten, twenty
potential victims coming at you, demanding care, and while
you're paying attention to the guy who is crying loudest about
how hurt he is, this other fellow is quietly slumping in the
corner and bleeding out into his belly. That is what you need
to train in! That is what graphics can give you: noise,
visuals, dialogue - the feeling you are there! So when
the shit hits the fan, you react.
These kind of issues seem obvious in retrospect, but you need
to suss them out. This scenario I learned from Dr Asher
Hirshberg, an Israeli trauma surgeon who has been through terror
bombings. According to Dr Hirshberg, sending your best trauma
surgeon to triage to categorize victims into four or five
categories is a waste - both of time and a good trauma surgeon.
Any decent paramedic can do it, and the only thing you need to
focus on is this question: Is this guy about to die shortly?
Yet at the last Games For Health Conference (2006), I watched a
presentation on production of a high-fidelity 3D triage
simulation game in which the objective was to methodically go
through all the medical symptoms and so on of your current
victim, as if that kind of minutiae would even be remembered
when a screaming person, blood pouring from a scalp wound, is
demanding help now now now! even though an improvised
compress bandage is all they need at the moment, and you have at
least five people unconscious (and thus not demanding help) who
are about to die while this person siphons precious attention
away from them. (Sounds cold doesn't it? Well, email or phone me
and we can discuss the realities of mass casualty incidents.)
The Design Blandness Trap
Design blandness comes when you do not take pains to get
under your subject. When you analyze it but do not perceive it.
Where sensory blandness (above) refers to a game that gives
an experience devoid of interesting sensory detail, design
blandness is one that is just plain dull even if it has
interesting sensory detail. And when you spend how many
thousands of dollars to make a serious game and it turns out
dull you just shot yourself in the foot. After all, making the
training interesting and compelling is the whole raison d'être
of serious games. If you want to make a dull, linear training
experience you should write a verbose course manual, hundreds of
pages thick, with no graphics, little structure, et cetera.
You'll waste a lot less money. (Not that written matter is
intrinsically dull
- far from it [as a serious game designer I spend a lot of time
reading on my subjects] - but you know what I mean.)
We are seeing the design blandness issue now in entertainment games. There
is a lot of talk of how creatively stagnant and lacking in
originality games are these days. (I wrote a
piece on that as it relates to serious games.) On the
internet there is talk that the game industry is full of
shallow, childish people who don't take their craft seriously;
who sling the words innovation, passion and
vision around as if they are everyday commodities.
Design blandness is difficult to measure. That's why people
don't pay much attention to it. For the same reason that when
they drop their car keys in the dark they'll still walk over and
look under the streetlight - because even though it's far from
where the keys are the light is better here. Design
blandness touches the mysterious "X" in the equation.
I saw this film once called City Hall. During it Al Pacino reacts to a harsh judgement of
someone, saying:
A man's life is not the bricks, it's the mortar...
It's the stuff that lays between. It's the stuff... the
stuff you can't see.
You can use that line for design in games - to persuade the people
who want in now of the importance of it, even though it's intangible. The
bricks are the technologies, the tools, the training content,
and so on - the
subject matter dissected into pieces, written in books and
whatnot. But what you need is the mortar...
In serious games, the mortar that lets you avoid design
blandess is interpretation. How
you interpret what you are to teach in terms of gameplay. And
interpretation is design. Design is the glue of it.
Game design, design of gameplay, is an aesthetic pursuit. Not
a technological one. Not one even of expertise in the subject
(though you certainly need to learn about the subject). You can take
an expert, who knows an itemized list of all the important
issues, who can even do it expertly in the field, but neither of
these means they can turn their subject into a decent
game.
The same has been said about veteran soldiers who write
memoirs about battles they have been in: as a general rule,
military historians are suspicious of these accounts because
they tend to be skewed, faded with time, coloured by the effects
of post traumatic stress and the pain of tears that cause the
retellers to change things to make them bearable. This isn't to
say those soldiers didn't do their job extremely well in the
midst of the fire - just that there is a difference between
being a soldier and a battlefield journalist or historian: being
good at the one doesn't make you good at the other.
This is also true about serious games. There is a dimension
of interpretation that goes beyond expertise in the subject
matter - that goes beyond merely knowing how to use the
technology. There is a huge difference between knowing
game design and knowing how to use technology. If you have a
choice between 1.) a designer who knows how to do the scripting,
but hasn't designed anything of much depth, and 2.) another who
knows how to study the subject and translate it into
meaningful play dynamics, game mechanics, user interface,
game story, et cetera - but spends so much time studying the
world they haven't mastered any of the umpteen scripting
languages out there - you are a damn fool to not go with the
latter designer. But, alas, you cannot concretely measure the
ability to translate something into a meaningful experience -
you can concretely measure if the script runs without
crashing. The light is brighter over here so the car keys must
be under it.
A Personal Example of the Challenge of Design Interpretation
For me, one of the most
challenging projects I had regarding design interpretation was
Code Orange. I was dropped into
the driver's seat of this project - spearheading designer
- after it was six months already done. They had done this
prototype but somehow it wasn't getting to what the client felt
was needed. We agreed to look at a total redesign. I was given
carte blanche: design the game. I decided to build it from the
ground up.
I was alone for months (while the team was off doing
Incident Commander). The game had no predecessor: there were
no games out there about medical resource management at the
hospital level during a disaster. In fact, there were no games
about ordinary emergency medical resource management - say, your
typical Friday night at a big city ER. So I was in a position of
designing the absolute foundation of gameplay with no prior
examples to work from. What's more, there is very little hard
data on this. Why? Because it's like combat: when your hospital
gets "slammed" with critical casualties and people die, do you
really really want to analyze the hell of it to determine,
definitively, that you could have saved those few people who
died in the trauma bays? Look at any report of a typical
emergency room subject to mass casualties: it will generally
conclude everyone received all the care they needed. Did they?
Probably not. But I am not going to judge them, because I'm only
a game designer: I can only know this intellectually. (Dr Asher
Hirshberg - whom I had the pleasure of meeting - faced his
colleagues at the ER One Conference in 2006 [which I attended]
and told them this, to their faces: We need more hard data on
the outcomes of disaster events in hospitals.) In the mean
time, you game designer are just going to have to design your
game based on... based on what?
Next, it isn't going to be played by gamers (laypeople) -
it's going to be played by experts. Not only that, the
people judging your game are world-renowned experts in
disaster medicine. (Google Dr Erik Auf der Heide, for example.
He was on the advisory board.) They make life-and-death
decisions at the same rate that you and I do our laundry or go
to the movies.
These are the challenges that can face you as a serious game
designer.
As a game designer, I found Code Orange terrifying.
Terrifying because I take game design seriously. Coming into BreakAway, starting the project, I got
that feeling. The team - off finishing up Incident Commander
while I researched and designed CO - seemed to treat me
like the "FNG" the veterans ignore in Vietnam: nobody talks to
him and they send him out "on point" to see if he gets shot; if
he survives we'll treat him like "one of us". That's what it
felt like at least. For a long time.
To me the catalytic moment came several months
into it. The project seemed to be coming to a head among us on
the team. I was spinning my wheels. I had done tons of research;
had seen people come in to the trauma unit knifed, shot, thrown
from buildings, smashed in car accidents, their limbs shattered
like rag dolls; watched dedicated trauma teams save them; had
donned gas suits during "chemical attacks" at hospital disaster
drills (which my army training helped me with). Had figured out
many key things about it. But still... the game was NOT gelling.
The damn game wasn't giving up its secrets to me! I had
already built all the key pieces for a tabletop prototype (that
much I was able to do - which is nothing to sneeze at), and the
art team was off building those assets for the computer version
- so I had the raw tools, the tokens, the units (some of the
"bricks", as it were).
One Friday we did a playtest on the floor of the
open area of BreakAway. We laid the pieces out on the floor,
building a mock emergency department and hospital. The team -
there to have me guide them through this so they could figure
out how, how this damn game is going to work! - they were
there playing the roles in a hospital under the "siege" of mass
casualties following a terror bombing attack: roles like trauma
unit leader, public information officer, incident commander,
chief planning, chief logistics, safety-security officer,
delayed unit leader, minor unit leader, triage unit leader,
inpatient services leader, surgical unit leader, intensive care
unit leader, ancillary unit leader, and so on (some playing more
than one role). We had all these pieces laid out on the floor
representing all the critical resources and things that need to
be tracked: emergency doctors, trauma docs, trauma nurses, emerg
nurses, radiology techs and docs, reinforcement docs and nurses,
ventilators, oxygen, blood (O-, O+, A, AB, B, et cetera),
gurneys, security officers, family-members (yes, family members
figure prominently!, both as potential resources and potential
hazards...), ambulances, civilian vehicles, surgical beds, ICU
beds, PACU beds, CT scanners, x-rays, portable x-rays, lab
processing facilities, orderlies and patient "techs", ancillary
services personnel, trauma bays, ambulatory bays, crash carts,
and on and on and on - all represented by pieces. Made from
cardstock and paper. And, then there were the patient cards...
Stacks of them. The patient cards were key, with
game-interpreted data to indicate all the needs victims of a
terror bombing can have; that would have to be discovered; that
they would "suck up": blood, surgery, CT scan, oxygen and so on.
That the practitioners would rush - rush! - to get to
them, to keep them alive...
That Friday game was total chaos. The pieces were right; the
key elements were there; but the game was still chaos. It didn't
have form. The team was terrified; the pressure on me
incredible. The team said, "This is just too complicated.
There's too much here." (Looking back on it, part of the reason
it was chaos is because it was something of an accurate
simulation of a disaster... which is chaos!) They accused me of
doing too much research; of trying to put too much detail into
the game. Some of that criticism was true (I later learned), but
it felt so ironic to me that at earlier advisory board meetings,
when we showed key materials we were devising - spreadsheets I
had drafted with the direct input of emergency medicine
practitioners (Xtreme Programming style) that depicted the
"stats" of key injuries (sorted only by abstracted mechanism
of injury, not by actual symptoms) and so on - those expert
doctors and nurses unanimously told me this is too
simplistic. We can't reality-check these figures because there's
not enough detail here. It seemed like an impossible
situation to be in as a game designer: the team telling you
it's too much, the subject matter experts (who will play the
game) it's not enough...
Saturday Dr Millo, the main client from Washington Hospital
Center, took me to speak with his friend Dr Asher Hirshberg, the
famous Israeli trauma surgeon (Google him too - he's been
through several terror bombings). We spent a whole day sitting
in the conference room of the Georgetown Hospital emergency
department in DC, going over mass casualty incidents at the
hospital level. Terror bombings (our agreed-to starting point).
Hirshberg is absolutely dynamic and decisive, with total command
of his subject. You have to be that way if you want to save
human beings in the midst of chaos, but he just seems beyond the
fold. He showed me modeling work he had done on terror bombing
events; gave simplified data on key aspects of it, statistics
and knowledge based partly on his own experience. We call that
stuff "hard crunchy bits" in game design. I wanted it. Badly.
But looking back on it, I also wanted Hirshberg's attitude to
it: his command of it and confidence over it. It was infectious.
Monday. I took the raw stuff Hirshberg gave and looked at it.
I wrote up a basic point form set of rules based on it;
interpretted things int he form of extensive charts on patient "decompensation
rates" based on their global needs - the kind of charts you'd
see in a good, complicated Avalon Hill boardgame (which is
suiting, since many of the guys at BreakAway are AH vets).
Tuesday we played it.
And it rocked!
(Plus, we had fun playing it! I still remember Chris, the
lead programmer, cursing at these little cards representing
crashing patients, as if a trauma doc slamming his fist on their
chests to shock the scrambled electrical waves of failing hearts
back into normalcy. "Stay with me, damnit!", or something like
that, when he rolled the D20 after throwing as many resources
onto them as he could spare.)
Wednesday. Dr Millo was there for a pass of the prototype. Dr
Millo, who was in search and rescue in the Israeli Defence
Forces. He watched us play (though he was often glued to a cell
phone, those ER types are so incredibly busy). From what I
recall the lead programmer was the trauma unit leader; the other
designer (lead of Incident Commander) the triage leader;
lead artist was safety-security officer; the user interface
programmer and a level designer were managing inpatient,
including the surgical unit, PACU, ICU and the general medical
units (the latter make up 75% of your typical hospital,
sometimes called "the wards" or "the floors"); the producer had
the hospital's command center (including the "labour pool" which
supplied vital reinforcements); another key programmer had the
remainder of the emergency department (the "non-trauma" ER). And
Dr Millo - ex Israeli Army - in charge of disaster planning for
a 5000-person hospital in Washington DC - was there watching us
play. We gave him the role of external operations command - the
guy up top the hospital would ultimately report its current
situation to to coordinate with other hospitals also involved
(to beg to redirect incoming criticals to other hospitals).
I was gamemastering and guiding the process. I had patients
lined up. Stacks of 'em. Who would "present" every 5 minutes
(the game turn length). The team - the programmers and artists
and so on - knew how they were going to come. Minutes after the
bombing, the hospital got slammed. Walking wounded. Panicked.
Arriving by taxis and civilian cars. Desperately seeking help.
Trying to get in. Do you declare this a mass casualty incident?
Well, of course! That's why we're here playing. But keep those
walking the hell out of the trauma unit! (You can't do that,
Hirshberg says, I know. So what you do is they get "overtriaged"
into the shock bays where you discover they're gonna be all
right, and you shoot them the hell through into the hospital as
fast as possible.) The ED is already running at nearly 100%
capacity (hey, it's your typical American emergency department,
and any terror bombing will happen in the middle of the day for
maximum casualties). What to do with all these people here?
Clear 'em out! I don't care if they're complaining. Just mass
discharge 80% of them. The programmers and artists and designers
are clearing these patients out. The GMU leader is clearing beds
in the wards, so we can clear ICU beds, so we can clear surgical
beds, so we can take what we know - what we dread - is about to
come... Because in a terror bombing it all comes down to
surgical beds. And any American hospital's surgery unit will
always be running at 95% capacity with mainly elective
cases (except for that one surgical bed the hospital is required
by law to keep open). About thirty minutes past detonation it
hits: slam! The criticals! Ambulances arrive and the criticals -
half dead, their bodies smashed with shrapnel, ruptured spleens,
blast lung, head injuries and other nasty effects of a terror
bombing - wheeled through triage rapidly into the ED. The
gamedev team is filling up the PACU; they are calling down
reinforcements into the trauma unit to keep the criticals alive.
Surgeons who normally specialize on hernias, residents with
little experience, all find themselves pressed into action
dealing with multiple fragmentation wounds, combined burn and
thermobaric injuries, and other bizarre blast effect wounds; the
unit's one trauma staff surgeon walking rounds in the
now-crowded trauma unit. The actual trauma bays are overfilled,
so they make improvised ones: a gurney, a bottle of oxygen and a
crash cart is all you need for an 80% effective trauma bay. We
stack patients in the hallways, but not the criticals. The
criticals wait for no one: we shoot them straight through. Into
surgery. One comes in, level 6 ("expectant"), and is rolled
straight through to the one open bed. We stack 2 patients into
each operating room, but we don't have the personnel at the
moment to deal with them.
On it goes...
To me the moment - the moment I knew I had the game - the
moment the game cracked and yielded itself - was when Dr Millo
said to the team...
Okay, let's see how you do. I think you'll be okay
with the patient load and the resources you have...
I had it. I had the game. He believed in the prototype. And I
felt that because an expert in emergency medicine bought into
it, this validated it. He looked at
our team - programmers, artists, designers... game developers
for gawd's sake - and spoke to them as if they were emergency
medicine practitioners in the middle of a hospital disaster
drill, training for the moment (that would hopefully never come)
when they would have to put this knowledge to real use. "I
think you'll be okay with the resources you have..." Not, "I
don't know if this game reflects a real terrorist bombing". He
looked at it and it, as a whole, seemed real. He was in that
teaching zone...
This prototype formed the foundation of the design for the
computer game version of Code Orange. I wish I could say
that Code Orange went on to be the big killer app in
disaster response training. Truth is, I had limited control over
it in the end: BreakAway had a dispute with a different company
on a different project and, with the sudden disruption to
cashflow, laid off a lot of people across the company
(including four teammembers from Code Orange); and the designer "under me"
was already a 25+ year veteran (worked for Avalon Hill; only reason I
was "above him" was I was at the helm of designing CO while he
was finishing up Incident Commander). True, the Washington
Hospital Center immediately hired me to continue working on
Code Orange - and I became a game designer at a hospital
(which was bizarre, but interesting) - but my role was then only a consulting
one. And then I used this expertise in Forterra (though, as a
game designer I consider them a little too married to their
technology [though being heavily committed to one technology
does have its advantages, naturally]).
However, I look at this as an opportunity: the killer app
for disaster training games has yet to be built. And now I
know how to do it.
Conclusion
The basic message here is that serious games by their very
nature are a combination of good technology, training and art.
Viewing them as good technology and training and tedious,
blandly-executed art is a way to make bland boring serious
games. If you wish to do that, why bother?
Serious games still require the passion and perspective of
creative game designers. When any artist creates - writes a book, paints a painting, directs a
film, composes a new song, performs a role on stage or screen,
et cetera - they
always know there is risk in this. That nothing is guaranteed.
They set out on a journey, an attempt - an attempt - to
capture the essence of what they sense is out there - of what
the subject is about - in the form of a paradigm-shifting work.
It is exactly the same thing in serious game design. You
don't just dryly program it. You interpret it. You try to
capture its essence - the mortar between its bricks.
If you're good... and have a little luck... you succeed.
|
|
