In the
process of all of this, however, I’ve been finding myself in an uncomfortable
position. Then again, I don’t suppose
mental breakdowns would generally feel all that comfortable in the first
place. I suppose you think I’m being
facetious about that whole “mental breakdown” thing. But I digress.
I graduated
college with what I felt was a firm understanding of what a game designer is
and what role a designer fills on the team.
A competent game design program seeks to teach you those sorts of
things. Having successfully filled the
role of “game designer” numerous times over my college career, I came to
identify myself as a game designer - exactly which subclass of game designer, I
was never sure, but I knew I was a design-minded individual. I had a role to fill, and I knew how to fill
it.
Every
development team I’ve been involved with since then has been another story.
Making Design Matter
I find myself
nowadays working on projects where being a designer is of no real value. For the first time, I’m working with real,
serious, competent programmers, which in and of itself isn’t a problem. It’s great, in fact. The issue is that these competent programmers
are people who also happen to be bursting with ideas, know the basics of
documentation, and are perfectly capable of designing game mechanics. You know…professionals. In the process of all of this, I found myself
drifting into obscurity. What good am I
as a designer if my colleagues are collectively going to do most of the design
work themselves? As I worked my way
through a few tough months of game development, however, I came to understand
the answer to that question. Some of
this may sound ridiculously obvious.
Some of it may sound flat-out stupid.
Nonetheless, it’s something I’d like to attempt to express.
I’d like to
raise an important point first. I can
sometimes come across as having a problem with programmers. This is absolutely not the case. I have immense respect and fascination for
game programmers. They are truly amazing
people, and I am clearly not one of them.
No, I don’t have an issue with programmers, but I acknowledge that there
is a clear difference between thinking like a game designer and thinking like a
game programmer. That’s what I’m here to
talk about today.
If there’s
one thing the past few months have taught me, it’s the importance of a
dedicated design role in modern video game production.
It’s
absolutely true that without the core technology, a game can never get off the
ground. In finally having been involved
with the process of what it’s like to build a game engine from scratch, I have
a new appreciation for exactly why it takes so long to make a game that’s
intricate, polished, and truly entertaining, even when it’s built from an
existing toolset. Furthermore, how we’re
able to make games truly stand out from one another is remarkable considering
the amount of work it takes to simply make a character reliably move along the
ground without hovering over it or falling through it.
But even when
you consider all of the elements required to make game mechanics work, it’s sad
to see those mechanics all go out the window for the sake of time or simplicity. In extreme cases, the cutback can be so
severe that practically none of the original game mechanics are retained in the
final product. Eventually, what you’re
left with isn’t a game. It has no hook,
no…panache. It may have some mechanics,
at least, in the most technical sense of the word, but it’s not the kind of
thing that demonstrates entertainment.
As a game is being developed, I don’t think the player’s reaction should
be, “I can see you’re well on your way to getting this engine ready for a game. All the basic elements are coming together.” At the very least, the player’s reaction to
an embryonic game should be, “Oh, I get it.
This could potentially be really cool to play. I’d be interested in seeing this once the
bugs have been ironed out.”
Or maybe
that’s the indie in me still showing through.
Contradictory Thinking
I’ve observed
that if you’re building a game, it should be able to exist as a game, on some
level, even before the technology being used to run it is fully
functional. It’s odd to think about, and
from a development standpoint, it’s a bit scary. After all, how can you successfully test
platforming mechanics if you can’t reliably jump? How can you successfully test a shooter when
you can run and shoot through walls?
These are the
sorts of questions we were asking ourselves as we built a game in the spring
quarter. We can’t incorporate player
damage correctly until we get collisions working. Why add in the combat system when we can’t
correctly register damage? The structure
of the world doesn’t really matter since we don’t have a combat system. For that matter, there’s no point in building
a final environment until we can actually walk on our terrain correctly. And actually, since we can’t reliably walk on
the terrain, what use is it to develop the mechanics right now? (To be fair, it was a graphics programming
course, so it was easy to place emphasis on programming graphics.)
While these
are all valid concerns, particularly in a 10-week schedule, the fact remains
that at the end of the process, we failed to create a game. We had a nice enough world with some
impressive underlying technology, but any mechanics we had set out to build had
been utterly gutted. Part of that comes
down to the nature of the game we were trying to create, but another part comes
down to a lack of design-centric thinking.
The
importance of the design role can be a bit confusing at times, but that’s
partly because the game designer must fulfill two contradictory roles
simultaneously:
1. The designer works to promote an environment of
sanity.
2. The designer works to promote an environment of
insanity.
Perhaps these
should be listed in the opposite order for chronological clarity. More correctly:
1. The designer works to promote an environment of insanity.
2. Then, over time, the designer works with that
insanity and uses it to increasingly promote an environment of sanity.
Yes, gather ‘round
everyone. Mental Breakdown Man is going
to tell us stories about insanity.
Promoting Insanity
In the
conceptual stage, it’s the designer’s job to be insane. Just a little bit, if there is such a thing.
DESIGNER:
This is what I think we should do.
<Insert clever mechanics>
DEV TEAM: We
won’t have the resources to do something like that. Are you crazy?
(The designer tears up.)
DESIGNER:
That may be the nicest thing anyone’s ever said!
(The designer begins batting at the
invisible monkeys flying overhead.)
DESIGNER: How
many times have I told you people to keep the windows closed? These things are going to keep getting in.
The
designer’s task then comes down to defending and maintaining as much of that
idea as possible for as long as possible.
This isn’t for the sake of being revolutionary or being the boss of
everyone. That insane idea is exactly
how it sounds – crazy, impractical, and a drain on resources. It will never work in the real world. No, the real purpose of preserving that
insanity is to prevent devolution into the next forgettable multiplayer-based
sci-fi FPS, the next forgettable fantasy-themed free-to-play MMORPG, or the
next forgettable…well, any tower defense game, really.
Without that
spark of insanity flickering away in the heart of the project, it’s extremely
easy for a game to be cut down to the point where it no longer exists. An elaborate first-person action-adventure
featuring attacks that are based on altering the laws of physics becomes a
world with some things in it that you can shoot at. It’s simpler, more manageable, and less
time-consuming, but far more forgettable.
Keeping the insanity alive won’t typically maintain the original vision,
but it might at least let you include one or two physics-bending weapons in the
arsenal. If nothing else, you can market
your game as the one with the Friction Gun, which nullifies the frictional
coefficient of any targets it hits, causing them to lose all control for five
seconds. For better or worse, you’re now
known as “That Game with the Friction Gun”.
Note: Should you use a Friction Gun in
your game, I expect to be appropriately compensated.
…Okay, fine, as long as I get a credit
somewhere.
…
…Okay, fine, forget I ever asked.
Promoting Sanity
Somewhere
along this road is where the designer’s role shifts from promoting insanity to
promoting sanity. In preserving the
spirit of a game’s design, a designer must determine exactly where that
“spirit” comes from. What makes this
game more than just a world with some things in it that you can shoot at? What makes it something you could convince
someone to play for more than 30 seconds?
The designer
bears the important responsibility of determining two things:
1. Most fundamentally, what makes our game a game?
2. More to the point, and perhaps more importantly,
what makes our game OUR GAME?
From here, it
all comes down to determining the absolute minimum requirements for each and
seeing that those requirements are worked towards right from the start. Sometimes, this may mean that you start
developing combat mechanics while your characters are still jumping off of the
world into the void that lies beyond your skybox. That’s okay.
We’re working on it. At least you
can get a sense of how the game mechanics work.
Well, okay…how they WILL work.
But you can at least see the game.
Well, okay, this isn’t “the game”…I mean, we’re not publishing this
version, but…you know, you get where we’re going with it. Right?
Keeping that
design mentality alive is important for ensuring that the game isn’t lost for
the sake of function. A single bug can
break the experience of the entire game – that’s why we perform extensive bug
tests, after all – but in focusing entirely on creating a functional engine, there’s
no experience to break. Generally
speaking, a toy car that has a wobbly wheel is more fun to play with than a slab
of metal with four fully-functioning wheels on it. The car has a clear purpose and a clear sort
of play to be derived from it. The
chassis is just a tool.
That’s where
maintaining sanity comes into play. As
is well known, no code is completely bug-free.
Hunting for bugs solves some problems, but can create others, and the
overall process goes on and on, practically without end. Thinking in terms of design enables the
development of a clearer hierarchy of priorities, allowing development to be
focused where it’s the most important for the game. Developing the gameplay early allows the team
to see exactly what problems need to be solved in order to make the game functional
for its own purposes. What is it,
exactly, that breaks the experience?
What element of the gameplay does this bug affect? If this problem isn’t fixed, will the player
still understand the game? If it is,
will it improve the player’s understanding further?
A Hastily-Conceived
Classification System
Thinking in
design terms, at least to me, means prioritizing the game’s development in
terms of different “tiers” of a player’s experience. Each tier represents a different degree of
depth to which the player is invested in the game.
Tier 1: Understanding
The
“Understanding” phase is the most basic piece of a player’s experience, and
it’s the first that should be focused on during development. During Understanding, the game should
demonstrate its purpose to the player.
This is the “kind of game” we’re dealing with. The player gets to sample the game experience
and determine if it’s the kind of thing they’d like to play. “This is how the game works, this is what
you’re trying to do, this is what’s entertaining about it, this is the kind of
experience you should take away, and generally, this is why you should play
it. If this doesn’t suit you, you’re
clearly just not the game’s target audience.”
Now, obviously,
there are some things you need to do on the technical side before anything
else, like being able to render graphics and interact with them on some
level. This tier, however, is the first
piece of a game’s development that enables people to see your game for what it
is – an entertainment experience – and not just a tech demo. There are things to do. Some of them may not do what you expect at
this stage in development, but they’re there.
Tier 2: Commitment
In the
“Commitment” phase, the player has grasped the concept of what the game is and
decided to move forward. Understanding
the base concept, the player now needs to see if what seemed like an enjoyable
concept begins to pay off. Does the game
live up to the potential the player has envisioned in the “Understanding”
phase? If it does, can it maintain that
level of enjoyment for more than a few minutes?
The real test of a successful player commitment is the completion of a
standard play session and a subsequent return to continue the game. This is where the overall execution of the
base game engine becomes vitally important.
Does the game
run smoothly? Do the mechanics work
together effectively? Does it feel like
a prototype, or does it feel like a fully-realized game world?
By now, the development
team should be pushing the game beyond the point of basic errors in physics and
rendering processes, as well as ensuring that player actions in the game
generate the appropriate feedback, both functionally and aesthetically. There aren’t just things to do, but reasons
to do them. You might say the Alpha
stage represents the end of this aspect of development (or even still a
pre-Alpha).
These first
two tiers are the only ones truly required for what might be considered a
technically “complete” game, but to take it farther, two more levels provide a
game with a deeper player connection and keep things more interesting.
Tier 3: Exploration
A player
enters the “Exploration” phase at about the time he or she begins a second play
session. By now, the player accepts the
base concept and accepts the execution of that concept within a game
world. Now, the player begins to dive
into the world itself and expand upon that initial review.
What sorts of
elements are present in this world beyond the mechanic I’ve come to enjoy? What sort of impacts do I have on the world
around me? Are there some other things
for me to do that are also enjoyable?
How does this all tie in with the main mechanic?
This is where
game mechanics start to reassert their importance in the development process,
but it’s also the point at which to further consider general functionality and
efficiency. This is where the player’s
impact on the world becomes increasingly important, so the game world needs to
be able to respond to changing conditions and maybe even surprise the player
here and there. With many of the
short-term gameplay concerns coming under control, attention now turns to the
larger scope of the game and how everything ties together. This isn’t just a demonstration – this is a
fully realized game experience. It’s
time to show that the game has more depth than simply repeating the base
mechanic over and over. At the same
time, it’s an opportunity to show the player that the same mechanic can be used
in new ways.
Tier 4: Immersion
The word “Immersion”
gets thrown around here and there all the time.
In this case, I’m using it to represent the deepest level of player
involvement and the lowest-priority stage in the development process. At this stage, the player is intimately familiar
with the mechanics and has fully committed to being a part of the game
world. The player is delving deeper and
deeper into the experience and moves from the posture of looking for enjoyment
to expecting enjoyment. At this point,
it’s less about finding things right with the world than it is about finding
things wrong with it. Keeping the player
immersed means ensuring that nothing happens to disrupt the existing
experience.
Naturally,
since the player is so deeply involved with the game at this point, smaller
mistakes become more and more noticeable.
This is the point at which thorough bug cleanup can mean the difference
between a good time and an unforgettable experience. It’s also the point at which smaller details
can be used to further enhance the game world and generate a more believable
space. In terms of mechanics, thorough refinements
of pacing and difficulty can help the game move at a rate that feels natural
and satisfying, but every player is a little different, so this process can
only go so far. Essentially, this is the
stage of detail and polish. It’s much
less about adding new things and much more about removing any problems.
What I’m On About
This all
makes it sound like the designer is taking over the role of a project manager,
but that’s not the issue here at all. The
issue is with ensuring that game design sensibilities are injected into the software
development process – ensuring that the software is being developed into a
game, not just into a framework for a game.
Thinking in terms of design helps to establish clearer development
priorities, shining a light on where the real issues lie and helping to identify
the specific tasks that make up the components of each milestone.
That little
spark of insanity provides a goal to strive towards. The quest to keep that spark alive helps to
identify where priorities lie, providing an additional blueprint for the
development process and reinforcing a sense of order. Thus, that spark of insanity works to promote
sanity.
As always,
how you choose to develop games is your own business (literally, if you have
your own development company). These
words of advice come from someone who’s most likely far less experienced than
you are, in which case, you have little reason to listen. That hasn’t stopped me before, though, and it
sure as hell isn’t going to stop me now.
And if you
think I’m crazy, I thank you deeply, and I’ll ask you to close that window.
Thank you. That
is all.
No comments:
Post a Comment