The "Unplugged" Album

(If, for some reason, you feel you need a more direct connection to my brain, this blog is also available at http://welcometogameland.blogspot.com.  It's a different color.  That's about it.)

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.