Level 2: Game Design / Iteration and Rapid Prototyping

Last time we asked the question: what is a game? Today, we look into a related question: what, exactly, is game design? Last time, we made a simple game. This time, we will look into the process of how games are made in general. While it is possible to make a race-to-the-end board game in 15 minutes, you will need to take a little longer if you are looking to make the next Settlers of Catan or World of Warcraft.

Course Announcements

Some administrative things that have come up since Monday:

First, I would like to apologize to those who are registered for the misbehavior of the wiki. It was sending out hourly announcements of updates… and there were a lot of updates! I have attempted to turn off these updates, so you should hopefully not receive any more “wiki-spam” but if you do, you can shut it off manually by going to your own settings and changing notifications to “Never.”

As of 5am GMT this morning, the discussion forums are set up and operational. I look forward to seeing some really great discussion. There were quite a few spambots that tried to register, so I had to check every forum account against course registrations. If you got an email that your account was rejected, it just means I was unable to match it up to a course registration; please try again. If you have not yet created a forum account, you can make it easiest for me by using the same email on the forums that you used to register for this course… and if you’re unwilling to do that, at least put some kind of identifying information in there (like your name and location) so I can find you in the list. Thank you.

Lastly, to those of you who sent in a registration email after the course started (that is, if your email was timestamped after Monday, noon GMT), I apologize for not being able to add you after the fact. Registration emails have taken a lot of my time prior to the start of the course, and if I accept late registrations I will not have the time to do other things for the course. Whether you are registered or not, this blog is free and open to the public (as is the Twitter feed), and I hope you do still follow along and get a lot out of the experience.

Game Design

We will use the word “design” a lot in this course, and unfortunately it is a term that is a bit overused, so I will clarify what I mean here. As it says in Challenges, game design is the creation of the rules and content of a game. It does not involve programming, art or animation, or marketing, or any of the other myriad tasks required to make a game. All of these tasks collectively can be called “game development” and game design is one part of development.

Unfortunately, I have seen the term “design” used (particularly in some college curricula) to refer to all aspects of development. When used in the video game industry (or the board game industry), “game design” has a very specific meaning, and that is the meaning that we will use for this course.

Multiple Types of Game Design

As mentioned in Challenges, there are many tasks associated with game design: system design, level design, content design, user interface design, world building, and story writing. You could fill several 10-week courses with any one of these, so this summer course will not be a full treatment of the entire range of game design. We will touch lightly on UI, story writing and content when relevant, but the majority of this course focuses on system design (also sometimes called “systems design” or “core systems design”).

System design is about defining the basic rules of the game. What are the pieces? What can you control? What actions can you take on your turn (if there are “turns” at all)? What happens when you take each action, and how does it affect the game state? In general, system design is the creation of three things:

Rules for setup. How does the game begin?

Rules for progression of play. Once the game begins, what can the players do, and what happens when they do things?

Rules for resolution. What, if anything, causes the game to end? If the game has an outcome (such as winning or losing), how is that outcome determined?

If you look back at Three-to-Fifteen from Monday, you’ll notice those very simple rules contain all of these parts. The creation of those rules is system design, and that is what we will be spending most of our time with over this summer.

What is a Game Designer?

As you may have noticed, game design is an incredibly broad field. Those of us who are professional designers sometimes have trouble explaining what we do to our families and friends. Part of the reason for this is that we do so many things. Here are some analogies I’ve seen when trying to explain what it is like to be a game designer:

Game designers are artists. The term “art” is just as difficult to define as the word “game”… but if games can be a form of art (as we saw in Costikyan’s definition, at least), then designers would be artists.

Game designers are architects. Architects do not build physical structures; they create blueprints. Video game designers also create “blueprints” which are referred to as “design docs.” Board game designers create “blueprints” as well — in the form of prototypes — which are then mass-produced by publishers.

Game designers are party hosts. As designers, we invite players into our space and try our best to show them a good time.

Game designers are research scientists. As I will touch on later today, we create games in a manner that is very close to the scientific method.

Game designers are gods. We create worlds, and we create the physical rules that govern those worlds.

Game designers are lawyers. We create a set of rules that others must follow.

Game designers are educators. As we will see later when we start reading Theory of Fun, entertainment and education are strongly linked, and games are (at least sometimes) fun because they involve learning new skills.

If game design is all these things, where would it fit in a college curriculum? It could be justified in the school of education, or art, or architecture, or theology, or recreation management, or law, or engineering, or applied sciences, or half a dozen other things.

Is a game designer all of these things? None of them? It is open for discussion, but I think that game design has elements of many other fields, but it is still its own field. And you can see just how broad the field is! As the field of game design advances, we may see a day where game designers are so specialized that “game design” will be like the field of “science” — students will need to pick a specialty (Chemistry, Biology, Physics, etc.) rather than just “majoring in Science.”

Speaking of Science…

How is a game designed? There are many methods.

Historically, the first design methodology was known as the waterfall method: first you design the entire game on paper, then you implement it (using programming in a video game, or creating the board and pieces for a non-digital game), then you test it to make sure the rules work properly, add some graphical polish to make it look nice, and then you ship it.

Waterfall is so named because, like water in a waterfall, you can only move in one direction. If you’re busy making the final art for the game and it occurs to you that one of the rules needs to change, too bad — the methodology does not include a way to go back to the design step once you are done.

At some point, someone figured out that it might be a good idea to at least have the option of going back and fixing things in earlier steps, and created what is sometimes known as the iterative approach. As with waterfall, you first design the game, then implement it, and then make sure it works. But after this you add an extra step of evaluating the game. Play it, decide what is good and what needs to change. And then, make a decision: are you done, or should you go back to the design step and make some changes? If you decide the game is good enough, then that is that. But if you identify some changes, you now go back to the design step, find ways to address the identified problems, implement those changes, and then evaluate again. Continue doing this until the game is ready.

Make an observation. (“My experience in playing/making games has shown me that certain types of mechanics are fun.”)

Make a hypothesis. (“I think that this particular set of rules I am writing will make a fun game.”)

Create an experiment to prove or disprove the hypothesis. (“Let’s organize a playtest of this game and see if it is fun or not.”)

Perform the experiment. (“Let’s play!”)

Interpret the results of the experiment, forming a new set of observations. Go back to the first step.

With non-digital (card and board) games, this process works fine, because it can be done quickly. With video games, there is still one problem: implementation (i.e. programming and debugging) is expensive and takes a long time. If it takes 18 months to code the game the first time and you only have two years, you will not get a lot of time to playtest and modify the game.

In general, the more times you iterate, the better your final game will be.

Therefore, any game design process should involve iterating (that is, going through an entire cycle of designing, implementing and evaluating) as much as possible, and anything you can do that lets you iterate faster will usually lead to a better game in the end. Because of this, video game designers will often prototype on paper first, and then only get the programmers involved when they are confident that the core rules are fun. We call this rapid prototyping.

Iteration and Risk

Games have many kinds of risk associated with them. There is design risk, the risk that the game will not be fun and people won’t like it. There is implementation risk, the possibility that the development team will not be able to build the game at all, even if the rules are solid. There is market risk, the chance that the game will be wonderful and no one will buy it anyway. And so on.

The purpose of iteration is to lower design risk. The more times you iterate, the more you can be certain that the rules of your game are effective.

This all comes down to one important point: the greater the design risk of your game (that is, if your rules are untested and unproven), the more you need iteration. An iterative method is not as critical for games where the mechanics are largely lifted from another successful game; sequels and expansion sets to popular games are examples of situations where a Waterfall approach may work fine.

That said, most game designers have aspirations of making games that are new, creative, and innovative.

Why This Course is Non-Digital…

Some of you would rather make board games anyway, so you don’t care how video games are made. But for those of you who would love to make video games, you may have wondered why we will be spending so much time making board and card games in this course. Now you know: it is because iteration is faster and cheaper with cardboard. Remember from Monday: you can make a board game in 15 minutes. Coding that game will take significantly longer. When possible, prototype on paper first, because a 15-minute paper prototype and an hour-long playtest session can save you months of programming work.

Later in this course, we will discuss in detail methods of paper prototyping, both for traditional board games and also for various types of video games.

There is another reason why we will concentrate primarily on non-digital games this summer, particularly board and card games. This is a course in systems design, that is, creating the rules of the game. In board games, the rules are laid bare. There may be some physical components, sure, but the play experience is almost entirely determined by the rules and the player interactions. If the rules are not compelling, the game will not be fun, so working in this medium makes a clear connection between the rules and the player experience.

This is not as true in video games. Many video games have impressive technology (such as realistic physics engines) and graphics and sound, which can obscure the fact that the gameplay is stale. Video games also take much longer to make (due to programming and art/audio asset creation), making them an impractical choice for a ten-week course.

The connection between rules and player experience is also muddied in tabletop role-playing games. I realize that many of you have expressed an interest primarily in RPG design, so this may seem strange to you. However, keep in mind that an RPG is essentially a collaborative story-telling exercise (with a rules system in place to set boundaries for what can and can’t happen). As such, a wonderful system can be ruined by players who have poor story-telling and improv skills, and a weak system can be salvaged by skillful players. As such, we will stay away from these game genres, at least in the early stages.

Trying it out

Take that 15-minute game you made last time, and play it, if you haven’t already. As you are playing, ask yourself: is this more fun or less fun than playing your favorite published games? Why? What could you change about your game to make it better? You do not have to play the game to completion, but only for as long as it takes you to get the overall feeling of what it is like to play.

Then, after playing once, make at least one change. Maybe you’ll change the rules for movement, or add a new way for players to interact. Maybe you’ll change some of the spaces on the board. Whatever you do, for whatever reason, make a change and then play again. Note the differences. Has the change made the game better, or worse? Has this one change made you think of additional changes you could make? If the game got worse, would you just change the rule back, or would you change it again in a different way?

We will be looking at the playtest process in detail later in this course. For now, I just want everyone to get over that fear: “what if I play my game and it sucks?” With the game you designed on Monday, the odds are very high that your game does suck (seriously, did you expect to make the next Gears of War in 15 minutes?). This does not make you a “bad designer” by any means — but it should make it clear that the more time you put into a game and the more iterations you make, the better it gets.

Lessons Learned

The one big takeaway from today is that the more you iterate on a game, the better it becomes. Great designers do not design great games. They usually design really bad games, and then they iterate on them until the games become great.

This has two corollaries:

You want to have a playable prototype of your game as early in development as possible. The faster you can playtest your ideas, the more time you have to make changes.

Given equal amounts of time, a shorter, simpler game will give a better experience than a longer, complicated game. A game that takes ten hours to play to completion will give you fewer iterations than a game that can be played in five minutes. When we start on the Design Project later in this course, keep this in mind.

Homeplay

Before next Monday, read the following. I will be referencing these in Monday’s content when we talk about the formal elements of games:

Challenges for Game Designers, Chapter 2 (Atoms). This will act as a bridge between last Monday when we talked about a critical vocabulary, and next Monday when we will start breaking down the concept of a “game” into its component parts.

Formal Abstract Design Tools, by Doug Church. This article builds on Costikyan’s I Have No Words, offering some additional tools by which we can analyze and design games. While he does use many examples from video games, think about how the core concepts in the article can apply to other kinds of games as well.

QC (= Quality Check) is testing. QA is about making sure that all things and processes go right. Not in the code only. QA covers all game content and features including usability and game design itself. If everything is documented properly it can be tested.

I’m not an Agile guru so I’ll take B. Waite’s comment at face value. I would say that if this is the case, in game design I would certainly prefer to fail early and often. “Failure” in this case is not a bad thing, it is a necessary part of the process. After all, if you don’t know whether a game will be fun or not, that means there is a chance that it will not be. You want to know this as early as possible so that you can either modify your design accordingly, or kill it and start over.

I’ve done some SCRUM for game development and the difference between that and non-SCRUM rapid prototyping is blurry at best.
B. Waite’s definition makes a lot of sense and in theory this would be exactly what it is but in practice the differences can be miniscule.

Not all agile systems use rapid prototyping or formal iterative processes though.

I guess the difference is that with the rapid prototype, you try to make a full game, with all the rules, test it, and change if it fails; but in an agile methodology, you would build the smallest game you know would work (ie. with one rule) and then in the next iteration add one rule.

As Grétar said, the difference is quite blurry. Really I don’t think you’d use agile methods, as they are born from having a customer who has specific requirements. With the game design process, you are as yet unsure who your customer might be and are just trying to build something fun.

For those who are interested in video game design, you can check out http://www.gamecareerguide.com/ and enter in their design competitions. They require no programming or drawing, but are optional. They usually give 2 weeks to design a concept on the theme/idea of the contest, and a contest appears about once or twice a month. These contests usually don’t take much time because they limit you to 500 words and 3 pictures. (A new contest was started yesterday on Wednesday)

I’ve entered into their previous contest and found that I was using iteration. I conceptualized ideas, ‘played’ it in my mind, evaluated it, then improved on it and repeated these steps. It is a good place to practice this skill in an environment filled with people already in the video game industry with entries.

If anyone know of any other sites running similar contests that focuses on design (for any type of game), please share with us.

“As mentioned in Challenges, there are many tasks associated with game design: system design, level design, content design, user interface design, world building, and story writing.”

“As it says in Challenges, game design is the creation of the rules and content of a game. It does not involve programming, art or animation, or marketing, or any of the other myriad tasks required to make a game.”

can you go into detail about why story writing is considered game design, while, say, art and programming are not?

the rules of hugely successful games like street fighter or even super mario bros. are deeply intertwined with their assets.

for example, in most 2d fighting games character sprites have to be appropriate for each character’s hitboxes, which leads to a two way street where the hitboxes – in other words, the rules – influence the art, and vice versa.

are there many examples of successful games in which the story is as integrated with their rules? (i can think of a few possible examples but none of them are hugely successful. of course i’m not arguing that popularity = quality, but it is a decent way to at least identify successful approaches to game design)

You bring up a great point. Design can influence and be influenced by other aspects of development. The hitbox example you give is a great case where art and design intersect with each other (and also with programming — we use rectangular hitboxes for a reason).

And you are right that it may seem arbitrary to lump story writing together with core systems design, but keep art or programming separate. The main reason I do this is convention. At most game studios I’ve seen that have dedicated story writers, they are working in the game design department; for studios that do NOT have dedicated story writers, it usually ends up being the game designers (as opposed to the artists or programmers) who write the story. I invite others to weigh in on this, and give their own reasons why these fields may or may not fall under the same umbrella of “design.”

As for integration of story and gameplay, we will touch on that later when we talk about nonlinear storytelling, and I don’t want to get too far ahead of myself 🙂

First, if we make laws, wouldn’t that make us legislators rather than lawyers?

Second, while it does not bother me at all, some might feel this course is a bit too USA-centric: right at the start of the book, it proposes an exercise on the American Civil War (most non-USA people won’t know very much, if anything, about it), and right now you used “this summer”, which isn’t true for all of us ;)… And I think there was a reference to American Football somewhere, too? (Can’t remember if that was in Challenges or in some other book I recently read.)

But I’m just being pedantic… Like I’ve said, I don’t mind it whatsoever. Keep up the good work! I’m really enjoying it so far.

As for this being US-centric… admittedly, this is the first time I’ve taught to an international audience using this book. There’s a maxim that you should write what you know about, and both Brenda and I have lived in the States, so we are probably guilty as charged 🙂

These are things I hope to learn during the course. It is a big experiment, after all. (So, if I can’t refer to the next ten weeks as “this summer”… what is the correct way to refer to this block of time that is correct for both hemispheres? “Q3 2009” just sounds too buisness-like.)

In my defense, I did at least know enough to specify American Football (this was in the first lesson) as opposed to merely saying “Football” and confusing those Americans who don’t know what Soccer is properly called 😉

Iteration is one brick wall I’ll have to get around, over, under or through. Hey…I just got the basis of a game! LOL. But for us people with ADHD repetition is the bane of our existence. But I know that it has to be done.

Also, and interesting concept has started to emerge for me. Starting with the smaller components of a larger game and using iteration to test out those components. That seems to be somewhat implied in the lesson here.

While we will concentrate on more simple games throughout the course…how about taking several simple ideas and merging them into a bigger game? I know that is a process used in most video game design today. The sticky part has become putting everything together to form the greater whole.

Federico: As I understand it, there’s a lot of overlap, but “agile” is a bigger concept than just rapid iteration.

Coming from software development, agile methodologies include a wide range of methods which are similar but not exactly the same; usually rapid iteration is a common feature, but there’s also a greater emphasis on increased communication and collaboration. (eg. Extreme Programming with its pairs of programmers, or Scrum with its small task-focused groups.)

Agile software development also tends to place more emphasis on code refactoring, which in layman’s terms generally means reorganizing code to make it more readable or sane without changing how it actually works. I don’t think there’s a direct parallel to this concept in game design.

Highly iterative design with rapid prototyping is a good fit with the rest of the ideas, but they aren’t strictly necessary.

Johsg, you say “Agile software development … [has] more emphasis on … refactoring, which … means reorganizing … without changing how it actually works. I don’t think there’s a direct parallel to this concept in game design.” Clearly the 3 to 15 game was a direct refactor of tic-tac-toe.

I see lots of examples in game design of refactoring. When I generated my 15 minute game, “Systems Engineering,” I thought about tracking the values on the Analysis and Design leg with chits, and “refactored” in my mind to track by having the player write down on a paper player-board. This change doesn’t change the “system design”, but does change the mechanics of how to implement that system design into something hopeful easier for players.

You could say agile development is like taking rapid prototyping even further and applying it to the entire design process.

The idea of agile is to fix issues in development caused by a lack of central communication between departments; over-scheduling until there is no room for changes; a lack of knowledge on the full design (say you are told to model of a house for level 25. you get to see what else is on level 25, concept art and such. but what is on level 24 or 26?); and as stated previously, the issue with finding flaws in gameplay too late to fix.

In Agile Game Development, the entire team is generally set into smaller groups for short scrums (Daily 15 min meetings, where the team meets standing up and each person states one at a time: what they were supposed to accomplish during the time between the last meeting, what they finished, what issues or problems they are having, and if they require help with anything). Milestones are generally decided at regular intervals, allowing teams to base schedules on what is needed as the process goes on.

Larger meeting are then set up regularly to review everything that has been accomplished so far – what is going well, things that need to change/be fixed. All of this is to strengthen communication and make sure that EVERYONE on the team knows what is going on and doesn’t get lost somewhere along the way.

Generally in agile, there is also no formal written design document, or there is a shorter document as an overview of the full design and is not extremely detailed.

“Generally in agile, there is also no formal written design document, or there is a shorter document as an overview of the full design and is not extremely detailed.”

While emphasis on documentation is less in agile, it is still often very important. We used SCRUM for a project I was on and we saw a reason to maintain very careful documentation because some of the project would eventually be handed off to others.

Ian: May I ask you to specify what you mean by the word ‘fun’? It’s become a pet peeve of mine, because it’s a word that’s thrown around a lot when it comes to games, but everybody means a different thing by its use.

Nice lesson but I have a question on the methods of game design. I’ve been studying software design and development (SDD) at school and I’ve been taught some other methods to make software in general. So would an end user approach apply to making games?
Also, a question for the iteration and risk section. Do you need to consider market risk if you’re making an indie game?

Although, as it first comes to mind, “market risk” is related to the cost-profit relation in a game, that is, “will it sell enough or not?”, which is something we normally think doesn’t apply to indie games, since they’re not being sold after all, it is still important to this kind of game if you look at their “selling” aspect in terms of “will people play it or not?”.

No matter if it´s a free Flash game you submit to Newgrounds or something you put on your own personal website, there is a point in making an indie game, which is, unless you’re making it “just for the fun of it”, building a portfolio or strengthening your name as a brand in the industry with the objective of actually breaking into that industry afterwards. No matter what, you’ll have to get people playing it. For an indie game this is the “market risk”: will it give me enough visibility?

There are also lots of indie game developers out there who intend to make some money off their games (of course, being realistic about how much you’ll make helps a lot in this aspect). In which case market risk is the same as Ian’s definition. But Bruno wrapped it up really well. Even if something is free, people won’t care about it if they don’t like it.

This really made me think about contemporary games (mostly MMOs), and I fear that the IMPLEMENTATION-PLAYTESTING-QA-(Re-EVALUATION) part of the rapid iterative design cycle usually comes too short nowadays.

Time and money may be the reasons for that!

I was especially thinking about Guild Wars, the designers usually have great ideas, but some of them really fell short in practice or were implemented in a way that really diminished them.

The term Game Space in the book is used to refer the area the game is played in. I have also heard the phrase used to mean every possible game playable with a game system. So as you play you are exploring the game space.

I am not sure where I have picked up the meaning from, but it is pretty ingrained in my use of the term, so if anyone knows the source please let me know (I suspect its from something to do with abstract gaming or combinatorial maths).

I think the term you may be thinking of is “possibility space” — but you’re correct that “game space” could mean either. In retrospect that blurb about game space on p. 26 is something we should redo for clarity if there’s ever a 2nd Edition 🙂

I was wondering the same thing. I planned on going ahead with some or all of them depending on how Ian continued with the course (I’ve almost finished my Level 2 Race to the End rules.) Then I noticed on the Forum that Ian will be Challenging us on Monday. So….not sure what that will be exactly.

Not really, as I hadn’t intended for it to go through a formal peer review process. The whole point of the 15-minute challenge was to get people over their fear of creating their first game… not to actually create something “good” 🙂

That said, a number of participants have posted their 15-minute projects on the course wiki, so that has become the unofficial collecting place.