Lessons of Rapid Prototyping

I’ve recently found myself back in school again after three years of post-college oblivion.  Due to the compressed nature of the quarter system, I was presented with the challenge of building a unique game prototype every week for several weeks on end.  I’ve been involved in a small amount of this sort of process with 48-hour game jams, but I’ve never truly faced the prospect of repeated rapid prototyping before.  If there’s one thing the experience has shown me, it’s that many of the concepts you can have about the process of designing a full game go out the window when designing a prototype.  In some cases, what seems immensely important in the design of a full game becomes completely trivial in a prototype.  Other elements that seem like trivial additions to a prototype are actually much more important than they seem.  I’d like to share some of what I’ve learned. 

As I sit here reviewing this entry, it all looks incredibly obvious, which makes me feel a bit embarrassed to bother writing about it.  But the deed is done.  Captain Obvious to the rescue! 

The Difference Between Scale and Scope 

One thing we were repeatedly taught in my undergrad program was to limit both the scale and scope of our projects in order keep the workload reasonable.  While I always knew what was meant by this, I never really bothered to figure out the difference between the two terms as I always found them bundled together.  One thing the process of rapid prototyping has shown me is that scope is everything when it comes to keeping your workload acceptable. 

Now, ideally, you want to have a prototype ready to go before you even make a project proposal, thus limiting the time constraints, but there are still instances in which you’ll find yourself rushed to build a working demo of your game.  If you need a prototype and you need it quickly, scale and scope are two vital considerations. 

Scale, as I’ve come to know it, refers to the size of the game.  How expansive of a game space are you going to deal with?  When thinking in terms of scale, a good place to start is thinking of your overall play time.  Is this a three-hour quirky indie adventure, an epic 40-hour RPG, or a pick-up-and-play casual title that someone can get through in ten minutes at a time?  Determining this can serve as a useful guide for how expansive – and how deep – your gameplay experience will be. 

Scope, on the other hand, refers to the sheer amount of material that goes into the game.  Whereas scale (as per its name) represents size, scope represents density.  How many different gameplay elements will you be dealing with?  How many different characters or assets are to be used?  Perhaps most importantly, how many different functions do you need to code?

This last question is key in rapid prototyping.  As is often said, ideas are abundant in the game industry.  In devising a game concept, it doesn’t take long to come up with a wide array of different skills or abilities an avatar can have or an array of challenges and obstacles the player might face.  If you’re making a prototype to demonstrate a game concept, particularly if you’re the one who designed it, you’ll probably want to give a sample of as many of these elements as possible.  That’s all well and good…as long as you’re capable of programming everything in before it comes time to present your game to a publisher.  The trick, as far as I can tell, is to always assume you can’t do this. 

I know, right?  Way to build up the confidence, pal. 

Now I’m not talking about breaking yourself down (or, if you have separate programmers working on the prototype, breaking THEM down).  As with anything in life, the point is to have a plan, and then, failing that, a backup plan, and then, ideally, a backup for your backup plan.  In the case of prototyping, a good plan should have the backup plan already built into it in the form of an incremental increase in scope.  Start ridiculously small and ridiculously simple, then worry about building up from there. 

This means adjusting the entire nature of the project build as you go.  If you’re designing a prototype featuring one level, that level could be designed in multiple ways depending on how many features are going to be implemented. 

Adjusting Scope through a Modular Design   

Let’s say you’re designing a platformer.  It’s got the basic platforming elements of running and jumping, as well as some other fairly standard ones like double-jumping, speed boosting, and wall jumping.  You’d also like to throw in your personal touch with a unique gravity-alteration mechanic.  You’ve designed a prototype level that demonstrates each of these abilities, requiring each one to be used correctly in order to make it through.  Great.  That should give people a good idea of what to expect from your game. 

Next, you work out a plan for building your prototype.  You’re going to start with the basic platforming mechanics to get the basic setup going.  It’s a platformer, so these elements need to be in place before you can move on.  From there, you’re going to implement your gravity-alteration system.  This is the key to your design – this element distinguishes your platformer from the rest of the market. Without this element, you have nothing to show. 

But then, things start to go wrong.  The physics of the existing platformer mechanics are at odds with what you want the gravity system to do.  This is going to take a bit longer than expected.  No problem – you’ll just skip one of the extra features you wanted to implement.  They’re not vital to demonstrate how the game works, after all.  But there’s another problem – the prototype level you’ve designed incorporates all of these elements.  Your gravity-alteration system doesn’t come into play unless you first use your speed boost and wall jump elements to access the appropriate area.  Now you’ll have to go back and redesign the entire structure of the level because you don’t have time to incorporate one of those elements.  This eats up even more time, forcing you to cut out another feature and redesign the level again. 

Of course, you can’t entirely prevent this from happening, but it’s a much easier problem to avoid in the prototyping stage than it is in production.  This is what I’m talking about when I mention having an adjustable scope and a modular design.  I’m a big advocate of building cohesive game experiences, but a prototype isn’t so much about this careful meshing of elements that you would hope to find in a full game – it’s a demonstration of how your game works.  As a result, a prototype can (and I would argue, SHOULD) be built with many of its key mechanics operating independently of each other.   

For instance, you might craft a level segment that specifically demonstrates the speed boost mechanic, another which specifically demonstrates your gravity-alteration mechanic, and so on.  Ideally, you’ll just be building your level sequence as you go.  If you want to mix things up a bit, you can generate each module and then, as you near the end of the prototyping period, put together what you’ve built to generate a full sequence of events.  This latter approach will likely produce a more connected and cohesive prototype, but it requires an additional design stage. 

Visuals are More Important than You Think 

This isn’t to suggest that you should bring in the professionals to give you fancy character models and visual effects for the sake of a ten-minute tech demo, but keep in mind that the term “video games” contains the word “video” for a reason.  The important thing in a prototype is that you prove the viability of your game mechanics, but the whole point of a video game is to translate all of the mind-boggling numbers and symbols of your code into a format that can be understood without years of training.  If the code works, the player needs to see it working on the screen.  If you shoot a gun, you should at least hear a “Bang!” of some kind.  If you’re charging up for your super-mega-special-energy attack, you should see yourself…I don’t know…glowing brighter and brighter or some such thing.  If you use your “drink milk” function, you should see milk disappear before your eyes. 

The word here is feedback.  It seems obvious when you think about it, but in a way, it’s so obvious that it’s easy to forget about it and simply leave it out.  If the player does something, it needs to be witnessed happening in some way.  It’s important in a prototype for the same reasons it’s important in a full game – to demonstrate that the meticulously-written code is actually doing its job.  The code makes your mechanics run, but the player doesn’t know that without the audio-visual element.  And no, a debug screen is not a viable audio-visual feedback mechanism for the typical player. 

In short, don’t ignore feedback elements in your prototype.  While it’s true you may not need a head to explode in a hyper-realistic shower of gore at this stage, your player will still want to know that the afflicted victim isn’t going to be a threat anymore.  Incidentally, a hastily-placed text box reading “Boom! Headshot!”, may technically be a viable feedback mechanism, but if I see this more than once, I’m going to stop playing your game with immediate effect. 

Drawing the Line Between “Engaging” and “Practical” 

After the experience of completely redesigning a game halfway through its production cycle during my undergraduate program, I hoped I wouldn’t have to go through that process again.  But, silly me, I apparently forgot that I was getting into an industry in which this kind of thing happens without warning.  When you make the discovery that a game simply isn’t fun, bad things happen. 

Ultimately, I’m not sure how common the practice of rapid prototyping is within the industry.  I will say this, though – the day before you’re pitching a project to the higher-ups is not the time to make a fundamental change to the design.  Generating a viable prototype in one week is challenging enough.  Doing it in less than 24 hours is just asking for trouble.  Sure, your game might not be accepted if your prototype isn’t fun, but if you change that prototype at the last minute, it’s still not going to be fun. 

Why do I mention this in reference to prototyping?  The prototype is the first stage of the project where you’ll start to see that your concept isn’t enjoyable.  As a result, it’s probably the stage at which you’re most likely to decide that a massive change is called for.  In general, I would say it’s not something to worry about…if your prototype doesn’t sell the concept, you should have the opportunity to make another one in the future. 

I also mention this simply because I just so happen to have been involved with a prototype that was redesigned from the ground up 12 hours before it was due.  Don’t do this, okay? 

Closing Down 

Whatever the situation may be, it’s better to let your mistakes shine BEFORE you start making a full game.  This is the true purpose of the prototype.  A prototype is a test run, allowing you to give your concept a chance before risking the world.  Sometimes, it can hurt to know that your prized design doesn’t work, but it hurts a lot less to discover that before you’ve invested the time to develop the game. 

Incidentally, prototyping also allows you to imagine, however briefly, that a typical crunch period only lasts for a few days.

The Game Experience (Evolving Definition Pt. 2)

Introduction

In my blog, I’ve spent a lot of time on the subject of game theory.  I’ve discussed the process of game design, what games mean to us as individuals and as a society, and some of the qualities that mark a great game.  Recently, however, I took a look at the larger question of just what games are, especially in a time when we see video games further and further blurring the lines of exactly what a game can be.  As I’ve thought about exactly how games can be defined, I’ve reduced the question down to a terrible argument of semantics – defining the “game” as opposed to what I call the “game experience”.

What is the Game Experience?

The concept of the game experience encompasses not just gameplay, but the total package of what the game is and what it affects.  It’s the game itself, its presentation, its style, the interactions within the community, the nature of the community itself, and the way a game impacts your interpretations of other games, other media, and the rest of the world.  The quality of the game experience isn’t something that can be determined and broadcast on release day like a game’s review scores.  The experiences of games from 30 and 40 years ago are still being written today.

This all factors in with another point I recently raised about the evolving definition of games.  We see a lot of video games out there that can’t really be called “games”, but we don’t have any other good way to describe them.  Perhaps this is another way to look at such games – not as “games” per se, but as game experiences.  If nothing else, we can use this expression in the same way we refer to Velveeta as an “American cheese food product”.

In seriousness, though, an “experience” may be the most reliable term for these non-game games.  They possess some level of interactive player control, so they play something like video games, but that may be as far as the connection goes.  The rest is simply a world built around that interactive nature.  It’s an interactive way to experience a story, an interactive way to view art, or an interactive way to sit and mindlessly roam around, forgetting your troubles.  There’s some element of a game in there somewhere, but what you’re really engaged in, more than anything, is a game experience.

Examples – Game vs. Experience

Of course, “game experience” isn’t an entirely fair definition for quasi-games.  Every game system has its own game experience.  I think the key is in placing emphasis on exactly what it is we’re engaged with. 

In this case, what would be the definition of a game?  Think of something like Tetris.  The game is part of a larger game experience, sure, but when you sit down to play Tetris, what keeps you engaged is the game itself.  The process of rotating pieces, carefully placing them, and dropping them down is a gameplay process.  That’s what pushes you forward, and that’s what keeps you coming back.  When you play Tetris, you’re engaging, primarily, in a game.

Then there are the games we might describe more as game experiences.  Something like Heavy Rain qualifies more in this sense.  You play through game events and participate actively in the process, but the primary driving force behind Heavy Rain is its story.  More than likely, you don’t play it primarily to complete tasks or move through the game world.  You play it to see where narrative events are leading.  The story is a big part of the game and is directly connected to the gameplay, but the primary engagement of the player is not with the gameplay itself.  The player is engaging in a game experience, rather than a game.  Proteus, as I’ve discussed previously, only deals with walking from place to place.  Goals are whatever you make of them.  Now, unless you’re immensely intrigued by the process of walking, Proteus isn’t engaged with as a game.  As you walk and create your own motivations, or even if you engage in the process and simply wonder “What in the world is this and why would I waste my time playing it?”, you’re participating in a game experience.

When we look at the concept of “game” and “game experience” in this way, we begin to run into a high degree of subjectivity.  Whether you engage in a game or a game experience depends greatly on how you approach the game.  Look at Metal Gear Solid.  Many people play it as a game.  They have key motivations to improve their skills, master the mechanics, and be the best damn Solid Snake they can be.  I’m the type who plays it when I feel like watching a movie.  The story drives me forward, and that’s the main reason I engage in the interactive portions.  I approach the game as a game experience.  Something similar could be said of Braid.  Many people seem to view Braid as a work of art – an elegant experience that is a combination of gameplay, narrative, visual art, and music.  In this case, Braid is enjoyed as a game experience.  I’m the type that plays it purely to beat those pesky puzzles.

In one of my very first posts, I discussed (at great length) narrative design in video games, but specifically, how it tied into the controversy surrounding Metroid: Other M.  Not to beat a dead horse, but there’s another point I’d like to bring up.  You see, leading up to the game’s release, Nintendo touted Other M as “the ultimate Metroid experience”.  Now, did it prove to be the ultimate Metroid game?  Absolutely not.  By no means.  But the ultimate Metroid experience?  There’s actually room for argument.  (The answer is still no, but it’s at least a much more accurate assessment.)  Looking beyond the gameplay to the sheer spectacle of the presentation offers a new view on the title.  Looking beyond the title itself to the insanely overblown controversy surrounding it which drew a great schism through a devoted fan base – that provides another layer to the mix, for better or for worse.  Simply put, if you were a Metroid fan, it was quite the thing to live through.

Game Experience as Product

By my definition, the game experience is always larger than the game; the game is always contained within the game experience.  But you may have noticed a key term popping up – motivation.  Motivation is the driving force (the motivating force, I suppose) behind progression through a game.  Motivation to progress from one event to another is a key element of gameplay.  Thus, we’re left with an interesting question…if you’re motivated by the game experience more than the game itself, isn’t that game experience now a part of the gameplay?  But then doesn’t that mean you’re more motivated by the game than the experience?  But then doesn’t that just mean the game experience is larger?  But then are you more motivated by the game or this new game experience?  But if you’re more motivated by the new game experience, then y—oh no, I’ve gone cross-eyed.

In this sense, the relationship between the game and the game experience is somewhat cyclical.  If you’re drawn to play a game for the sake of nostalgia, that’s the game experience drawing you along towards the game’s goal.  If you play a popular game in front of people to make yourself look cool, that’s the game experience propelling you along.  It’s also terribly sad.  I’ve never done this, of course.

So how, then, does this help us define games and quasi-games?  While it’s true that a certain part of the game experience takes place outside the software, some of it can be created as an integral piece of the gameplay and included as a part of the package.  When you first begin a playthrough of Amnesia: The Dark Descent, a block of text prompts you not to play the game to win, but to get involved in the story and environment.  Fans will instruct you to play the game not because it’s challenging or fun, but because it’s scary, visceral, and just generally engaging.  In this sense, Amnesia is marketing itself directly (and indirectly) as a game experience, not a game.

Conclusion

Some games are crafted for the gameplay.  Others are crafted to look beyond it.  Neither is necessarily better than the other, and they both contain shared elements.  They share the same heritage and the same developer motivations to engage and entertain the audience.  However, placing these titles in the same category is proving to be a bit inaccurate.  The way I see it, there’s nothing wrong with marketing a fringe game as a game experience, because that’s what it is.  If the “game” aspect of a game isn’t what’s being sold, it probably shouldn’t be called a game.

But really, you can call it what you want.  I’m not in charge here.

The Evolving Definition

As the game industry has grown and formalized into a more systematic structure over the years, there have been numerous efforts to break the process of game making down into its various components.  How do we create games?  What makes a game fun?  What makes the video game different from other media?  At the core of the industry lies a simple question – one so rudimentary to game development that there’s often no need to even ask it: what is a game?

Of course, professional game developers don’t need to ask what a game is.  It’s something that’s understood somewhere back in the recesses of our minds.  We have an underlying knowledge of what makes a game a game, so we don’t typically need to think about it.  The bigger questions we’re faced with are the questions of how to make a game entertaining, how to make it unique, engaging, immersive, beautiful, and functional.  Generally, the question only comes up when we’re teaching the concept to newcomers. 

“Welcome to Freshman year of your Game Design college program.  This will be your first class.  Open the game design textbook to the first page.  We’ll spend a few minutes discussing this first question.  ‘What is a game?’  Well, let’s take a look at the definition.”

That definition usually reads something like this:

“A game is an activity in which one or more participants work to complete a goal (or set of goals) according to the constraints of a predetermined set of rules.”

This basic definition is held to be the common element between every game ever made.  Every game can be described this way.  It is, after all, the very definition.

While it might be nice to cuddle up with that nice, cozy, clean definition, it’s proving to be less and less reliable all the time.  The indie game scene, in particular, seems bent on breaking down the very definition of what makes a game a game.  Experimental prototypes result in games that remove goals, rigid rules, and consequences, and simply allow players to immerse themselves in a digital world.  Players can experience the game as they see fit.

Now, I don’t want to say this.  I really, really don’t want to say this because of the firestorm it always brings up.  But there is an existing term used for media that exist purely for the interpretation of the viewer.  That term is “art”.

(Warning: Personal Opinions ahead.  I would like to stress this point.)

I regret having to use that word.  I’m not describing video games as art.  On the same note, I’m also not saying that video games aren’t, or can’t be, art.  I am, however, saying that games, based on the strict definition of games, are not typically (in my opinion) art.  Likewise, video games that qualify as art (in MY OPINION) are not exactly games per se.  By divorcing themselves from a rule system or pre-defined goals, these experimental projects remove themselves somewhat from the traditional definition of games.  As they do, they provide an experience that has no real purpose beyond the player’s own interpretation. 

What’s the point of playing this game?  What are you supposed to get out of it?  That’s really up to you.  Some people won’t get anything from it, much like staring at a canvas covered with strange geometric figures yields no impact on the average passerby.  Other people find something significant in it; there’s some deep message being conveyed somewhere inside.  Other people might just think it’s pretty.

What does this have to do with the definition of games?  In the standard concept of a game, the player’s focus is on the completion of existing tasks.  In an artistic piece, a player’s focus is on the product itself.  “What am I experiencing?  What IS this thing?”  As soon as focus shifts from the former to the latter, a game becomes art.  Again, this isn’t to say that what can be considered a “game” cannot also be considered “art” within the same product.  You might take time from completing your goals to simply interpret the game space and create a new experience all your own, but you’re no longer playing the game.  I don’t feel these terms can really be experienced simultaneously.  (The concept of “toyplay” lies within that gray area between gameplay and art, but doesn’t greatly overlap either one.  This discussion can be saved for another day.)

There are (seemingly, at least) a growing number of projects that focus less on the traditional aspects of gameplay and more on the artistic side of this spectrum.  Many people don’t consider these projects to be games.  Still, at the same time, we honor them with video game awards and classify them with other works that are, very much, games.  What this seems to demonstrate is that the term “video game” is, somehow, broader than the term “game”.

Perhaps the real question is, what constitutes a “video game”?  Video games are technically defined as a subcategory of games – games controlled via an interactive, computerized interface.  As a result, however, many other activities controlled by the player through a computer interface are placed under the blanket term “video games”, even though they may not necessarily be games.  This is simply because we don’t have a good way to describe them.

For instance, what exactly is Dear Esther?  It’s not a simulator because it isn’t really designed to replicate a real-world experience (maybe an emotional experience, blah, blah, blah).  Many in the game community don’t like to describe it as a game, either, since it has no immediate established goals.  It has an ultimate endpoint, but so do movies, novels, and songs.  However, if described to someone, the clearest, most basic term to use is “video game”.  The player (or maybe “user”) controls the action and the speed of the progression.  Also, it’s played through a computer.

To take it a step further, what is Proteus?  Proteus has no endpoint, no pre-established goals, no formal story, no consequences for failure (indeed, no failure), and extraordinarily rudimentary graphics.  It’s a very bare-bones representation of the process of exploration.  The player can walk around, and by walking to certain points, cycle forward to the next season at will.  This is the extent of the interactivity in Proteus.  Still, what’s the first term you would use to describe it to someone?  Personally, I would still say, “It’s a video game in which…”

Sure, if you’re talking to a fellow game expert, you might say “It’s not so much a game as it is a ______”.  But if you were to describe it to some random person on the street…

YOU: Hey, have you ever tried out Proteus?

INNOCENT BYSTANDER: What’s Proteus?

YOU: Well, it’s sort of a…virtual world…experience for your computer where you walk around through a digital environment.

BYSTANDER: You mean a video game?

YOU: No, no, it’s not really a video game.  It doesn’t have any goals to complete or anything to do.  You just walk around and experience the environment.

BYSTANDER: So, what, it’s just some kind of sport or something?  You walk around outside and try to experience the world?  Is that anything like meditation or yoga?

YOU: Well, maybe it’s like that for some people, but no, it’s not a physical activity or anything.

BYSTANDER: But you said you go walking around.

YOU: Well, yeah, you go walking around on the computer screen.  You control someone who walks around.

BYSTANDER: I thought you said it wasn’t a video game?

YOU: It’s not.

BYSTANDER: Sounds like a video game.  It’s on the computer.

YOU: But it’s not a game.

BYSTANDER: Well, you walk around in the computer screen.  Isn’t that a video game?

You and the bystander then have an equally fruitful discussion regarding who, exactly, is on first base.

When we say “video game”, the first image conjured in someone’s head isn’t a set of rules or the act of striving towards a goal.  Rather, it’s the image of someone controlling something with a computer.  Maybe you envision motion technology, DDR, or Rock Band.  Maybe you envision trading resources with a Facebook friend.  Maybe you envision an avatar running through a richly-designed virtual world.  In the end, what we think of when we hear the term “video game” is something the player controls.  We think of interactivity.  In a way, the term “video game” is more about “video” than it is about “game”.

After all, if it wasn’t for the computer, we wouldn’t really consider such things to be games.  If you were stranded on an island, walking through sparse foliage and old, abandoned buildings, looking at things while someone told you stories about his dead wife, you would be more annoyed than intrigued.  You wouldn’t call that a game.  If you saw a movie of the same thing, you wouldn’t consider it a game.  However, if you control a character on a screen doing the same thing, a video game is born.

So what, exactly, is a video game?  Where are the lines drawn between film, interactive art, toys, games, simulators, and their kin? 

I think the answer is always pretty clear: these lines don’t really exist.  All of this genre-bending doesn’t just skew the definition of what constitutes a video game, but of what constitutes a game itself.  Is a quest to understand something a game?  There’s a goal to complete.  You’re restricted by life’s rules.  You’ll likely obtain enjoyment from the experience.  By that token, going to a museum and interpreting modern art can be seen as a game.  Making that art can be seen as a game.  As the semantics break down, my previous argument becomes meaningless: if art is a game, then a game can be art.

The basic point is that it doesn’t seem all that worthwhile to attempt to classify a concept that is as subjective and situational as a game.  Games are things that can’t be described, but instead have to be experienced.  Is it a game?  Is it art?  Is it a mindless display of graphic violence?  Is it something else altogether?  Our own experiences are all that can answer that question.

Maybe that’s why I get so frustrated when people ask me what my favorite genre is.

Jamming with Purpose

Applying for jobs in game development can be an exhausting and massively frustrating experience. To be considered a viable candidate for any position, you need to keep building your skill set, work on using your existing skills to build a portfolio, and all the while, find the time to support yourself in the absence of game-related employment. As most career advisors will tell you, however, perhaps the most important thing to do when job hunting is to go out into the world and network. As it’s said, it’s sometimes less about what you know than it is about who you know.

As it stands right now, there are a number of great ways to go about networking with fellow game developers. The big conferences allow the opportunity to meet and talk shop face-to-face. Groups like the IGDA allow members to work together to solve problems and explore new possibilities for the industry on a regular basis. Perhaps one of the most useful tools for meeting other developers, however, is the humble and always-exciting game jam.

Game jams are a great way to meet and work with fellow game developers. For a few days, people can see what they can do when they join forces within a tightly-constrained atmosphere. The chief reason game jams serve as a great networking tool is simply that they allow people to make games. A jam isn’t just a discussion about everyone’s latest projects or backgrounds, but a direct vision into the participants’ development philosophies and skills.

The interesting thing about jams, which is perhaps due to their heavy time constraints, is that they almost always seem to be very informal events. This is a good thing. Jams are generally seen as a good way to relax (if “relax” is the right word) and give everyone’s creative skills a quick boost. When it’s all over, people go their separate ways with a hearty, “Well done, and good luck. It was nice working with you.” Some maintain contact, while some fall off the radar. Again, this laid-back atmosphere is a nice feature.

However, I feel a good opportunity is often overlooked in the realm of the game jam. A jam has the ability to fulfill a more formal, professional purpose. What I’d like to see more of (and indeed, I’m not sure if anyone does this at all) is the use of game jams as recruitment tools for game companies.

The Existing Process

A company looking to bring on new employees can examine the skill sets of their applicants all they want. The hiring process tends to follow a similar pattern from studio to studio. Job hunters submit their applications, typically with a cover letter and résumé. Some force, usually an HR associate or a set of computer algorithms, searches through those initial applications for keywords and presentation. Those candidates fitting the bill are sent along to the appropriate department leads, examined in greater detail, and contacted. Through a few stages of interviews, employers learn about the candidates, get a sense of how they operate, and whittle down the list further. In the later stages of the interview process, some present basic tasks for applicants to complete, thus providing a better glimpse into what each candidate may offer the company.

In the end, what’s the main purpose of all of this? Companies want to get a clear idea of which candidates are the best fit for the job. How do these people work? Does their work style fit in with our needs? What are they capable of? What might we expect when we set these people to work on a game project? Essentially, the entire application process is about the company determining whether or not you’ll be able to make games with them.

As far as I see it, there’s a much better way to accomplish this task than simply through this traditional “apply-interview-analyze” process. Frankly, if I wanted to see if potential employees were capable of making games with the team, I’d have them do exactly that – make games with the team.

The value of game jams has been under a bit of examination lately. They’ve always served a purpose in the form of providing a challenge and allowing jammers to network on a basic level, but companies are starting to see a more practical application for game jams, as well. Intra-office game jams are used to loosen up employees, generate some quick new ideas, and re-spark a creative drive. They get team members working together in some new ways, giving a new life to projects that can drag on for years. (One of my college friends, Auston Montville of Tagged, Inc., gave a useful talk on the subject at GDC 2012.)

Studio-run jams generally seem to be limited to existing studio employees. There’s nothing wrong with this, but I feel a great networking opportunity is being overlooked in such a private session. I’d like to see a greater effort for game studios to host public jams that can connect professional game developers to, shall we say, “outsiders”.

Two Approaches

There are several ways in which I can see studios approaching a more open sort of game jam. In my most ideal vision, a studio would arrange a jam open to anyone who takes the time to register (taking into account capacity limitations). Registrants are placed into mixed teams with employees. For a couple of days, the various teams work to complete their projects, just as they would in any other game jam. This not only gives amateurs and newcomers valuable hands-on experience with game professionals (not to mention valuable professional contacts), but it also provides the studio with a glimpse at the newcomers – their work style, their character, and their potential. If nothing else, the outside participants meet another group of people – a very useful group, mind you – who can attest to the quality of their work.

What I like about this approach is that it takes place with no real obligation on either side. Employees can intermingle with non-employees with no real expectation. All everyone is here to do is meet a few new people and make a game. No strings attached.

Perhaps a more purposeful and targeted approach to such a jam, though, would be in the form of a job interview. Such an event would still be specific to the company, just as the intra-office model, but instead of utilizing only employees, the jam would invite along job candidates. This wouldn’t necessarily include everyone who applied for a job. More likely, it would include only callbacks, essentially taking the place of an interview. Just as with the jam above, applicants are grouped together with employees for a quick couple of days of game development. Not only do employers get a good look at how their potential employees operate in a high-pressure development scenario, but candidates get to compete with each other in a professional and fun environment, rather than simply waiting and hoping for the best. Even those who don’t come out of the process with jobs have been through a full development cycle (albeit compressed) with industry professionals. As an added bonus, people on both sides may come out of the experience with new ideas for current or future projects.

Final Thoughts

These scenarios wouldn’t always be viable options, of course. They would be at their most useful at the beginning of a development cycle when large numbers of new hires are taken on at once and employees aren’t yet locked into a firm development schedule. However, studios that make occasional jams a part of their regular operation have numerous opportunities to expand those jams to a more public arena, as well.

I’m also not suggesting that game jams should completely replace the traditional application process. A professional interview and personal presentation are both still important parts of determining a person’s viability as an employee. But jams offer us the opportunity to interact in a unique way, and it’s a style of interaction that says a lot about how we go about our work.

Perhaps these are just the words of someone frustrated with the traditional job application or traditional networking practices. Whatever the case may be, though, I do sincerely believe public company-sponsored game jams have a future. I’m not sure they’ll actually catch on, but I believe they have considerable practical applications. There are elements of this process at play in many places, but not quite on the level I’d like to see. The idea of encouraging professional game developers to work with newcomers in a short, energetic development process holds a great deal of potential for all parties involved.

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.