The [Spiritual] Role of Design

It’s been a while since I’ve posted anything to this blog.  Needless to say, I’ve been busy, what with the graduate degree and everything.  Oh, and also the mental breakdowns.

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.