Things get really interesting with Crawford's taxonomy when you get
to the lower reaches. Crawford suggests that without a competitor
whose outcome you can directly influence, you don't have a game.
I'm not so sure direct "attacks" are actually required in order to
influence the outcome of an event - think about the mind games that
occur in a running race where you can't actually touch your
opponent, but you can psych them out. But his definition really
boils down to this element of conflict, an element which makes it
into other definitions of games, such as that of Learning Games
expert
Simon Egenfeldt-Nelson, who suggests the
definition of computer games to be 'virtual worlds with a
conflict'.
For me, 'virtual worlds' is a contentious term because it conjures
the image of 3D graphics engines, Second Life and the rest of it. I
don't believe that this level of virtual world is necessary to
create a computer game, but I do believe it is necessary to create
a reality which is different to our own - be that through a
webpage, an app or a world.
Constructing the 'world' is a key part of the games design, as are
a number of other elements. I'll throw back to Jesse Schell who
neatly outlined 4 pillars of game design for us to work from:
Schell suggested that all games have a basis within these 4
pillars.
They have Aesthetics - a look, feel and touch which appeals to
players and is appropriate to the context. This might mean a 3D
virtual world, or it might mean a few scribbles on a piece of
paper. If you are short on resources, it probably doesn't mean a 3D
world, but that's no big issue. Many fine computer games are played
out through a text interface within a browser window.
Schell also talks about the Story behind the game. This, for me, is
one of the most important features in any game. Does it have a
narrative that I am compelled to see through to the end? Am I
genuinely interested in the outcome? To often 'serious games'
overlook this aspect as they seek to rip the 'fun' elements out as
an unnecessary and childish addition. It couldn't be more core. If
'fun' isn't a part of your vocab, leave games-based learning well
alone.
Mechanics are the pillar which the architects of many a
'gamification' have come to rest upon. Mechanics are the methods by
which we compete within a game, the way in which we do better and
win. Most people come to rest on the ideas of points, levels and
badges as being the sum-total of mechanics, but again, this is
selling the concept short. Mechanics can be woven into complex
design patterns which promote engagement within the game if they
are done right. Think about ideas like Quests, Treasure Hunts,
Reputation, Scarcity of Resources and Roles as just a handful of
mechanics which you can use to promote engagement and signal
competence within the game.
Finally, technology is the pillar which allows your participants to
play your game. Simplistically, the technology you choose needs to
facilitate the other pillars to the best of its ability. If you
choose an aesthetic which happens to be a webpage, then you better
have a web server which can serve it up reliably and your students
better be able to access it. But it doesn't need to be an X-Box to
do this.
I guess what I'm getting at with this background information is
that you shouldn't feel constrained by the 'normal' view of what a
triple-A rated game on the store shelf looks like. You don't need
to invest in the next Call of Duty to make a great game. By
considering the core components of a game and aligning the games
objectives with your learning outcomes, you can create a neat
solution which doesn't cost the earth. Games come in all shapes and
sizes and, if you structure your expectations accordingly, can be
brought in at low or even no cost if you are willing to do the work
yourself.
Plagiarism is rife in the game development world and I wouldn't be
adverse from taking a leaf or two from existing games as your
inspiration. For example, in a recent project we created a very
simple game that replicated "Guitar Hero" to teach students the
rhythms behind a horses hoof falls. Really simple, less than a day
to make and it works really well.
In reality, unless you happen to be a kick-ass coder, most games
that are within the reach of your 'average joe' probably play out
most of their story without the use of a computer game engine. But
that's fine too; the approach transcends computer games technology
once you know the core components of creating a decent game.
Nowhere in those definitions will you find an insistence to make it
a 3D photo-realistic shoot 'em up.
Let me close on a favourite story of mine for the development of a
simple game.
Imagine you are running a new employee orientation course. On the
first morning, you arrive 10 minutes late, looking a real mess. You
announce to the class that you've lost everything for the
onboarding programme - every scrap of information, save for the
contents page at the front of the binder. Your job is on the line
unless you can pull this information back together before the end
of the day. You need their help. They need to get online, get
around the office, and get talking to people to find you the
information you need. They'll compete against each other to get the
info back to you first as you only need one copy. But you need it
all by the end of the day.
Well, what are you waiting for? Get going!