Flash and JavaScript are required for this feature.
Download the track from iTunes U or the Internet Archive.
Description: This lecture begins by exploring what a game is (and isn't) and defining the terms "mechanic" and "dynamic". Designers identify the core mechanic and dynamic of a game to help guide iterative playtesting and optimization.
Instructors/speakers: Philip Tan, Jason Begy
Lecture 2: Iterative Design
Related Resources
[CGD] Chapter 1
Zimmerman, Eric. "Play as Research: The Iterative Design Process." July 8, 2003.
The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make a donation or view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu.
PROFESSOR: This is our first lab session for CMS.608 and, for folks, who wasn't here this past Wednesday? One, two--
AUDIENCE: Who wasn't?
PROFESSOR: Who was not here on Wednesday?
[INTERPOSING VOICES]
PROFESSOR: And so, you weren't here. Let's see, we have some blank index cards underneath the--
AUDIENCE: The plastic Tupperware, I think.
[INAUDIBLE]
PROFESSOR: So you can just fill in your name, your email address plus favorite board game or card game. The email address, basically, just gets added to the email list. Did anyone not get an email from Jason yesterday?
AUDIENCE: Yeah, last night.
PROFESSOR: You didn't get an email?
AUDIENCE: I don't think so.
PROFESSOR: OK. So the email basically said that there was a swap
[INTERPOSING VOICES]
PROFESSOR: --of Friday the 17th, and the 20th. So, basically, we're swapping your readings around-- and that's really the only thing, right?
AUDIENCE: Oh, and I fixed the link for Zimmerman's article.
PROFESSOR: And, unfortunately, Eric Zimmerman didn't migrate his website terribly well, so all of his pictures--
[INTERPOSING VOICES]
PROFESSOR: I actually have one of his games, SISSYFIGHT 3000. In fact, this is before SISSYFIGHT 3000, so this is probably 2999, which is going to be the non-digital version, which is the whole point. It is actually a computer game. It is a pretty decent flash multiplayer game, back in the day when flash multiplayer games were not that common. And if you haven't played it before online, after today, especially if you had a chance to play with the card deck, try out the online version. Do a Google search for SISSYFIGHT 3000, and try it online. Hopefully, there are still people playing it, because you need kind of like a minimum of five people to get a good game going.
AUDIENCE: [INAUDIBLE] the one that was taken down.
AUDIENCE: Aw, suck. It was such a great game.
PROFESSOR: Never mind. Basically, what you had was, you got avatar customization in your game. You could create your character, and you could-- you had this really cool retro pixelated look back in the day when retro pixelated stuff was not that popular yet. But the game-play was pretty much exactly the same as what a card game has.
The readings today basically covered a lot of jargon that we're going to be using a lot of that for the rest of the class. For the most part, I'm not going to go through every single one of them because you folks can read. And if I mention something and you don't get it, you can always check back there.
So just remember that the first chapter in Braithwaite is a pretty good glossary of terminology that we're going to keep using. But one of the big things that they ask is, what is a game? And it's one of those-- Does anybody actually want to offer their definition of what a game is?
AUDIENCE: A game is something that involves players and they set up, define rules beforehand, rules that you have to abide by, whether they be, you can't go outside this limit, you have to abide by certain questions and orders. Something that has structure that is meant for one person to go from Point A to Point B.
PROFESSOR: OK. Structure, rules, limits, players. Anything--
AUDIENCE: It's fun.
AUDIENCE: Fun.
AUDIENCE: It accomplishes some goal.
PROFESSOR: Goal.
AUDIENCE: So you always have some goal.
AUDIENCE: You're working towards something.
PROFESSOR: Anything else?
[INTERPOSING VOICES]
AUDIENCE: Or it's an abstract system. Often an abstraction of some real system.
PROFESSOR: An abstract system. So these are actually pretty good benchmarks. Now there are, again, as Brandon describes, there isn't one that's just the canonical answer for everything. It really depends on which theorist you are reading at any given time.
But usually it will involve a significant subset of all of these in the definition. And I like to keep things broad and vague because, for the most part, if you define yourselves too strictly, it might be useful. You're an academic and you need to write papers about it, but if you're a designer and you're just trying to create something fun-- the word I would use is "engaging," because fun means a lot of different things to a lot of different people.
Engaging basically means that this is going to be something that you're going to want to do for a while, that is motivating. It might be terrifying you out of your wits. Some people enjoy that, or would find that experience compelling. I mean they may not call it fun. So I call that engagement.
The problem with using fun and engaging as a metric for defining what a game is, is that that means that a bad game is not a game. A game that fails to achieve fun, that fails to be engaging, is not a game. But I wouldn't go that far, largely because that means a lot of stuff that I created is not a game.
But it should give you the-- there is no magic point where a game becomes --the thing that you're building becomes fun and then suddenly becomes a game. I can't even imagine someone making that argument, that it's not a game until it's fun. But I much rather sort of say, fun and engagement is kind of more of a metric of how well designed your game is, not necessarily whether your game is a game. But that is a goal of a game designer, to try to create an engaging experience, something that people are going to want to do.
I know some game designers who think that is not, in fact, their job. Their job is to maximize revenue, for instance. Especially if you work in social games, there's a lot of discussion now in how business and game design is basically just one thing now. The whole point of game design is, how do we get people to pay a little bit more? Zynga's going to be in town on September 20th, they're giving a talk. That has those two points in it.
[INTERPOSING VOICES]
PROFESSOR: So I always thought of design as something that you're working towards. But all these other things-- a game should have players. Again, I don't want to be too strict on that because I've certainly seen games that play themselves.
Anyone here involved in Battle Code? That game pretty much plays itself, right? I mean, you set it going and then one side wins, but there's no human person at least during the time when the games actually being played. Or you could argue that the whole course of Battle Code-- for those people who don't know it, it's an IP course, I believe, where Course 6 students basically write bits of AI to play a real-time strategy game against some of other team's AI. And the basic idea is that, you win a real-time strategy game, your AI wins, but there's no human actually playing it at a given time. But, of course, there are humans writing the AI, so if you think of the entire class as a game, then there are players, there are people.
I suddenly see people make a case that there are games that are zero player, and I've heard, for example, there's a game out there called Novick, which is largely a game about coming up with rules. And there is a system, which are actually in the rules themselves, about how you change rules. And, of course, those rules themselves can be changed. And that changes the way how you change rules and, by the time you actually play the game, someone's already won. Because somebody in the game has no legal moves. That's the whole game, is basically making it impossible for someone else, or someone else except for you, to win.
So does that game actually have players? Well, yes, it does because you guys are arguing over all the rule changes through the rules of the game. But, in a sense, it had no players because the game never actually got played. The rules are basically stating, this is an unplayable game for everybody except for one person who's playing the game.
Goals are one of those things that I used to be very, very adamant about. Like a game had to have a goal. You have to know what they're going towards, and if you don't have that, then it's a toy or something, it's a dollhouse, it's an experiment. The Sims was the one that I was like railing about when I was an undergraduate. You know-- that's not a game. And, of course, I was working with many colleagues and eventually came across, came over to decide that it doesn't matter whether I think it is a game or not. If it's in the game shelf of Best Buy, it's a game. Because people think it's a game, and if enough people think it's a game, then it might as well be a game. Otherwise-- because that's what people think it's going to be.
So when you come up with your game, I would say that goals are one of those things that helps steer player behavior. So it's one of those tools that you have as a designer to basically say, this is important, this is not. Reaching the end of 100 meters is important for a sprinter. That end is really not interesting for somebody who is running 400 meters or a 50 meter dash. But that gives someone a direction for them to go towards. But there are plenty of games where you have to invent your own goals. Other than Sims, can anyone think of any? Where inventing your own goals is kind of the fun.
AUDIENCE: A lot of NLRPGs.
PROFESSOR: A lot of NLRPGs. They have goals. They have quests. But that's not where a lot of fun is, necessarily.
AUDIENCE: Second Life.
PROFESSOR: Second Life. A lot of virtual worlds.
AUDIENCE: A game like EVE?
PROFESSOR: EVE? Yeah. EVE, you kind of, want to, like you have to set your own goals, because whatever is in the game is only good enough for a single player-- to tell whether a single player whether they're doing well or not. But EVE is not about a single player. EVE is about thousands and thousands of people playing simultaneously. Actually, have people heard of EVE?
All right. Yeah. So, cool. Cool.
AUDIENCE: [INAUDIBLE].
PROFESSOR: Oh, cool. In Iceland?
AUDIENCE: Yeah.
PROFESSOR: Was it like really cheap when you went over there?
AUDIENCE: Yes.
PROFESSOR: Could you have bought the entire studio?
AUDIENCE: No. Unfortunately. But it was really cheap.
PROFESSOR: So they must have been making tons of money over there.
AUDIENCE: Yeah, they're making money in US Dollars and the Euro.
[INTERPOSING VOICES]
PROFESSOR: They probably hire most, yeah, support most of the economy.
[INTERPOSING VOICES]
PROFESSOR: Yeah.
[INTERPOSING VOICES]
AUDIENCE: The capitol is 20,000 people so...
PROFESSOR: So I'll say goals are very important tools and as a result of that you see them in a lot of the games. And for most of the games that you guys are going to be building, you're going to give a very clear goal of this what you want to do-- earn a certain amount of money, prevent your opponent from doing anything else, take over all the land. That sort of thing.
Let's see. Oh, I'll get to the rules last. But, system. Systems are-- I might already have mentioned this in the last class, but games are systems in a way that most MIT engineers would think of systems. They're a bunch of interconnected little modules, all of them with sort of predictable behavior, and then you put them into a big interconnected system, and it is no longer really all that predictable anymore. At least that's the kind of games that we're interested in in this class.
There's also the game-theory games, where the whole point of it is trying to predict what could possibly happen. And those are great thought experiments and there's some really, really interesting math behind all them and some interesting rules of thumb that can come out. But for the most part, we aren't going to go into too much detail about that, largely because I'm not a mathematician or economist, so I don't really have a good sense of game theory. Just be aware that there is this whole field of game theory in economics.
If you're doing a game like an auction system, if you're doing a game where people are doing either a lot of simultaneous moves or the whole point of the game is trying to predict what strategy your opponent's going to do, you might actually want to read up a little bit on game theory, if nothing else, just to give you some vocabulary to talk about it with your teammates, and some tools to be able to think through some of the design problems that you've got. And we do have one session where I'll introduce some of that.
Finally, we are getting to rules. The things that give your game structure and the constraints of the things you can't do. You can't move from here to there without having your foot tied to another player, that sort of constraint. Or a rule being you can't see anything during a certain part of the game.
There are two bits of terminology introduced by Brenda and Ian Schreiber in their book, which is in Core Mechanic and Core Dynamic. So before I'm going to go into the core mechanic and core dynamic, I'm going to talk about mechanic and dynamic.
Anyone want to throw out the definition of mechanic?
AUDIENCE: I reckon it's sort of the actions like a player takes during a game like the physical actions he takes.
PROFESSOR: OK. The actions that a player decides to take?
AUDIENCE: Decides to take, yeah.
PROFESSOR: Sorry if this is a little low, I saw Patrick and-- or did those hands just go down? I thought I saw a few more hands.
AUDIENCE: Actions that are sort of designed by the game designer. So it's intended actions.
PROFESSOR: Design is definitely a good point. A game mechanic is definitely something that you as a game designer control. There are-- if a player decides to do something in the game that you did not explicitly think about, and you did not explicitly say, all right this is what players are going to be doing in a game, then it might not actually be a mechanic. It might be something that you're discovering in your play testing that you will turn into a mechanic. But because it's not designed, it's kind of-- it becomes more like a strategy, actually, like an emergent strategy.
Sorry. You were saying, Jeremy?
AUDIENCE: Is it more like a dynamic ?
PROFESSOR: Possibly. There are times where it is. Yeah. Actually let's throw out definitions of dynamic, what do people-- well, Jeremy?
AUDIENCE: It's behavior that emerges from mechanics?
PROFESSOR: It's emergent behavior? What else?
AUDIENCE: Use of mechanics that isn't directly stated in the rules of the game.
PROFESSOR: OK. So unstated. I'm running out of space here. I thought I saw a hand on this side. No? OK.
All right. So, yeah, dynamics are basically interactions of mechanics. It's like you don't have anything that may necessarily explicitly say, because of this one rule and because of this other rule, and because of the things that the players can do in that, a good strategy is to do something else. So let me see whether I can think of an example. Right now, everything that's coming to my head is StarCraft.
AUDIENCE: Has that been the case for the last few weeks?
PROFESSOR: Unfortunately, yes. By the way, if anybody is playing StarCraft, I need testers.
AUDIENCE: StarCraft II or StarCraft I?
PROFESSOR: Two.
AUDIENCE: Ah, yes.
PROFESSOR: I need testers for a math game I'm designing.
AUDIENCE: I play Zerg.
[INTERPOSING VOICES]
PROFESSOR: OK.
AUDIENCE: So there's this role selection mechanic where everybody picks the thing which they want to happen during their turn.
[INTERPOSING VOICES]
AUDIENCE: and mostly everybody chooses to build a particular cross. And the dynamic that emerges from the sequence of play, which goes clockwise is that it's best to optimize your strategy so that you were doing, so you were benefiting from the role of the person to your right, is likely to choose. But you're making the [UNINTELLIGIBLE] of the person you elect is most likely win a ship. So mechanically it's role selection and turn order and then the dynamic is the strategy written by the program.
PROFESSOR: Which gives you some idea what to select as opposed-- the mechanic is you can select. The dynamic is, here are a couple of strategies that you can use in sort of assessing what would best to select. And if all the players start to understand that, then it almost becomes like a second layer of rules almost.
If anyone has played a game like Bridge, for instance, there's actually a ton of things that are assumed in the play which are not actually in the rules of Bridge when it comes to bidding. Like when you call out a bid, it's highly dependent on what you actually have in your card hand. And that's not actually written in the rules anywhere. But the assumption is that there is optimal way to do it. And since there's optimal way to do it, everyone's expected to know those optimal ways.
The example in the book was chess moves, like every single piece of chess has a set of moves that it can perform, right? Pawns go one or two squares, depending where they're starting. The bishops move diagonally. But there are also opening gambits. Opening gambits that are also well known, at least among professional chess players, and the idea being, oh, this person is using this opening, therefore, if I counter it with this response, I actually have a reasonable chance of actually winning this game, and professional chess players know this.
The other thing that comes up in chess, which is not in the book, is there is the concept of threatened squares. If you move, if there is a square where there is no piece on a chess board-- everyone here knows the rules of chess, more or less? So say you've got a bishop-- and this is quite a simple chess board-- and you've got the bishop, and it can move like that, right? So every single square on these lines is threatened. It's something which the bishop could move to. Unless, of course, it's lost by a pawn or something, then these are not going to be threatened by the pawns.
If your knight obviously is no longer straight lines, it becomes a specific or sort of like stochastic pattern of squares that become threatened. But the idea of here's this square now that nobody dares move into until something's done about that bishop. Either something gets moved in its way, or something takes out the bishop or forces the bishop to move by threatening it instead in a way that it cannot respond. So threatened squares is not a rule in chess, but it greatly shapes your decision making and that's the difference between dynamic and mechanic.
There's a lot of strong correspondence between mechanics and rules. But-- and I had a long, long little rant about exactly what the difference is between mechanics and rules. And what I basically-- I know I'm going to get the rant right now, but it's like overlapping venn diagram. There's a very, very large area where it's exactly the same thing. My general rubric for trying to figure out whether something is a mechanic or not is whether this is the thing that changes the state of the game. It is an action. It is something that someone is going to be doing to change the state of what the game is. In chess, that's largely the movement of the piece. If it's ultimate. It could be just physical movement. You are limited on when you can physically move. If you have that frisbee, you're not moving. Well, your feet are not moving. I believe that's a rule of Ultimate.
So the reason why I use that definition is because there are occasionally times when I need to talk about mechanics that players aren't actually doing. The game requires certain pieces to move in a certain way, certain things to happen in the game in such and such a time. For instance, you have these die rolls and-- actually, that's not a good example. Let me think.
Right at the beginning of Settlers of Catan there is the way how you set up the board, and that establishes what a game state is going to be. It changes game state by giving you a game state in the first place. I consider that a mechanic. That is something that's going-- that's not one rule. That's actually a whole collection of rules. And if you're interested in finding out what those rules are, the box is actually in that closet over there.
There are something like five or six different rules on how you set up your board. It's going to be, set up your game state, and I consider that a mechanic. How people do bidding and buying things in Settlers of Catan? That's dynamic. There are no real rules on how much something costs. That's up to the players to work out on your own.
So that's how I sort of consider the difference between dynamic and mechanic. They're really, really useful concepts because really, for the most part, as a designer you have an idea of what kind of dynamics are interesting. And the more games that you play, the more inspiration you get from various sources, your range of different ideas of what kind of dynamics might be interesting is going to expand.
But all you have control on are mechanics, the specific rules that you're giving, note that game mechanics don't necessarily need to be written or described out. This is one thing that I think you and your teammates should figure out when you're talking about mechanics for a given project. Are we just talking about the things we are writing down? Because there are some assumptions that are just given. We are playing a game, and we're not playing some sort of schoolyard game or something, hitting people with solid objects that's disallowed. Not necessarily something you need to write down. Unless you're playing with certain people. You can assume that the game again -- things like how fast people normally do things.
There's a game over here called Falling, which is actually a real-time card game. It goes as fast you can possibly play it, and there is no there is no limit on how fast you can play these cards. But there is a real physical limit on how fast you could physically grab the card out of your hand and put it down. So, actually, it's not even on your hand, your just moving cards on table. So make sure you give that a try today.
Finally, we'll be getting to aesthetics, I think-- next class?
[INTERPOSING VOICES]
PROFESSOR: So, which is another thing which a game designer-- in fact, what I would like game designers to actually spend more time thinking about, which is, what is the feeling you want your player to have? As opposed to, this might be fun, or this might be engaging. And specifically, how is it fun? And how is it engaging? Is it fun as in like, yes, victory! I have crushed all my opponents. Or is it fun as if, well, we had a really good time together and we got to know each other really well. There are games that are designed for both of those.
And what is the aesthetic you're going for? Are you going for something poetic? Are you going for something fiercely competitive? Tournament competitive? Are you going for just a nice little social experiment?
Core mechanics and core dynamics are a tool, again, for designers. The idea of-- there really isn't a huge difference between what's a core mechanic and what's just a mechanic, except inside a designer or design team's discussion. The idea of having a core mechanic is you identify this is what our game's about. Or a core dynamic means this is what our game's about. And a lot of core mechanics in first person shooters is pointing and shooting. I'm going to point at something and I'm going to launch a projectile that way, and that projectile is going to move in some physical properties. Maybe it arcs, maybe it goes straight.
I would say that the core mechanic of Halo isn't actually that. Who has not played Halo or seen someone play Halo? OK. So the idea, core mechanic-- or I think my Bungie calls it the core game play loop-- of Halo is, you shoot at something, you take cover, you throw a grenade at it, you wait for the grenade to go off, and then you shoot at it again until it dies. That's pretty much all you are doing for the entirety of Halo 1.
I'm sure Halo 2, Halo 3 gets complicated, but de-identify that as you actually read the post-mortems and if you read the talks that are given, they say those-- I can't remember if it was 20 seconds or five seconds of game play which is used to describe that. I think that five seconds of game play is what they focused on. And if they could get every little thing in that sequence correct, they can repeat that same thing at infinitum, and you'll still will be having fun. Halo 1, everyone.
They're kinda right. But the idea being, if you've got a core mechanic, and you've got one thing in your game that someone's going to be doing over and over and over again, all your players are going to be doing over and over again-- maybe it's bidding because it may be some kind of auction game. In Falling and Pit, it's transferring cards to other people. I'm trying to think of the other games that we got here. In SISSYFIGHT, I would imagine the main core mechanic would be putting down the card and everyone revealing the cards simultaneously, because of you all take simultaneous turns. Make sure that's really, really fun.
And Yahtzee is rolling dice. That action, that thing that you're going to be doing over and over again, has to be at least fairly engaging. Because if you can't get that right, then what happens is that that same movement, that happens 30 to 50 times in your game, just-- the badness just gets multiplied by 30 or 50. And you don't want that. So for core mechanics, I would say the thing that happens in your game the most-- and you want to make sure that that part is as engaging as possible because it gives you a rubric to say, what's not a core mechanic might be, in fact, expendable. You might not actually need it in your game. So if you've got a problem-- this game takes too long to play, this game's too hard to learn, this game's over too fast, it's too random or something-- take a look at all the things that are-- but first make sure that your core mechanics not the cause of the problem.
But if the core mechanics doesn't seem to be causing the problem, that seems to be working, something else in the game is not working. Everything else expendable. And so you can look at everything else in the game, all these other rules that you've got, and say, how does that work with a core mechanic? How does that help? How does that hurt the core mechanic? It just helps your discussion as a team. Or as an individual game designer, it helps you to think about what could we throw out? What could we keep?
Similarly for core dynamic. It's like here's this particular interaction that we really, really want. And SISSYFIGHT is guessing what other people are going to do. I'm trying to think of other examples. And like territorial space acquisition. I guess Go is about taking over territory in space. If that's your core dynamic, you say that's kind of fun, just making sure that I'm in control of space and nobody else can do anything they want to do in a certain part of the board. That's fun. That's what I'm going for; that's my core dynamic. That's what this game is all about.
Then you can look at every single mechanic, even your core mechanics, and say, is it all serving that goal? Now there's a whole bunch of tips right at the end of chapter one of Challenges for Game Designers about how to break designer's block.
But I would say, actually, those things are just things you should be doing all the time, not just when you have a problem. But you should be experimenting. Things like, OK, you've got a variable. Draw two cards every turn or something. Multiply it by two. See what it does to your game. Halve it. Draw one card. See what it does to your game. Through a rule-out, and that sort of gets you to the whole iterative design thing, is that you don't actually, because games are systems, these complex little collections of seemingly simple things, you don't actually know how these changes are really going to affect the game. You may have a hunch, but until you actually play it out, you don't actually know.
So the whole point of iterative design in engineering as well as in game design is that you make the change. It has to be a substantial change. And then you actually put it to the test and see what happens. This means, of course, testing, and testing takes a long time and if you're going to be making a game that takes a long time, then your testing gets even longer.
So for the first project that's going to be coming up, assignment one, you want to be aiming for games that take really not very long to play. These games that we got today, I'm not sure about [INAUDIBLE], but I know everything else that we got on that table, is pretty darn fast. Which means if you play an hour with four people who've never played your game before, you get through two or three rounds, four rounds, of them. Each time, you'll be teaching a rule once, sharing and seeing how that changed the game.
If you've got a game that takes an hour to play, and believe me, a lot of the projects that we've gotten from previous semesters take at least an hour to play. You've got four people for an hour and another definition of a single-player game. Because by the time they finish learning your game , half your time's up.
So that's a process that we will like you all to be using in your teams and your assignments, is iterative design process. Right from the beginning-- I wish I had more space-- but we're going to start with brainstorming. That's actually going to be Friday, the 17th, where we'll actually sort of-- for folks who haven't necessarily formally learned brainstorming we're just going to do a quick refresher so that everyone sort of is on the same page.
You learn how to do brainstorming. You come up with a basic idea of a game, and you start to identify things that could be your core dynamics. You think of what sort of core mechanics could address that. Knock something up really, really quickly with the crappiest materials you can get your hands on and start playing.
Since nobody on your team knows, really, what game you're making at that point of time, you can probably test it with your team. As soon as you do it a few times, your team becomes useless as testers because you already know too much about the game and what the game could have been. And you start playing it in ways that a fresh person, who's never seen your game before, wouldn't even consider.
So you actually want to keep looking for people who've never played your game before. So the next step would be to broaden it to other teams in this class. Because everyone's going to be broken up in more or less teams of three or four. That's pretty much, I'm going to take this game that we designed for a team of three or four, and give it to that team of three or four. And then you play their game, and give each other feedback. And that lasts for about one more session, and after that, everyone in the class is useless now.
So you have to look for dormmates, friends, people on the street, just go right ahead and try to get as much feedback as you can. There is some value in replaying, especially later on once your rules are pretty set in that people start developing strategies, still some of them emergent behaviors, things to understanding sort of higher level play of the game, and you do want to test that. But don't let that prevent you from also testing with fresh players. Because in the end, you have to get past that initial hurdle. Anytime someone sees your game, they are going to have to learn your game from scratch at least once. And if they don't even get that far, they're never playing your game a second or third time. So don't optimize for the people who play your game for four weeks, because you really want the people who've only played it once to have a good time as well.
That's not necessarily the case if you're making a huge, well-funded game based on a franchise that's been around forever. If you're doing Halo 3 or Modern Warfare 3 or something like that, then sure you can sort of cater to the fans who've already developed these strategies and skills. But in our case, we're going after a new audience. We're going after someone who's never played anything like what you've played with before.
Cool. Any questions? Feel like we've been soapboxing here for a while. Is there anything?
AUDIENCE: I guess the thing I would add from my experience, especially with iterative design is, a big trick of it is learning to kind of distance yourself emotionally from what you're working on, because half the time you end up chucking things that you really liked. You think, oh, this would be so great, but it's best to just remove it. And it helps to think of it as kind of putting it on the shelf for later, and saying, OK, I'll deal with this later, or I can try this in another game.
And on a related note, I don't know about you, but I found that, when games I'm designing have a problem, it's almost always fixed by removing something as opposed to adding more stuff on it. Unless you're going for something, I think, really complex off to start, I always prefer to try to take something out and simplify it. Especially on short projects like these it almost always works better.
And then, in terms of testing, too, one thing just kind of a tip that I find works, is if you're designing a game that has a lot of different, like, passive victory and this is a little bit higher level, which you'll see when we get there, where if you want a game that has different viable strategies, a really good testing method is to have different people kind of play like a perfect version of that strategy. And you say, I'm going to do this strategy, or I'm always going to do X, and it doesn't matter if I think it's dumb, I'm just going to do it. Because that will really help you find rules that are appropriate, or find something that's overpowered.
AUDIENCE: A good example would be Settlers right. Like if you say, obviously this wouldn't work because, the game's a good game, but like, I'm always going to build roads. You know what I mean? In practice, that would be stupid,but when you're designing a game, you do that kind of strategy, and you just limit yourself to one action, you can really find things that are broken really quickly.
PROFESSOR: Thank you. Much appreciated. Cookies. Good, we have cookies.
Let's see. So I think after this, we're just going to play games.
We do have pre-testing as a topic coming up later in the semester, where I will actually sort of talk about the discipline on how do you do testing. Honestly, you shouldn't wait for that class to necessarily start practicing. It could be as simple as just grabbing a unit that you have never seen before and just trying to get a whole bunch of people to play it. And critiquing it at the same time. It's like, why did I do that? Why did you do that? Why did you do that move?
And there are sort of practices to make sure that when it's your game, you are not sort of telling the players what they should be doing while they are trying to play the game, because that affects their play of the game in a way that biases it. Well, we'll get to that later in the semester. For now just be aware, the more that you're testing, the more you're sort of tweaking your rules in between tests and then getting another chance to test and test and test, the closer you are to getting a game that is actually fun and engaging to play. And that's what we're looking for. That's the process that we expect you folks to suceed in.
When do we ever get to fun and engaging? Who knows? We don't know whether you're going to get there, so we're not grading you based on that. Just remember that. We're not grading you on how engaging your games are. But how well do you stick to the process? Yes. Absolutely.
There was a question in the forums about when do you stop? I didn't get a chance to look too closely at it. What--can you repeat it?
AUDIENCE: It's essentially, it's the question of, say, there is this iterative design process. When do you know when to just sort of get out of that process? But--
AUDIENCE: Due date.
AUDIENCE: Due date. OK. That's always a good reason. I guess, if you didn't have a due date, like how would you know when to shift? Well, let's say you have control over the due date. I guess part of that is, you should always be updating, blah blah, so I guess the question is when do you know when you have something you can put out into the world?
PROFESSOR: So the cynical answer is that, yeah, is that you wait for -- you have to ship, right, or you're not getting any cash. I personally think it would be sooner than you think. As, like, my game's almost ready but I know there's something wrong with it, especially when you're a student. Right now, I'm in this mode with my StarCraft games, which is, this path is cracked. I know there's something wrong with it. I have no idea what it is. Therefore, I'm going to release it. Because until I do that, I have no idea what's wrong with it. I need to get that information.
The nice thing about stuff like computer games is that you can ship updates. It's annoying but you can. But even board games and card games now have rule revisions, rule clarifications that you can release over the net. For the most part, if you're going to go professional, your publisher will tell you. And then the answer really is due date. It's going to the presses on this date. And that's one maxim, which is, game projects are never finished. They're just abandoned. It's just horrible. I can't do anything else about this because I'm out of time. Ship it.
But one thing that you can do to prepare for that-- Let me see. Is there a laser around here? There is a guy who runs a blog called Lost Garden. His name is Dan Cook. He works over in Microsoft. And he talks a lot about game design. Specifically about video game design, but actually his stuff is actually really, really impeccable. And he has this concept that game design-- or iterative game design kind of goes in this kind of cycle, where this list down here is the number of features you've got in the game.
The trick, though, is that what you're really doing is, you are taking-- let me see if this is right. So this is all the good stuff. This is all the stuff that's not so good. And the whole idea of sort of like using iterative design is to allow yourself to the space to come up with a whole bunch of ideas, not knowing whether they're good or bad. But it also gives you a gate to cut out all the bad stuff.
So at frequent periodic intervals, you have a collection of rules, of cards, of designs, of whatever consists your game, that, is pretty much as good as it possibly could have been given the amount of time that you got. And that could ship. So if ship date was here, you had as good a game as you possibly could do it. If ship date turned out to be there, all of a sudden you've still had the opportunity to put out all of the stuff that you knew was bad. So iterative design is not about, let's just keep accreting more and more and more and more features. It's more about, we're going to add some features and then we're going to remove the ones that don't work. And that's really, really important. So at any given time, you are prepared to sort of release it. As for when you actually decide that this is now ready to go out, again I will repeat, sooner day than you think because you need that feedback.
Sometimes you don't know how a market is going to respond until you actually do it, but you can do a soft launch. If you are doing a commercial product, you can do things where, we're going to release it to a few select stores and get that feedback before we go into major print run. Or for 10,000 different copies of the same board game. We're going to 200 copies and see how that does for us. Gives you the opportunity to make a revision, but it's still an official release, because those 200 people think that this is the final packaged product.
That's pretty much how a lot of manufacturing industries actually work, anyway, so you think about any kind of product design, a lot of them have a sort of a trial period.
AUDIENCE: Soft drinks you get a lot.
PROFESSOR: Soft drinks you get a lot. Japanese electronics, and other things. You release it in Tokyo, and then you release it in the rest of Japan. And sometimes it never makes it out of Japan because that initial test-- yeah, it was a good product but not enough people bought it because of these problems. So instead of releasing it into the world, we're going to make version two, and maybe that will be one we release to the world. That's one example.
All right, so we have games. Who has not played Uno? OK, we have more games that--
[INTERPOSING VOICES]
[LAUGHTER] OK. So Jason, you're going to do a Euchre table? So--
AUDIENCE: It sounds like 4 player trick taking game, kind of like bane or current speeds or which?
PROFESSOR: Looks like we have exactly four people-- one, two, three, four, one, two, three-- it's an average of three people per table.
I think most of these games are three to five player, although I'm going to be absolutely sure.
[INTERPOSING VOICES]
PROFESSOR: --so it might
[INTERPOSING VOICES]
PROFESSOR: You guys might actually want to try the round table in the corner?
AUDIENCE: Yeah, it's a [UNINTELLIGIBLE]
AUDIENCE: I really want to play bowling.
[INTERPOSING VOICES]
PROFESSOR: So basically, take a game from the table. I'll bring some out and I'll see --play them. Once you've had a chance to play a few times, feel free to switch. And try to get as many games played as possible during the next couple of hours.