The "Unplugged" Album

I’ve been doing this for about a year now.  Many of my blog posts are written from the perspective of some lunatic raving about high-level design theory.  What makes a game good?  What can we think about when we’re designing?  What sounds clever and thought-provoking while still disguising the fact that I have no professional experience to draw on for the sake of my argument?

(Answers [Respectively]: Licensed Merchandise, Food, and, “Hey, quick, what’s that over there?!”)

Today, though, all of that changes.  I’m going to make a comparison of two things based on ACTUAL EXPERIENCES!  That’s because, for the first time ever, I recently completed the design and development of a non-computerized game. 

The Basis

I’ve spent the better part of the last six years designing (or learning to design) video games.  This is a particular branch of the vast community of game genres out there, and it’s one that I’ve been focused on.  It lends to a particular style of thinking.  However, over the past few years, I found myself wanting to do something in particular that demanded thinking outside the confines of electronic gaming.  “Wouldn’t it be nice,” I thought, “if I, as a game designer, had a business card that actually demonstrated that?”  Thus, back in November, I set about converting my business card into a playable board game.  In actuality, I turned it into four games, which I proceeded to unveil in a completely untargeted and reckless manner at this year’s GDC.  At most, roughly one percent of this year’s GDC attendees may potentially know what I’m talking about. 

That process gave me a few new insights into some of the differences between designing for an electronic platform and designing for what is often called a “traditional” platform.  Some are obvious, but some of them can easily slip under the radar.  Or maybe that was just me.  For your consideration…

What are some of the differences between designing a video game and designing a “traditional” game? 

Automation

One of the keys to designing a video game is the inclusion of elements of interactivity.  The game is able to communicate with the player, at least to some degree, and provide some level of automated feedback.  A non-computerized game loses much of this feedback. 

Now, I don’t want to get into a lengthy semantic discussion here, so let me quickly explain exactly what I mean by “automated feedback”.  “Feedback” can qualify as an action presented on one of Monopoly’s Community Chest cards, for example.  However, the player has control over the presentation of that feedback.  The player can always choose not to play with cards, not to draw that particular card, or not to follow the action portrayed on that card (breaking the rules, of course, but still by choice).  Automated feedback is forced on the player – an action triggers a reaction, and the player can’t avoid it.

Thus, in a board or card game, any feedback the game can provide is dependent on the player’s cooperation.  This is the key element upon which the other elements listed below are based.

In the case of my design, the only tool the player can use to aid game feedback is a pencil.  Interactivity is entirely dependent of the player’s willingness to constantly mark and erase spaces on the game board.  Such interactivity is much more easily handled by an automated system.  In an electronic format, the player would only need to be concerned with making a move, not with the specifics of how to mark down each move on the board.

How can this lack of automation be used to the design’s advantage?  I’m not willing to hypothesize too much since I’ve only done this once.  However, I’ll say this much: with a lack of automation, the player becomes much more exposed to the game design’s internal functionality.  The player’s knowledge of that functionality can provide some interesting opportunities for play alterations and some player-based evolution of the game.  You can potentially encourage “hacking”, if you will.  That’s just one example.  I’ll discuss a bit more about the player’s knowledge of game functionality below.

Documenting for Players

One thing I learned to do in college as a game designer (over and over again) was to create and maintain documentation for my games.  I was shown the importance of the DESIGN DOCUMENT, a mystical tome from whence video games are spawned.  Programmers like to sit around this document and shoot down any ideas that emerge from it (i.e., spawn camping).

A design document is written for the benefit of the development team.  Developers turn to this reference as a source of instructions for building the game, constantly updating and altering its content as conditions change.  The design document is often referred to as the “blueprint”.  It provides a basis for what resources are needed, how mechanics fit together, and how basic systems function.  Development teams take these elements and combine them together in such a way that the computer builds a world for the player and, essentially, teaches the player how the game works.

As I was creating my business card, however, I noticed a strange pattern occurring.  Instead of writing a design document, I found myself writing instructions for the player.  I wasn’t so much providing a reference for others (or in this case, myself) to build a game, but rather bypassing this direction and speaking directly to the player.  In essence, I found myself “programming” my game as it was being designed.

Once again, a lack of automated feedback has a great deal to do with this.  In the space of a video game, programmers dictate game functions by telling the computer how to react to a given situation.  Generally, the rules of play are revealed to the player over time as these actions and reactions are repeated.  The development team and the computer have to know how the game works from the beginning, but the player merely needs to observe and learn as the game unfolds. 

In a traditional game, there is no computer to react to game situations.  Any reaction must be made by the player.  As a result, all of the game rules and functions need to be conveyed directly to the player.  “This action has this consequence.”  What would normally be sitting in the code as an “if/else” statement is simply described directly: “If the player rolls a twelve, he draws a card.  Otherwise, he moves the number of spaces displayed by the dice roll.”  In this sense, a non-computerized game is “naked” – the potential actions to be taken are laid out right in front of the player, rather than hidden away in AI functions and code blocks.

This isn’t to say that a design document is irrelevant in a non-computerized game.  There is still information relevant to the game’s functionality you may want to take note of while still keeping it hidden from the player.  Noting particular useful strategies, pointing out advantageous game scenarios, and, depending on the game, listing solutions are all elements that can help you determine what tweaks to make in the rules or what direction to take the design, but it stands to reason that revealing them directly to the player might break the gameplay experience.  In this case, a design document can prove to be a useful addition.  In the end, however, the final rules presented to the player will entail the bulk of the game’s design.

Complexity

Working off of the prior subject comes the issue of complexity.  This is an element that I, admittedly, may not have taken into account as well as I should have.

Considering that a non-electronic game is explained to players largely through pre-written instructions, such a game needs to be capable of being conveyed clearly and concisely through those instructions.  Every game system is built of a set of steps to be followed in sequence.  In a video game, some of those steps are covered automatically by the game.  A non-electronic game, lacking that automated feedback, forces the player to perform every step in the process.  As previously stated, the player has the advantage of seeing all of the immediate consequences of game actions laid out in the game rules.  However, the addition of this information comes at an obvious price – the player has more to learn.

The issue of complexity is primarily an issue of time.  Just as it takes more time to program a computer system to execute a more complex sequence, it takes more time to program a human player the more complex the sequence becomes.  The more time it takes someone to figure out how to play a game, the less likely they will be to play it.  If computer code is written incorrectly, a program may fail to compile properly, but the programmer can continually go back and fix the language used until the program runs.  People aren’t as willing to undergo nearly as much trial-and-error; if someone doesn’t understand how the game works, you can only rewrite the rules so many times before they refuse to even make an attempt.

It’s difficult to describe effectively, but I can tell you straight off that complexity in a non-electronic game is decidedly different than complexity in a video game.  Video games often feature a wide variety of actions, each one with a different effect on the game.  Their complexity comes out of finding the correct situations in which to use each of these many actions, placing them in the correct sequence with the proper timing.  Many non-electronic games feature a very small number of actions and rules.  Their complexity comes out of the player discovering the many different uses for those few actions.  In effect, the video game dictates a play style to the player, forcing the player to adjust his style to fit the game rules.  In the effective non-electronic game, the player’s play style dictates the functionality of the game to a much greater extent.

Looking at it this way, I realize that my business card games were designed from a video game mentality.  They have a heavy emphasis on sequence and cause-and-effect.  As a result, they are easy enough to understand once you understand the sequence, but it takes far too long to fully convey that sequence in written instructions.  The combined instructions for my four games totaled out to a 65-page document.  Granted, this included a number of large pictures, lots of repetition from game to game, and a lack of text-image wrapping, but it still means the instructions for each individual game range from 10 to 25 pages.  Combined together, that’s a bit intimidating to look at.

The basic rules for any game have to be as simple for the player as possible.  For equivalent electronic and non-electronic games, the rules of the non-electronic game will be twice as complex as those of the electronic game, at least from the player’s standpoint.  In order to cover both action and reaction, the player must learn twice as many rules.  As a result, there is a greater need for simplicity of gameplay in a non-electronic game as there is in an electronic one.

This isn’t to say that non-electronic games are doomed to have less depth and complexity than electronic games.  Two non-electronic examples often cited in game design lessons – Chess and Go – demonstrate very simple rules, but with immense underlying challenges.  Understanding how to play takes just minutes, but becoming a successful player takes years, even a lifetime.

Therefore, it would seem that the real trick with non-electronic games is to create complexity through simplicity.  Simple gameplay rules with simple relationships between action and reaction create a game that can be played in an immense number of ways.  The game is approachable, it’s easy to follow, and it promotes repeated replays.  It’s probably worth noting that while these elements are a key consideration in the creation of a non-electronic game, they are also tremendously important in the design of a video game.

Wrap-Up

So there we are.  These are just a few of the new things I’ve come across in my exploration of the non-electronic gamespace.  Looking back, some of my mistakes have become much more obvious, but then again, that’s what this is all about.  I’m here to learn, and I’m here to pass that knowledge on to you.

Thank you.  That is all.

...

By the way, if you’re interested to know exactly what I’m talking about, feel free to sample the Business Card Games at http://www.douglynnportfolio.com/thebusinesscard.htm.  

I’m still looking for some legitimate test data to work with.

The Scientific Method

The question of “The Art of Games” keeps coming up in discussions.  However, there’s a piece to this discussion that’s always present in some form – the Science of Games.  Art or not, these two theoretical situations demonstrate how many, many games out there are products and promoters of the scientific process.

THE GAMER

Problem:

I seem to die every time I fight this boss.

Question:

How can I get past this boss without dying?

Observations:

The boss has a very big machine gun, which fires in long bursts and deals out damage quickly.  He is heavily armored, and as a result, doesn’t seem to move very quickly.  He always seems to know my location, even when I hide somewhere, so he can always track me down.  When hit with a powerful enough blast, such as a grenade, he is dazed for a short period of time.

Hypothesis:

I’m focusing too much on racking up lots of damage at once, spending too much time exposed.  By quickly ducking in and out of cover, I can deal out small amounts of damage at a time.  While it may take longer, it should provide the protection I need to outlast my opponent.

Materials:

Let’s focus on weapons that can discharge quickly between pieces of cover, preferably while I’m on the move.  Grenades can quickly be tossed.  The light machine gun is great for strafing runs.  A medium or heavy pistol is also in order for quick pick-off shots.

Procedure:

1. I began by equipping the Light Machine Gun (LMG) while standing in the opening anteroom.  I approached the corner, hugging the wall.

2. I rushed out to the barricade in the center of the room.  On the way, I fired a quick burst from the LMG.  Having reached the barricade, I immediately ducked down.

3. The boss proceeded to unleash a long stream of bullets from his machine gun.  I waited several seconds for the wave of bullets to subside.

4. While waiting, I prepped a grenade for use.  As soon as the firing ended, I quickly rose up and released the grenade towards the boss before ducking back down. 

5. Quickly, I re-equipped the LMG and waited for the blast.

6. The blast occurs, damaging and dazing the boss.  I rose up and quickly emptied a LMG clip into the boson this occasion.  Before his daze wore off, I ran for third pillar on the right while equipping the pistol.

7. As the boss recovered, I gazed around pillar and fired three shots.  The boss began firing once again.

8. I moved to the next pillar, taking a few hits on the way.  Once more, I waited for the enemy wave to subside.

9. Rounding the pillar, I fired two more shots.  I quickly dove into second anteroom before the next wave of bullets commenced.

10. Within the anteroom, I was able to retrieve fresh ammunition for the LMG and Pistol.  Moving to the corner, I waited once again for the wave of bullets to subside.

11. While waiting, I prepped another grenade, stepping out to release it immediately when clear.  Due to an error in aim, the grenade failed to land as accurately as hoped.  However, the blast radius was still sufficient to damage the boss.  I made a run for the pillars on opposite side of room, re-equipping the LMG.

12. Following the grenade blast, I proceeded to fire precision shots at the boss character’s head for the duration of his dazed period.

13. I ran up to the last pillar in the row, equipping the pistol.  Several more shots impacted me along the way as the boss character recovered.

14. I rounded the pillar and fired two more careful shots.  Following this, I dove back into the first anteroom.

15. Acquiring additional ammunition in the anteroom, I repeated steps 1 through 7.

16. Following a final Pistol shot, the battle came to an end.

Analysis:

Initial results during execution appeared promising.  Though the perceived progress in relation to the time elapsed seemed much lower than in prior attempts, the amount of damage sustained in the process also seemed to be much lower.  While the battle was taking a longer time to complete, it stood a better chance of progressing farther than in pervious attempts.

Results:

This boss has been utterly and completely owned.  In the face.

 I shouldn’t say that.  I barely got through that fight alive.

No, you know what?  Owned.  Destroyed.  Wrecked.  End of story.

Conclusion:

In this instance, panic and haste seem to be less effective means of play than methodical use of cover and speed.  As the boss is based on powerful attacks, it seems to be well-equipped to defend against the same type of attack.  Quickness and a thorough use of defensive cover proved to be the winning solution.

THE DESIGNER

Problem:

This puzzle doesn’t seem to make sense to the QA team.

Question:

How can I make this design easier to understand while retaining an adequate level of challenge?

Observations:

The existing puzzle is meant to reflect upon the main character’s childhood memories.  As a result, certain childlike elements are incorporated into the puzzle.  A rubber duckie, toy frog, and toy firetruck populate the game area, each one with a different function.  Colored pipes on the floor lead from each object to the next part of the puzzle.  The colors of the pipes correspond to the colors typically associated with each object (red firetruck, yellow duck, green frog).  By activating the objects in the appropriate sequence, players fill in freaky void spaces in the water, swim through air (i.e., fly), and alter the water level to progress through.

Hypothesis:

Too many elements are being introduced at once.  If I trim down the number of mechanics used to solve the puzzle, it can help.  By reducing the number of inferences and implied associations, the puzzle should have more universal appeal.

Materials:

The idea of twisting corridors has been done to death, but it works well and is easy to understand.  Twisting corridors.  We’re underground in a storm sewer, so water and swimming seem to be logical components.  I have immediate access to assets for wheels, levers, buttons, and lights.  The existing puzzle contains a rubber duck, rubber frog, and toy firetruck, along with null spaces and colored pipes.

Procedure:

1. Initial re-evaluation.  I examined the nature of the puzzle in relation to the rest of the game.  Which elements are the most vital?  Which are the best fit for the environment?

2. The existing sewer setting proved important to the story’s progression.  Working from that element, the most necessary feature from an aesthetic standpoint seemed to be water.  Consequently, swimming proved to be the primary mechanic fitting the environment.

3. Elements of fear are pervasive throughout the game.  A great number of dark, cramped spaces make the player feel crowded and trapped.  In maintaining this atmosphere, the existing concept of a twisting, narrow maze fit in very well.

4. With these key elements isolated, I proceeded to eliminate the less vital pieces of the puzzle and go back to a more basic starting point – an underwater maze, traversed by swimming.

5. The basic concept, through fitting in with the game, lacked challenge.  Adding a degree of complexity became the next step.  Originally, this was the function of the toys-and-colored-pipes system.  However, the original system proved too complex. 

6. Re-evaluating the system began with removing its “symbolic” pieces.  This meant looking beyond the specific art assets – the toy duck, frog, and fire engine, along with the element of color – to determine the actual gameplay structure of this system.  That gameplay structure turned out to be a simple one – a sequence puzzle.

7. Working the sequence puzzle into the maze system meant avoiding the vagaries and implicit nature of the original layout.  Instead of utilizing numerous objects that do numerous things, I began by simplifying the process and having a single type of object do one thing.

8. Analyzing the gameplay mechanic of swimming suggested that the water itself could prove to be an effective barrier mechanism; the player can only swim as high as the water can reach.  As a result, a secondary mechanic emerged – move the water.  By moving the water, the player can move through the game world.

9. Thus, the function of the single type of object to use was determined.  When used, this object would alter the water level.

10. With the mechanic in place, mapping could proceed.  The existing maze from the original puzzle was in place.  Working from its structure, different water levels were worked out that could be used to access different areas.

11. Upon examining the new mechanics, it occurred to me that the puzzle was not based so much on determining a specific, correct sequence, but on moving from one point to another linearly.  Each object only raised the water level.  All that was required to complete the puzzle was to explore the entire area and locate each object to raise the water.

12. To expand once more upon the mechanic, an element of asymmetry was introduced.  Each object not only raised the water level, but also lowered it in another area.  As a result, some of the locations that could originally be reached with just two moves now required a sequence of five or six moves to reach.  This new layout demanded much more from the player in terms of analysis and problem-solving, increasing its level of challenge.  Still, the concept itself remained quite basic, lacking the implicit nature of the original design.  Incidentally, this mechanic also made more sense aesthetically; water was not simply appearing, but being transferred from one area to another.

13. From this point, all that remained was the selection of the object to be used to alter the water level.  Several existing options were available to choose from – namely, a wheel to be turned, a lever to be pulled, or a button to be pressed.  The lever seemed to indicate directionality.  Since water was being both raised and lowered at the same time, this directionality conflicted with the gameplay.  The wheel ended up being chosen as it seemed to fit more properly into the underwater environment.  Additionally, it provided greater movement than the button, allowing for a more visible effect upon use.

Analysis:

Testing the puzzle on my own time seemed to suggest a much more left-brain-centered design than its predecessor.  Even in its early stages, it seemed more logical than the original design.  Despite the loss of artistic flair and symbolic complexity, it somehow seemed more challenging in its new form.

Results:

A new round of testing indicates a much higher completion rate of the new puzzle design.  Reports of frustration and confusion are significantly reduced, as are reports of accidental solving.

Conclusion:

While artistic expression is important to this game from a narrative and aesthetic standpoint, it doesn’t work as well in the logic-based format of the puzzles.  The more artistic and narrative-based puzzle simply seemed to be confusing, whereas its more logical counterpart was more playable and contributed more to the overall quality of the game.  In this particular instance, the story seems to be told most effectively through the atmosphere and the gameplay, rather than through more literary methods such as symbolism and metaphor.

(No offense intended to the actual designer of “the original puzzle”.  Good times.)

…

Question:

How can I tell people about myself without actually meeting them?

Hypothesis:

Let’s just say I’ll see you at GDC.

Or rather, I hope YOU will see ME.

Lowering Expectations

"Hello. My name is Doug, and I am a motivational speaker."

At least, that's the role I'll be filling today.

There’s quite a serious desire, especially as a beginner, to make a big mark on the game industry.  No matter how rational and level-headed you are, it’s easy to envision yourself as the developer of the next Portal, Angry Birds, or Minecraft.  And yes, there’s the remote possibility that you could be that person.  However, chances are also pretty good that if you get into the game industry at all, you’ll spend much of your career working on rehashes of old concepts, film- and TV-licensed games, and overall generic, unremarkable titles.  If you think about it that way, you can easily start getting concerned.  “I need to make something special right now while I still have the chance.”

So that’s exactly what you try to do.  You put all of your knowledge and skills to the test.  You come up with crazy new concepts and attempt to find ways to execute them.  You attempt to make game engines do things they weren’t designed for.  You work under the guise of “Boy, if I can make this work, I would just be the most awesome person ever!”  You look at your creation as something that no one will be able to ignore.  In a good way.  Not in a Mystery Science Theater 3000 kind of way.

Then again, maybe that’s just me.  Which reminds me…

THIS IS AN IMPORTANT NOTE:

The recommendations in this blog post are not intended to apply to everyone.  This is not general advice.  Everyone has a unique way of working, getting motivated, and making things happen.  If your brain works in a certain way, the information you are about to see may be completely wrong.

What, then, is my target demographic?  Who is this advice designed for?  It’s designed for those who are inspired by the big picture, but who need something else to gain the motivation to learn something new.  It’s for anyone whose delusions of grandeur have overpowered the ability to expand and grow.  It’s for those who have forgotten about the virtues of patience.  And, on a more pathetic note, it’s for people like me who have worked under established guidelines all their lives, and have now realized that they can’t establish guidelines of their own.  In short, it’s for people who need motivation to keep learning.

As we grow up, we’re told to reach for the stars.  There’s nothing we can’t do.  We are awesome.  While this may be true, this line of thinking has a particular, glaring flaw.  When one “reaches for the stars,” there is an implication that the goals we strive for are far away.  In response, we establish short-term goals that can help to lead us to this final step.  Our conscious minds are more capable of interpreting and dealing with these shorter-term goals, delegating our ultimate goal to the back of the mind to be dealt with later.  In a few years, maybe.  Thus, we move incrementally up a path we’ve established, making that unreachable goal seem much more attainable.

As we move closer and closer to our ultimate goal, however, it becomes harder and harder to follow the established path.  While the steps to reach the end become smaller and smaller, the desire to follow those steps diminishes.  When the end is in sight, it comes back into focus and blocks out everything else.  “This is what I’ve sought for years, and it’s about to happen.  My dream is becoming a reality right in front of me.”  We’re so close to the stars now that we can almost reach out and touch them.

“Almost” being the operative word.

Einstein’s theories state that as one moves closer and closer to the speed of light, it requires the expulsion of exponentially greater amounts of energy.  If you’re traveling at 99 percent the speed of light, basic thought would seem to suggest that expending that last percentage point worth of energy would get you there.  In reality, (at least according to the now-aging theory), that extra percentage point would take you to more like 99.00001 percent of light speed.  “Okay, then…light speed is right there.  I’ll just double my energy output and that should put me well over the top.”  So you double your energy output.  You’re now traveling at 99.1 percent of light speed.  So on and so forth.

Reaching for a major goal feels similar to this concept.  In the beginning, it seems outrageous and practically unattainable.  As you move forward and apply yourself to the problem incrementally, you move closer and closer to your goal.  Eventually, you reach that elusive 99 percent.  Only a few simple steps will help you to break that barrier and achieve your dream.  On the other hand, with your dream staring you right in the face, another possibility becomes more and more appealing: you’ll take what you’ve achieved, all you’ve learned, and press forward with it.  You’ll consolidate your 99 percent, make it more efficient, and hope that it can push you the rest of the way.  In the end, though, no matter how much you spruce up your 99 percent, it can still only take you 99 percent of the way.

What’s the point of all this nonsense about percentages?  The gap between knowing MOST of what you need to know about making games and knowing ALL you need to know about making games is bigger than it seems.  More accurately, “knowing all you need to know about making games” doesn’t exist.  There is no 100 percent.  While this is true of anything that demands the accrual of experience, it’s especially true in a field as consistently shifting as gaming.  New technologies, new processes, and new ways of thinking are always entering into play.  There’s always something new to learn.

So let’s take a completely random, out-of-the-blue, entirely hypothetical situation.  Let’s say you graduated from a Bachelor’s program in game design some, I don’t know…32 months ago.  You learned a lot there and built up a pretty sizable skill set.  You know how to market yourself fairly well, and you’ve been trying to use that skill set to net yourself a job in the industry.  Good.  For some reason or reasons unknown, however, you’re just not making a mark with your prospective employers.  Maybe you complain a lot about the requirement for 2 years of experience on so-called “entry-level” jobs.  Maybe you’ve thought about trying to go independent.

Over the course of all this, you’ve been trying to work on some projects to build up your portfolio, and you’ve run into a few snags.  Primarily, you seem to have a lack of fully-completed, fully-playable games available to show to the world.  Now comes the time to ask a question: “Why don’t I have any fully-completed games here?  Is it the fact that I can’t get my [artist / programmer / designer] friends to help [make me some assets / make this thing work / make this thing “work”]?  I know it’s not me because I can do anything.  People have been saying that all my life.  I can do anything, just…not everything all at once.”

Stop right there.  I’m here to crush your spirits.  I’m going to destroy all of your hopes and dreams.

It’s your fault.  You don’t know as much as you think.  You are not worthy.

There.  Now what do we do when people break our spirits?  No, no, stop crying.  It’s okay.

If you find yourself struggling to find motivation, if your eye has been dead-set on the end goal, and if you find yourself struggling to complete your heroic quest, consider that your wakeup call.  What I meant to say is, “You are not worthy…

“…Yet.”

  All that means is that there’s still more to learn.

Of course, the idea that there would ever NOT be more to learn is ridiculous.  What I’m talking about here is taking a step back, going back to your roots, and re-learning the basics.  Whether that means going through old tutorials and training programs for the basics of Unity, something as major as reexamining what makes a game a game, or something as minor as reevaluating the basic language of a C++ sequence you set up at the beginning of a project, going back to basics can remind you of what you need to do to complete your ultimate task.  Treat yourself like a rookie.  At the very least, it will make you feel smart to learn about the things you already know.

But the true goal here is something bigger.  Lowering expectations isn’t so much about making yourself feel more qualified to do what you do.  Really, it’s about reigniting that spark to learn something new.  By going back to the beginning, you get introduced to new avenues you may not have explored before.  New information resources turn up.  New chains of thought are set into motion. 

Perhaps most importantly, you can present yourself with the opportunity to stop trying to solve a specific problem you might be facing.  If you’re building a game from a preexisting engine, it’s easy to get caught up in the frustration of, “I guess the engine just isn’t designed for this.”  Maybe Unreal just isn’t designed to allow two rockets fired from opposite directions to hit each other in midair and explode.  (I’ll admit…I haven’t actually tried this.)  When you go back to the basics of the engine, though, and re-teach yourself about collisions, weapon mechanics, and the basic functionality of code blocks, you can likely discover that all of the elements you need are there.  You may even look at elements you never considered to be part of the solution before.  The more you learn about those basic elements, the easier it becomes to see how they can all be connected to create the desired effect.

Essentially, treating yourself as a rookie gives you the opportunity to stop looking at problems for what they are and start looking at their component parts a bit more.  By doing so, you get a new opportunity to evaluate your problem and tackle it once and for all.

And after that’s done, I’ve got some more work for you.

If you find yourself stuck and you have the luxury of some extra time, step away from the problem and go back to the beginning.  Revisit what you thought you knew, and then, go further.  Before long, you’ll be able to take what you’ve learned and apply it to the problem you’ve been facing.

Theoretically, anyway.  I don’t offer guarantees.

Thank you.  That is all.

Four Years Later

In early 2008, I was engaged in the second of my two college semesters abroad in Montreal.  I took part in a class called “EGD-310: Interactive Storytelling,” a standard part of the curriculum for Game Design students.  Studying in Montreal, however, carried with it a separate perk.  Our instructor was, at the time, working as the lead writer on a recently-announced project for a brand new studio.  While she declined our half-joking requests to be taken onto the project as her brain trust, she was able to share with us her knowledge and experience from years of writing for video games – knowledge and experience that was being put into action a few blocks away.

Though it’s been nearly four years since I was first exposed to those lessons, I’m now able to see them in action and get a more complete picture of what everything means.   With Deus Ex: Human Revolution finally available, I’ve once again entered a classroom with Mary DeMarle, and it’s interesting to see some of her lessons in action.

This blog post is serving dual purposes.  On the one hand, it serves as a [very] limited review of some of the aspects of the narrative for Deus Ex: Human Revolution.  On the other, and more importantly, it analyzes those aspects in an effort to understand the challenges associated with nonlinear narrative development.  As the game is still a somewhat recent release, I’ll do my best to avoid spoilers.

The Basics of Interactive Narrative

Writing for a game is unlike writing for any other medium.  Even a highly linear game demands much more flexibility and depth than a comparable movie or television script.  Most of the issues involved with writing for games come back to one overarching concern: THE PLAYER WILL NEVER DO EVERYTHING YOU WANT.  As a result, every bit of freedom allowed to the player will alter the game narrative in some way.  Player personalities become projected onto characters and a player’s skills and tactics alter a story’s pacing.  Thus, the individual player’s interpretation of a game character’s interaction with the environment – in a way, the plot – will vary depending on the subject concerned.  As more and more freedom is provided to the player, this sensation grows more pronounced.

The above relationship can apply to either implicit or explicit narrative.  When referring to implicit narrative, player freedom refers to the openness of in-game actions.  A greater number of play styles being available indicates a greater level of freedom for implicit narrative.  When referring to explicit narrative, player freedom refers to a diversity of predetermined story elements, i.e., a branching vs. non-branching storyline.  A non-branching storyline provides one set of established plot points which will always be followed in the same sequence.  In contrast, a branching storyline provides the player with these established plot points, but these plot points don’t always link together, or at least not always in the same way.  A branching storyline is still based upon player choice, but unlike with implicit narrative, the established story points play out in the same way for each player.

While level of rigidity can, and often will, be similar between implicit and explicit narrative elements, it doesn’t need to be by any means.  An open explicit narrative with a rigid implicit narrative is similar to a text adventure or a choose-your-own-adventure novel.  Story progression and endings can be changed, but the path to each will play out similarly any time that story path is followed.  An open implicit narrative with a rigid explicit narrative is similar to what you find in a lot of stealth- or action-based games.  While there’s only one core story to follow, there are a fair number of options for how to progress between each one.  Player actions will have minimal bearing on how the explicit plot plays out, but the player’s interpretation of the story will be highly individualized.

This description is very generalized and may come off as a bit confusing.  For that, I apologize.  In the basic sense, though, what matters is that an open explicit narrative will change the plot for ANY player.  An open implicit narrative will change the way the plot is interpreted by an INDIVIDUAL player.

So where does Human Revolution fall in the spectrum of implicit and explicit openness?  The entire concept of its narrative is centered around a high degree of explicit openness.  There are a range of side missions to choose from, branching dialogue tracks, and a variably open world is provided to allow players the option to complete some mission objectives in differing sequences.  Likewise, the implicit narrative is provided a large degree of openness via a combination of stealth and action tactical options, lethal versus non-lethal weaponry, and an RPG-style upgrading system that changes the gameplay style, but has little direct bearing on how the explicit narrative plays out.  The result is a game with a high level of freedom in both implicit and explicit narrative elements.

By its very nature, implicit narrative is something a game writer has little control over.  The most a game writer can really do is leave gaps in the explicit elements to allow room for interpretation.  Layout for implicit narrative falls more in the hands of game designers, level designers, and artists.  Therefore, for the purposes of this discussion, any further reference to the game narrative will refer to narrative of the explicit variety.

Characterization & The “Hero’s Journey”

Deus Ex: Human Revolution

Player Character: Adam Jensen, Security Manager at Sarif Industries, a biotech corporation that creates cybernetic prostheses for various purposes.

Character Traits: Well, he’s male.  He’s sort of…thirties-ish.  A bit of a Matrix character look about him.  Incidentally, sounds a bit like Keanu Reeves.  And, emotionally, um…well…it depends.

One big challenge a writer of an interactive narrative may face is the prospect of developing the main character.  A character’s personality is illustrated through actions; choices made in a given situation, styles of interaction with other characters, and measures taken to solve (or not solve) a problem all combine to give an image of who a character is.  In a game, the main character is a combination of two personalities: the player and the avatar.  Since the actions taken by individual players, i.e., their personalities, are impossible to predict and player choices dictate how the avatar character interacts with the plot, it’s extremely unlikely that a character will develop as both the writer and player desire.

One solution to this problem is to remove all personality from the avatar and allow the player to start from scratch.  This approach is used in many MMORPGs.  The character created is the creation of the player.  This technique, while effective in the open, unending structure of MMORPGs, doesn’t lend itself well to more traditional “beginning, middle, and end” plots.  A plot based around a three-act structure is expected to build and evolve, and that evolution is shown through the characters.  As a result, the characters are affected by events in the plot – affected in ways that the player might not be.  So how do you generate character traits and development for a character whose behavior is affected by actions that can’t always be predicted?

Deus Ex makes use of a highly structured system of narrative branches and dialogue tracks to dictate what sort of range of options the player has for the type of person Adam Jensen will be.  For instance, the various choices made available in dialogue tracks, which may read as “Cold, Empathetic, Confrontational”, are not absolute.  While they yield different results to accommodate different play styles, each option keeps within the range of the preexisting character traits of Adam Jensen.  Each piece of dialogue expresses the advertised inflection, but is worded so as to lead back to the core character.

Despite the tendency of the dialogue to rein the character back towards the center, enough action in one direction or another will, in the long run, shift Jensen’s character towards one end or another of his established range.  To put it another way, if you stretch a rubber band enough, it will eventually start to lose its elasticity.  The ultimate range of characterization that can be reached is limited to fit within pre-scripted (and often pre-rendered) cutscenes at key points in the story, but it’s enough to create the sensation that the player does have control over the character development process.  For the most part, it seems to be relatively seamless; the player isn’t left with the idea that he’s done something wrong or strayed from the intended character.

The same concept applies to the game’s portrayal of the “Hero’s Journey”.  Human Revolution’s practice of continually driving players back towards key plot points is the main tool used to ensure the integrity of the character development process and the evolution of the plot.  While the narrative structure is based upon branching, it still focuses on classic narrative elements.  Players still progress through a story about a “hero” who is pressed into action by an inciting incident, discovering that not everything is as it seems while facing ever more challenging threats, until he finally uncovers the truth and eliminates the primary threat that led him into action in the first place.  The basic elements of progression and character development are all still there.  The variability lies in the manner in which players move from point to point in that sequence.

Believability

A game with a highly interactive narrative runs into the same problems as one with highly photorealistic graphics.  It’s the classic balance of believability versus realism.  In game that is very realistic in the visual sense, every detail matters.  A low-res texture or an object placement that doesn’t make sense aesthetically becomes all the more noticeable as the visuals reach more and more towards reality.  What might normally be a minor inconsistency that players accept and ignore becomes a glaring error that players note and view unfavorably.  It doesn’t fit – players don’t believe it.  The illusion of the game is broken and a degree of immersion is lost.

In the case of interactive narrative, we run into the same concerns.  Real life has no narrative structure; it is infinitely variable.  We can say or do whatever we want, and those words and actions have different consequences based on the situation and people involved.  Human Revolution attempts to capture a small slice of this interactivity through variable dialogue tracks.  Choosing the right dialogue track for whatever outcome you wish to produce is based upon evaluating the personality of the receiver.  Limits are set in place in terms of how often the player can speak in a given conversation (typically around 4 to 8 times, give or take), how many dialogue choices there are at any one time (no more than 4), and also by the range to which character traits can be maintained.

For the most part, this system blends together well, depending on play style.  Since the believability of the conversation is dependent on the player’s familiarity with the character of Adam Jensen, however, it can take a while for the player to settle in.  The player’s exact choice and inflection of words can’t be reflected entirely accurately, so what a player might think is the best thing to say in a given situation won’t always be available.  As players grow more comfortable with Jensen’s style of speech and ways of thinking, it becomes easier to predict the direction of a conversation and accept a more secondary role in the decision-making process.

Some lines of dialogue do tend to feel a bit unnatural when combined together.  For instance, you might be attempting to convince someone to do something important.  You say exactly the right line towards convincing someone to do something.  A second choice appears, and again, the right choice is made.  The subject is almost ready to do what you want.  Then, you select the incorrect line.  The subject calls you an idiot and thinks you’re being manipulative.  Another choice appears, and you select the correct line again.  Instantly, the subject forgets that you were being ignorant and manipulative, realizes how wrong he’s been, and gives you everything you want. 

Now, in most cases, a situation this minor would easily be interpreted as “fitting into the rules” and would not interfere with the believability of the game world.  However, since the act of pressing through the conversation is centered around a mechanic as undeniably real as human emotion, it becomes easy to notice that something is off.  When something isn’t quite right about someone’s behavior, it’s hard to miss.  

Actions can also interfere with the believability structure, such as in the situation when I ran up to the “boss” character, David Sarif, in the middle of a crisis situation.  With my gun drawn, I engaged him in conversation.  A small cutscene began, and his immediate response was, “What are you doing?  Put that thing away!”  After holstering my gun, I spoke to him again.  Another cutscene began, with David Sarif walking up to Adam Jensen as though he had just entered the room – as though he hadn’t just spoken to him three seconds earlier.  “Oh, Adam, thank God you’re here!”  It seems a bit strange that your employer, for whom you are employed as Security Manager, would be offended that you were carrying a gun in the middle of a life-threatening situation, and apparently so much so that he wouldn’t acknowledge your existence until you put it away.

Conclusions

In the end, what Deus Ex: Human Revolution illustrates about interactive narrative design is that control is key.  Though the game may offer a wide range of story branches to follow, they are all very carefully regulated and deliberately placed.  The degree of freedom players have is far from infinite, and measures are often put in place to ensure that players remain on the Golden Path and keep moving towards the next vital plot point.  Yes, it’s a game about choices and their consequences, but those choices and consequences are all regulated cleverly.  The idea is to provide enough flexibility to generate the sensation or illusion of player control while subtly ensuring that everything eventually leads where it needs to.  In short, the folks at Eidos have done a very good job of tracking and controlling the variables.  The places where the narrative falls down demonstrate a conflict between player and developer control – elements of non-sequitur generated by behaviors that can’t be fully accommodated.

I’ve truly only scratched the surface of the issue of nonlinear narrative design.  I spent the better part of four months learning about it and still can’t quite grasp it all, so I don’t expect to explain it effectively in one blog post.  What’s always interesting, though, is the process of analysis.  It’s always a learning experience.  For instance, four years later, Mary DeMarle is still teaching me about narrative design.