Iterative game design

Understanding core elements of play design: actions, goals, rules, objects, playspace, and players. Design accessible and creative games across genres, platforms, and development realities About This Book Implement the ….

Capturing a wealth of experience about the design of object-oriented software, four top-notch designers present a …. Skip to main content. The CPU utilizes moves as they are learned, allowing iterative game move development.

This is known as Artificial Intelligence AI. By: Brad Rudisail Contributor. By: Kaushik Pal Contributor. By: Leah Zitter Contributor. Dictionary Dictionary Term of the Day. Techopedia Terms. Study: Develop statistical tools for analyzing the success or failure of the design. Act: Repeat the cycle if the results of the study find problems with the design solution.

Around the same time, the industrial and theatrical designer Henry Dreyfuss began to approach product design from a similar perspective. His goal was simple but unexpected: understand the experiences his designs provided, and refine the design to better meet the functional needs of the end user. Think: Consider the cause of the problem, and then use brainstorming techniques to consider solutions.

Sketch: Develop the most simple and efficient means of exploring the most promising solutions. Show: Share the sketches, whatever form they may take, with stakeholders clients, potential users, and so on.

Evaluate: Reflect on the responses from the designers, clients, and users to determine the effectiveness of the solution and to more fully understand the problem. Where Shewhart relied on hard data to improve product consistency, Dreyfuss used the then-emerging fields of ergonomics and human factors to consider the functional, experiential, and emotional responses to his products.

A more recent influence on the iterative game design process comes from software development and Human-Computer Interaction HCI. Both of these use approaches derived from Shewhart and Dreyfuss:. Requirements: What is the function of the software or hardware?

Prototype: Based on the requirements, create a functional prototype. Review: Have all stakeholders use the prototype and provide feedback. Revise: Based on the feedback, revise the requirements and plan. It is from these three foundations that the iterative game design process emerges. While some people approach game design from a perspective of metrics and statistics, most gamemakers take a more intuitive approach.

And while some use a more traditional predictive process, most embrace the adaptive methods of iteration that allow game designers to design and refine the game through successive iterative loops. This is because, unlike phone infrastructure, typewriters, and ATM machines, games are experiences and expressions more than tools or functional products. Games are about the play-driven moment-to-moment events, while typewriters and ATMs are a means to an end.

Game designers are therefore addressing a mix of gamemaker intention and player experience. As a result, the four-step iterative game design process see Figure 5. Conceptualize : Develop an idea for the game and its play experience. Playtest : Have players play the prototype to see what kind of experience they have.

This is how the iterative game design process works: a series of steps toward the complete design of a game. Each loop through the cycle is an iteration on the design of a game: an incremental step toward better understanding the game being made so that the designer can work out the full design of the play experience.

And it could come from anywhere. Maybe it starts with an idea for a cool action or an unusual use of a common game object. Maybe it starts with the need to explore or share a feeling that is difficult to put into words. In other words, a game concept can start from anything.

The conceptualization of a game begins with a number of different techniques to generate and shape ideas at the beginning of the game design process and continue to support the design through successive iterative loops.

But at the start of the game design process, all that is needed is this one question. Once a basic question is in place, the next step is brainstorming. 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 meters is important for a sprinter. That end is really not interesting for somebody who is running 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. They have goals.

They have quests. But that's not where a lot of fun is, necessarily. A lot of virtual worlds. 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. So, cool. In Iceland? But it was really cheap. 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. 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? The actions that a player decides to take? I thought I saw a few more hands. So it's intended actions. 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. You were saying, Jeremy? There are times where it is. Actually let's throw out definitions of dynamic, what do people-- well, Jeremy?

What else? So unstated. I'm running out of space here. I thought I saw a hand on this side. 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. By the way, if anybody is playing StarCraft, I need testers. 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.

So mechanically it's role selection and turn order and then the dynamic is the strategy written by the program. 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.