> [!cite]- Metadata > 2025-07-09 21:45 > Status: #secondary #course > Tags: [[Game Design]] `Read Time: 2h 1m 27s` > Collaboration, prototyping, playtesting. The Sims creator Will Wright breaks down his process for designing fames that unleash player creativity. > [!Abstract]- 1. The Fundamentals of Game Design > All of us are set in our own little worldview. We think we see the big picture, but we all see a little slice of the world through our own little lens. I would like to imagine that people have the opportunity to see a much wider set of perspectives on the world and that games might be the mechanism, the vehicle that brings that to them. You can take almost anything and make it a fascinating interactive experience. What I'm really doing is I'm giving the player a toy and the player is turning it into a game. > > Every designer has the opportunity to make something incredibly unique. At the same time, every designer faces the risk of creating something that no one will be able to understand. As a designer, you are actually dealing with two computers. First, the electronic one sitting on the table in front of you. But more importantly, the players imagination, the player's brain. And that one is far more complex. And we have barely scratched the surface of it. > > During the course of this class, I'm going to expose you to a number of fundamental concepts about game design. Basically the psychology of the player, the mental modeling that goes on. How to use game mechanics as part of your toolset, and how to develop your toolset as a designer. How to think about the overall structure of what's going on underneath the hood. How to build emergence, surprise, cool, detailed worlds and to try to predict what's going to motivate players and pull them in. Get them emotionally involved to the point where they get into communities that are built up around these. > > And so there are many different levels of game design. And we're going to start with the fundamentals and work our way outwards towards larger and larger, more strategic levels of thinking around it. > > Every designer is unique in some way. My games have tended to be very specific in terms of real-world simulations, generally, games that tend to encourage player creativity, player storytelling. There are a lot of other approaches to game design, but I think a lot of the fundamentals that I'll be talking about in this class are going to be things that can apply to any genre of game. I think by going down to that fundamental level it's going to give you a lot more opportunities to come up with creative inspiration, to bring in new approaches, new-ideas -- basically, how to amplify your own internal creativity in ways that are coming from a fundamental level rather than just the feature level. > > What are games? You're probably watching this because you have an interest in games. We all know what games are. We play games. More recently with electronic devices, games have taken a totally different kind of turn and gotten much more elaborate, more ubiquitous in our lives. Games really are something that have been around for thousands of years. Different cultures have played games, board games, social games for a long, long time, for a lot of reasons. > > Games really, right now, have different genres. Puzzle games, first person shooter, simulation games, massively multiplayer online, role playing game, strategy, music. These are different subsets of the game space. But games really are a subset of a larger thing called play. Play is just exploring. It's experimenting, it's trying different things, usually in some symbolic representation, some little toy of the real world, with a very low cost for failure. > > In a lot of ways, I think games have been somewhat misaligned. We've associated games with violence. It's something that little kids play. But that's actually been true of any kind of new media. Fine art looked down on books, which looked down on radio, which looked down on film, which looked down on TV, which looked down on games. Games are the up and coming thing, that in some sense, is breaking boundaries, doing new things. and that's what makes games interesting to me, as a topic, as a medium > > Games borrow from so many other different design fields, not just entertainment, storytelling, things like that, but also things like architecture, product design, fine art, mathematics, cognitive psychology. Games incorporate all these different design fields in an interesting way. The more you can expose yourself to these different design fields, the better designer you'll be. > > Take a multi-disciplinary approach. I think game design is one of the most challenging design fields there is. And I think to be a good game designer you first and foremost have to be a good designer. Getting into the idea, the mode of thinking of how does a designer think? How do they learn? Where do they pull inspiration from? Don't close yourself just into the gaming world. Look at all sorts of things all over. > > I've learned so much from weird fields like Japanese gardening, or biology, or economics whatever you know. You can pull all these things in and, as a designer, use these as parts of your creative palette. One of the things I really would inspire try to inspire, up and coming game designers to do is think, how do I continually learn from other people, from myself. > > Just do it. Try it. You can do something as simple as design a little game on a piece of paper. And go show your friend. Let's play this game. Here are the rules. See how that works out. The more you're doing that. Always inventing little games, even if it's with toothpicks on a tabletop, you're going to learn a lot that way. > > You'll be much better off doing continual, ubiquitous, everyday, kind of local game design. > > Explore Branching Paths of Decisions. Any designer, basically, when they're designing something has to look at a number of factors. Basically, you're trying to balance all these things against each other. So think about just a chair and all the different properties you would like from a chair. You want it to be cheap, easy to move, easy to produce, comfortable. > > These functions can be broken down into a tree. So games have pretty much the same property. There's certain functional things about them. There's certain things that are economic about them. What does it take to produce the game? How much does it cost? What kind of a team do I have to build? What kind of skill do I have to have as a designer? The designer needs to understand how to balance all of these things against each other. > > You're basically exploring these branching paths of design decisions, starting with very fundamental design decisions - you know, what kind of game am I making? What's it about? What are the controls? Down to very incremental design decisions. What color is this button? How tall is the character? > > That's why when we build a prototype, we want an answer from that prototype. We want to find out, do we go down path A or B? If the prototype can't answer that, it's basically failed as a prototype. So we're really trying to efficiently prune the branches and continue down the right path toward our final design. Like I said you don't exactly know where you are going to end up on this tree. > > A lot of times, I've seen game designs, or even other designs, where somebody went a little too far. The designer needs to know you've hit the sweet spot. > > Embrace Constraint. One of my design hero's is Charles Eames. Charles and Ray Eames were a design team, husband and wife. He had a great quote which was simply that design is constraint. Design really is how do you work around constraint. Without constraint there is no design. It's just pure imagination. So to be a good designer you kind of have to embrace that constraint. You say, within this constraint, what can I do that's really cool? > > Here's my starting point, and within that constraint I was able to do this. The constraint could be the technology in front of you, how fast the processor, the graphics. The constraint could also be "what does my player know?" "what skills do they have?" "where does their imagination take them?" those are constraints just as well. > > **Design beyond Zero-Sum Games** > > In a competitive game, usually with two players, there's the concept of a zero-sum game. Which is that if the player wins, he gets a positive 1. The losing player gets a negative 1. If they tie they both get 0. Basically the sum of two players is always 0. You can't have two winners or two losers. In a non-zero-sum game you can. Both people can win. The kind of games that I do are not zero sum games at all. > > In fact, most of the things that I do don't even have a clear win state. When you play something like SimCity or The Sims, what actually, I found very interesting was to leave it to the player to define the goal state. When a person sits down to play SimCity I don't tell them they have to build the biggest city, or have the happiest people, or the least crime. Players in their own mind decide that. They think, okay, what is my ideal city? And they design that. > > So the player is actually the one building the rule set and the structure, and the player is the one scoring it. I'm really just kind of giving them an open-ended toy. Then you get a lot of really interesting kinds of play styles, certain players trying to achieve things. Other players don't even really try to achieve anything at all, but just try to use it for creative storytelling or creativity. For them the win state was more social. > > I think games have the opportunity to go way beyond this kind of zero-sum approach. > > **Expand Player Creativity** > > You can take almost any technology that we have and view it as an extension of the human body. For example, television, telescope, our eyes, our vision. Telephone, our speech. Cars really kind of extend our legs. If somebody hits your car you don't say "somebody hit my car" people usually say "somebody hit me while I was driving." > > We now with these little microworlds have the ability to basically externalize what's in our imagination and share it with other people. It used to be that you had to have a very rich skill set. It could be a fine artist to do that, to paint something in your imagination and then share it with people. But now with these tools, the creative leverage they give us, average casual game players have the ability to externalize, create things out of their imagination, share it with other players, and actually have these shared imaginary worlds. > > Basically, we were turning the average player into a Pixar artist. They were able to create a brand-new character out of their imagination and have it come to life. And so I think this is one of the examples of the computer giving creative leverage, a creative amplifier. And a lot of people are using computers for different creative fields, but same thing, it's a creative amplifier for everything they do. > [!Abstract]- 2. Generating Game Concepts > I don't actually start by concepting a new game. I read a lot, I like learning new things, and at some point I'll just trip over a subject or some material that I find particularly fascinating. So it's not like I sit down and say I am going to come up with a new game idea. It's more like, i'm just kind of exploring, browsing the world, then it's like oh, maybe I can make a game out of this. > > **Find Your Palette of Inspiration** > When I went to college I studied all these different things, and I don't want to become an architect, or an engineer, or an artist. By being a game designer I found that I could study whatever I want and my excuse is, I'm making a game about it. So for me, being a game designer turned into a lifelong learning process where I can go off in any subject I want to and it's tax deductible. > > For me, it's usually some kind of interesting thing about the world or in the world that as I dig deeper it gets more interesting, not less. A lot of the games I've done were based on cool subjects, usually books that I read. SimCity was very influenced by the work of a guy named Jay Forrester (Urban Dynamics) who was the first person to actually model cities on the early computers back in the 50s. His models were not spatial they were just like little numbers. How much money did the city have? How much land? How many roads? But he was actually the father of what became known as system dynamics. > > SimAnt was very much inspired by the work of Edward O Wilson, very famous myrmecologist, studies ants. He wrote this great book, won the Pulitzer Prize, called "The Ants" but he in some sense, was reverse engineering the way ants work. Little ants are almost like little robots, and it's pretty simple to figure out in the presence of this pheromone the ant does this, and in the presence of that pheromone the ant does that. > > He actually reverse engineered that and discovered a whole level of emergence. An ant colony, in fact, is incredibly smart. About as smart as a dog. An individual ant is incredibly stupid. So ant colonies are really one of the few forms of intelligence that we can deconstruct and understand at that level and he was the guy who did it. > > These kind of subjects are things that when you read about them, they're kind of dry and boring, they're filled with technical jargon and what I always aspired to do was to take these things and make them approachable -- turn them into a toy. How can I turn an ant colony into a toy? In a way that people come in and start interacting with it? When players are actually manipulating these things and building them, they take ownership. They get so involved, so much more emotionally connected to these and then the subject becomes utterly fascinating. > > As soon as I built the very first prototypes of SimCity and I was running a little simulation, it was very coarse, very crude -- but still, my interest in urban planning skyrocketed. All the sudden, oh this is really cool, I want to find out about traffic modeling. I want to find out about this, that, and the other. These things that would have sounded incredibly boring to me, when I had a little Guinea pig in my room to play with it became fascinating. > > Likewise, other games I did, The Sims, was very much influenced by Christopher Alexander's work in architecture. So for me personally, I find a lot of inspiration in books, also in fields I think that are interdisciplinary, things that are almost controversial. > > SimEarth was very much inspired by James Lovelock's Gaia hypothesis. It's about the earth and the way it regulates itself. And usually that's where the areas of science are moving the fastest and the most interesting. And those are the things I tended to gravitate toward. This is me personally as a designer. I think every designer is going to find their own kind of palette of inspiration, their own direction, their own kind of voice. > > **Research Without Limitations** > > When I was starting out in game design, there wasn't this thing around called the internet. I actually had to go to this place they used to call libraries where they had these things called books. I would read these books and learn about things in that way. Designers now have so much less friction to do research around an idea. For me it's almost magical that I can kind of pick any topic and go down any little weird path and find material about it. > > On the simulation side, it was really interesting to me to kind of go back into the history of simulation. Back into the 60s and 50s and even all the way back to Von Neumann and Turing and see what they were trying to do with these super primitive computers, and some of the things they were trying to do were amazing, way, way beyond anything a computer could do. But they would imagine that one day a computer could do this. Right now my watch has much more power than they ever envisioned. At least as a designer I don't feel like there are any meaningful limitations beyond my own imagination. So I think to me, that's really the thing that I have to kind of flex and exercise and push. My own imagination. > > If I can do that, it's actually pretty straightforward and easy for me to figure out the research, the technology, to do it. It feels to me that so many designers think about and even communicate their game idea relative to other games. It's going to be World of Warcraft on the moon. It's going to be whatever. You can take almost anything, and looking at it the right way, make it a fascinating, interactive experience. > > **Researching the Sims** > > With the Sims, it wasn't really apparent what I should be researching. But as I started digging into the game design we started getting into this thing with the Sims motives, and they had to go to work and all this stuff. It became pretty apparent that this was really kind of a game about time management, in some sense, on their side. How do you manage their time to maximize their motives to make them happy? > > After quite a bit of digging I came across the work of a guy named James Robinson, and he did all these time studies of Americans, how they spent their time. He actually kept logs everyday. They spent 20 minutes of time doing their stuff in the morning to get ready. This amount of time with their kids. This amount of time in front of the TV. And he actually broke it down. It ended up that we were actually matching those numbers fairly closely. We matched these numbers with the percentage of time people spend doing each of these activities in The Sims. That wasn't something that was apparent the we could even research. > > Another area of research, a guy was interviewing people about what their most prized possessions were at different ages. It was actually quite interesting stuff, some of which kind of made it into the game. It turned out that for kids and really old people their most prized possession was their bed, and TV was second. In Mid-life it was like their car, their house, all these other things. It was interesting that the kids list of their top possessions was almost the same as an elderly persons. > > As a designer if you can understand and absorb all this stuff, it helps you think about directions you might take it or you could take it. Even if you don't end up using it. > > **Zero In On Your Concept** > > Even when I am kind of initially imagining, okay I'm making a game about this thing, I don't start by thinking what's the game going to be. Or what it's going to be like, I just dive deeper and deeper into the subject and the research. And then I start trying to kind of look at the components -- what are the different aspects of this that are interesting to me? It might be the process, it might be the structure, it might be the science behind it, whatever, historical context. > > From those things I start imagining how would I really like to view this or manipulate it or play with it or create it. If this is a piece of clay, how do I want to sculpt it, what are my tools? I start just imagining 10 or 20 different perspectives on that subject. I think the perspectives are far more valuable than particular solutions or approaches. Two or three will usually start to get traction in my head, and i'll start exploring those a bit further. I'm trying to describe something that in my head is a much more abstract process. In some sense I'm circling the idea and slowly moving in on it, not diving right at it. This research process may take a year before I think what kind of game it might be. > > During that time I'll even build models of it. Or draw pictures of it or try to recreate it in different forms. Tangibly. That again just kind of puts my brain in a little bit of a different spin, and new ideas will pop up. > > **Spore Inspiration** > > The original concept was based on a couple of things. I did a box deisgn and I actually called it Sim Everything. There were two things that fascinated me especially. Number one wa an old film, Charles and Ray Eames "Powers of Ten". Every ten seconds bigger and bigger and bigger. I love the idea of scale across the universe. Within that dimension of scale at every single scale that we know of is light. Everything else is fairly deterministic. Fairly predictable. Dry. But life is the one unpredictable aspect in every single scale starting at the cellular level. > > The other big inspiration was basically astrobiology - the idea of how prevalent is life out the galaxy. What forms might it take? So those two ideas came together and I was really thinking about, can I tell a story about the journey of life from the cellular level up to galactic expansion? How would I make that game-like, a kind of toy. > > **Trust Your Instincts** > > As a designer I tend to go with my gut feel in terms of "that's going to be something cool", and I can't always express exactly on what dimensions it's going to be cool, but I hope that my instincts will bring me to a place where a wide range of people will enjoy it. I wasn't always that way. It kind of took me a while to realize that. > > When I was first kind of working on Sim City by myself, I showed it to a few people and they showed it to a few people and they thought it was kind of cool. I showed it to my eventual partner, Jeff Braun, and he was like Oh Yes we have to do this, let's start a company. And we started Maxim and did SimCity. But in my mind, even at that point, I was thinking, okay this is a game that maybe a few strategy gamers or architects maybe might enjoy. It didn't occur to me that a wide range of people would enjoy that. To Jeff it did. He kind of understoof that I think more than I did. > > After that, I started learning to trust my instincts, that if I really find this cool for some reason or i'm gravitating toward that, just trust that we can find a way to bring other people and they'll enjoy it as well. It's very hard, as a designer, for me to design for somebody else. You know, this is how that person thinks, this is what they want, this is what they believe. It's easy to do for myself then figure out why am I enjoying this, why am I motivated? What about other people's though process will let them see this and enjoy it and experience it the same way I do? > [!Abstract]- 3. Early Prototyping > Once I have an idea for a game I start making prototypes as soon as I can. The early prototyping is probably the most important stage. We're trying to imagine different types of rules that might be applied to the system that we're basing the game on. You're basically trying everything you can think of for how to turn this concept into a game. Whatever it takes for you to cheaply get a sense of that's fun, that's not fun. > > **Answer Specific Questions** > > Well a prototype is usually interactive, not always, but usually. And we're taking some little bit or part of the game that we have a question about. Should we go this way or that way? It might be an interaction question. Is it better to have controls work like this or like that? It might be a visualization or graphics question. This point of view or that point of view? Should it be this style, that style? But it's something we feel like we can't answer unless we actually touch. Play with, interact with a little bit. > > Even if it's just turning the world around, looking at different camera angler and that's when we decide, OK, we're going to build a prototype and we're going to build the simplest possible thing we can that will help us answer that question. As I'm playing with this one little piece in hand and imagining the rest of the experience. Can we answer that question? Oh yeah, this would be much better top down. This would be much better 3D. This would be much better with that kind of player control. > > But you know, it really needs to be answering a question as cheaply as possible. You don't want to go spend weeks and weeks building this. You want to build the cheapest, simplest little thing that you can build that you can sit back and say, OK, I'm pretty confident now that we go this way. As we get further down the path, it's, you know, can somebody learn how to use this interface? We can find out what the failure states are, how we need to change it to make it work better. > > And even further down the road, it's how engaging is this to players? That's a much more open-ended question and a much broader range of answers. For certain people that's very motivating. Most people, it isn't. Or it's somewhat motivating for a lot of people, but if we did this, it would be much more motivating. Or, you know, the social component is working well here, but not the individual. Those are much more subjective in terms of interpreting the results. The very initial ones are very clear usually in terms of, ok, we go with A instead of B. And we thin of it in those terms. > > **Prototypes Can Take Any Form** > > Sometimes it's cutting up little pieces of paper and these are now game units. And you have, basically, rules and you can move you things your thing two spaces every turn, and you might have a very simple turn based two player game and you're moving the little pieces of paper around. Other times it might be a more constructive experience, where you're actually drawing something in a piece of paper and you have rules about how much you can draw, and you add up how many things you've drawn and what the cost is, and you're actually doing your own little kind of economic bookkeeping along side of it. What we call paper prototyping isn't so much it has to be paper. It really means that it's off the computer. You're not really programming but you're doing it with tangible little objects. > > One thing that I tried starting a long time ago was when I was first coming up with the game, I was trying to pitch it around, I would actually make two or three different box designs myself. I'd just print the stuff out, glue it to the side of a box, put them up there and show it to people. Which one of these games would you like? It's all the same game in my mind, but you know, these are three different ways of kind of informing what the game is about and presenting it. In some sense that's a marketing prototype. > > This way I would see, oh people really go for box B but A and C they don't like at all. This would initially tell me how somebody thinks about this idea and which direction I should go in terms of communicating. So that's kind of, in some sense a communications prototype. Later on as you start kind of playing with how we present the player or what's the interface, you know, those are things that are fairly simple. > > **Build Tangible Models** > > I found that when I make games it actually helps me to build real, tangible things. Before I actually build the game. When I was actually working on the sims, I decided I wanted to have a little neighborhood, and then eventually you'd build a little house and another until you had a neighborhood. I actually built a real model. How can I make the player feel like they are touching something real here. > > **Find the Fun** > > As you're building prototypes you start to find sweet spots. Then you think how can we take those really good spots and spread it out through the rest of the design and make it part of the spine? > > In the game Spore, we started building some of the editors early on, and it was so fun building these things, we decided, hey let's see if we can do a building editor. Oh and that's cool let's see if we can do a vehicle editor. We decided that the editors would be consistent across all the levels. They would operate pretty much the same. It was kind of a core activity that gave connection across these different levels. Spore otherwise was like 5 different games. > > Use the most Expedient platform. From my point of view it's whatever had the least amount of friction. I'm totally agnostic when it comes to coding base. Use it s a navigation system or a compass. > [!Abstract]- 4. The Relationship Between Story and Games > Games and story I think have a really interesting relationship with each other and I see a lot of game designers that really are aspiring to be storytellers. I've always thought that the coolest stories are always coming from the players. > > It's nice to have a backstory or here's the world and all that, but really you want every player to basically encounter their own story, create their own story by what they do in the game. That's the really interesting story for me. But as creatures, as organisms we are faced with this kind of fundamental dilemma, which is that we're here, the world's out there. Basically we have a limited bubble of experience, things that we know about the world and will experience directly about the world. > > Basically we take this in through our senses. We see the world, we perceive it in certain ways. It goes into our imagination. We actually start building little models of it. And based upon how we interpret the world around us, it influences our behavior, how we act out there. > > That limited bubble of experience is not really enough for us to build very effective models of the world. It's that experience that we are building these models of the world from. So over time, actually through evolution, I think we've discovered two other methods. One is to have toy experiences, where we have symbolic experiences and kind of abstract that back into the real world. The other one is to learn from other people's experiences. > > If my friend the cave man says that a tiger almost ate me when I left the cave, I didn't have that experience, but I know the next time I leave the cave I'm going to look out for a tiger. I was able to learn from his experience without having that experience directly myself. > > Over time and through our culture we've learned to call one of these things play, these toy experiences, and the other one story. These are both, though, fundamentally educational technologies. I think this is why we enjoy consuming these things because they actually help us build more elaborate, more detailed, world models. With a limited experience base. > > Now story and play have a really interesting two sides of a coin relationship here. Some of the really cool stories, the ones that really capture your imagination, you can deconstruct into characters, worlds, locations, objects. I watch my eight-year old playing with Star Wars LEGOs and he creates his own stories with storm troopers and all the components from Star Wars -- and he kind of understands that universe. But now becomes a set of things for him to play with. So I think some of the best games where players have a lot of freedom, creativity, lead to really cool stories. The games are actually generating stories as the players play. > > So in some sense, I think really good stories can generate play and really good play can generate stories. The two are kind of self supporting, but they are very very different actually. > > **Empathy vs. Agency** > > A lot of time you hear that stories have such a deep, emotional connection whereas games are flat. I don't really think that's true. I think that games really haven't matured as much. But I think what it is is that they have very different emotional palettes. > > The emotional palette of film is totally based on empathy. You can look at characters, actually simulations on the screen, which we call actors pretending to be these characters, and they are basically pretending to have emotions and we're empathizing with those emotions. So when they feel sad, we feel sad. When they feel happy, we feel happy. > > Games, the emotional palette is based upon agency. The fact that I did it. That I'm responsible, I have accountability, I'm the one that pushed the joystick in that direction. So I think that the kind of emotions that we can actually get out of games are very different. Things like guilt, pride, accomplishment, teamwork, are emotions I've felt in gaming that I've never felt in linear media. Because they were things that I was actively involved with. > > **Enable Players to Become Storytellers** > > As we were getting closer to finishing the very first version of The Sims -- we were of course bringing people in, watching them play it, just observing. As designers we were sitting back watching them play the game. As they were playing the game, they were telling each other the story of what was happening. It was hilarious! I really enjoyed hearing the stories. It was based upon what was actually happening in the game but they would elaborate and they would add details. It was fascinating how readily people would build a story around this. > > It's a fundamental way to convey things to one another, through story. At the very last minute we decided we were going to put a feature in so players could basically capture screenshots, write text, and basically build a little comic book, a little illustrated comic book, and then upload it with one click. We had a section on our website of players stories. > > It's amazing that a lot of these people may have never written down these stories at all. Because they did not have the creative outlet. But when they started playing the game, they recreated these things and they found how easy it was to share. Also people would post these stories and other people would comment on them and rate them. For some of these people who had never been praised for their creativity it made them tremendously motivated. It took very little positive reinforcement or recognition for these people to dive in. So basically, this game for them turned into a creative tool. A tool of self-expression. > > We later kind of developed that in The Sims where you're capturing movies and much more elaborate things. And of course along side of games there's been this really interesting field of machinima where people are actually using game engines to tell stories, very cheaply. And so that's something for the same reason, has been growing up along side of games and has turned into its own kind of whole medium. > [!Abstract]- 5. Exploring Player Psychology > More than anything else, I found the psychology to be really tricky, challenging part of game design. The technology is advancing every year. What we can do on modern computers makes me as a designer feel almost unlimited. You can do amazing things on these electronics. > > Player psychology, though, human brains are not advancing. They're kind of the same they've been 100 years ago. We have to learn how it works. What are the inner workings of that computer, and how can we exploit it and use it to our advantage? > > There's actually a great book - I think it's out of print now - it's called Maps of the Mind. Each page was kind of a visual representation of one phycological theory. It might be Maslow's pyramid or Freud and the id. Each one of them was a different way, a different perspective on the human mind and human psychology, and the way it worked. Each one if kind of a tool, you know? It has a purpose, it works well in certain situations and not in others. None of them are the sole approach to religiously adhere to. Each one contains something that might useful in the future. Maslow's pyramid turned out to be very useful for the Sims. > > Psychological Needs - Safety Needs - Belongingness and Love Needs - Esteem Needs - Self Actualization > > The very basic core of the sims had to do with feeding the motives of the Sims. Hunger, entertainment, sleep, all those things. We started building very, very simple little prototypes. That was just a set of sliders and buttons, like press a button for food, sleep, entertainment and basically trying to balance these little sliders. > > At some point we decided okay one of the major goals of the sims would be to have them actually go to work and earn money so you can go out and buy more junk for your house. Now we basically had a reason to get all these sliders up, to achieve a balance that they go to work in a good state. The better their state is the more money they earn. So we're connecting these base motives to the larger aspirations, which is exactly what Maslow's pyramid is all about. > > **Get Inside the Player's Mind** > > The game design is really kind of playing with the player's psychology. You know, by giving them certain freedoms, certain limitations, certain goal states, you're trying to get them into a certain motivation within this little world that you've crafted, and make them want to do things or want to avoid things happening. You basically want to set up this structure in their head that they're motivated to do this and avoid that. But you want to have an environment where they start feeling strong motivations for their actions. > > Now it's up to them to start testing their model against your model. They start building that mental model against your game. I think it was PT Barnum that said something like, no entrepreneur ever went broke overestimating the intelligence of the American public. My version of that is no game designer ever went wrong by overestimating the narcissism of their players, you know? So the more it is about the player, and the more the player is celebrated, the more the player is the center of that universe, generally the more they like it. > > **Build a Mental Model in Your Player's Head** > > At the very beginning, one of the chief fundamental components of game design, one of the skills that you really want to master as a game designer is the ability to build a mental model in your player's head. This is really kind of an art form. This is something I've learned from magic, actually, from magicians is that when a magician is performing a trick, what they're actually doing is they're getting the viewers, the audience to craft a mental model of what's going on, but they're getting them to craft exactly the wrong mental model, such that you think this is in my hand, I pull the handkerchief back, it's not. I've actually through a lot of different techniques, as a magician, got you to build an incorrect mental model, and through the reveal the audience realized their model was wrong. In fact, what the magician was doing was some other manipulation over here. And as a game designer we take that kind of approach in some ways. > > We're actually having our players interact with little pieces of computer memory and code and interface buttons. But in their head, they're building an entirely different model. There's a world that they're in with verbs and nouns and affordances and agency and actions and possibilities and goal states. That's what we're actually building in our player's head. And so in some sense, the game designer is a much more elaborate magician doing this. > > **Human Behavior is Derived From Mental Models** > > We're modeling things all the time. You're modeling other people all the time. I'm imagining what my friend is thinking about me. I'm imagining what they know about me, and I try to be consistent with that. So I'm not only building a model of my friend, but I'm building a model of their model of me, you know? It's recursive. I can kind of remember what they have seen me do, how they've seen me behave. And I have a very rough sense of what their model of me is, and I try to be consistent with that. So this modeling is pretty deep and recursive in that sense. > > You can put any kid in front of a video game and right off the bat they start mashing buttons, looking at what's happening. They observe. And it's very much the scientific process, you know? Where they're doing hypothesis, experiment, look at the result, go back, refine the hypothesis, experiment, look at the result, and it's that iterative scientific process. And that is basically model building of a different sort. > > In building models, we take in a lot of data, a lot of examples, and from that we start looking for patterns in that data and things that are different, things that are the same. After that we start building abstractions out of that, these -- what we'd call schema. And basically, these are patterns we see in the world. Any kid can tell you the difference a dog and a cat, and that's a schema we have internally. And it's really a very fine set of features to distinguish the difference between a dog and a cat, and compare new information against our schema. > > From that, we start building more elaborate things called models. The schema of these patterns now become the components of the models that we're building. And that goes on to influence our behavior. We behave against these models, basically running scenarios. Should I do this or that? Should I get this job or that job? Should I say A or B? So all of our behavior is based against us playing these models in our head about what we should do. > > Now schema, are really interesting in that we have schema for so many different things. For instance, in a restaurant we have this rough idea of things that happen when we go into a restaurant. Now, not all these things always happen. But in general, it's a pretty good schema for what to expect when I walk into a restaurant. (Enter restaurant, be seated, get menu, place drink order, recieve drink, place food order, eat food, recieve check, pay check, leave.) > > Some of the schema we are dealing with: Classification. who are the good guys and the bad guys? Causality. If you find a pot of gold, you'll be rich. Empathy. If you see a hungry dog, you feel bad for it. Agency. If you have control, you can command your fate. We have schema for all of these differnet things. You are controlling a player's schema, in some sense as a designer, by what you present them with, how it operates, how it behaves. > > When I see five turtles in a row coming at me and they all attack me, I start saying, okay, turtles are a bad thing in this game, you know? That's a schema I'm building as I play the game, part of the model building. And games in some sense are generating these worlds from the models. > > So a game is really almost the reverse of science. Science is really taking all this data from the world, compressing it down into a very concise, small rule set. Laws of physics. Games take a very concise code base and try to expand it into a wide range of possibilities that the player's going to encounter > > In your game. And then the player is trying to reverse engineer that process and now build a concise representation of that. These mental models are key, for a game designer to realize that's what they're building. > > **Allow Your Model to Diverge From Reality** > > The mental model that we're trying to create in the player is something that may or may not have a purpose for you really. I might be building a mental model for some players of SimCity about how cities work, but I know as a designer of SimCity that model is not going to be correct. There are things about SimCity that do not match the real world. > > A lot of times games and filmmakers as well will actually build a model that they know is incorrect because that's what the players expect, you know? > > If I'm trying to build a training simulator for an airline pilot, then yes, I want that simulator to actually train them to build a model of the way that plane really behaves. As an entertainment designer, and if I'm designing a city simulator - and most of these players are not going to be designing a city like this. Most cities are not designed with one person as the overlord. It's much more political. So I'm not concerned when we take liberties like that. > > **Enable Player Communities** > > As an interactive experience, we want this whole thing to be centered on the player. And understanding that every player is different is key to that. We want every player to be able to take their own path, have some freedom, agency within our games. So we need to start thinking about how players see themselves, their identity. > > Now everybody kind of wraps a lot of things around who they are when you present yourself to other people depending on the context. There's a place where you live, your neighbors. Your job, your profession, your skill set. Hobbies, things that you do. Or brands, products that you maybe have some allegiance to. All of these things are components of your identity. And when you're interacting with other people these are ways in which you kind of mark yourself. This defines who I am. > > We have a lot of personal aspects to our identity, but we also have communities that we live in. Sometimes real geographic communities, sometimes online communities. Some based on location, some based on interest, profession. Then there's the world. We find that when player's come into games, they all kind of come in the same way. > > Players all begin as casual's within your game. Now players going down that path in your game have a trajectory. The game can present different branching paths and a lot of the time it becomes a community. > > For the Sims, we actually had a lot of casual players started to turn into what we called collectors. They would go on the web and we found a lot of other people that made objects or characters that they could download into their game. So they could start to collect special things. Other people were actually building these collections on their websites. At first they would upload their objects, then other people would start contributing. We called these people webmasters. Then the core creators were kind of feeding these websites. So there was an ecology and as players became more and more involved it became more and more of their identity. This was their hobby. For a lot of these people these games become a kind of hook into a social network of sorts, or different types of social networks. > > So in a broader scope the game becomes a part of the players identities and is linked to how they think of themselves and present themselves to the world. > > **Motivate Your Player, Then Get out of Their Way** > > I've heard a lot of stories from players about how they've taken their game experiences and how it's changed their life. For some people, they became storytellers. You know, they started making a few stories on their Machinima or whatever, uploaded it, and a lot of people liked it and loved their style or the stories they told. And so it kind of really pushed them into creative writing or filmmaking. > > Other people - I've talked to a lot of people actually who played SimCity and went into Civil Engineering, just because they enjoyed dealing with that kind of system. Other people went into biology because of SimAnt, things like that. Sometimes it's motivational. > > In education, I think the fundamental issue we have isn't so much how we teach kids, but it's how we motivate kids. If you can get a kid motivated in a subject - they have plenty of resources to go learn it on their own. From that point just get out of their way basically. That's the key. > [!Abstract]- 6. Design Player-Centered Experiences > One thing that game designers really should know is that it's about the player. It's a player centered experience and the player is the one driving the experience. It's the difference between being on a roller coaster and being in a car behind the steering wheel. Now that character, because they are holding the steering wheel, is responsible for where they go. They have choice. They have decisions to make. Because of that they take ownership. When somebody feels like they are in control of the process, they own it. And it now has a fundamentally more personal connection to them than something that's one size fits all. > > **Enable a Flow State** > > I think of flow state as basically something that's right at the limit of your abilities. It's pushing you mentally, but it's not too hard. If it's too hard it's random, arbitrary, frustrating. If it's too easy it's predictable, it's boring. Flow is putting you right on that edge of your abilities and really testing them. There's a rule of thumb in racing that if you weren't crashing 10% of the time then you weren't trying hard enough. > > You need to design the game such that failure is interesting and understandable so that you go back and say, aha, now I need to avoid the turtles, or whatever it is i the game. Then you kind of grow and build that model. Also you're building your ability to problem solve and strategize. > > Every player is going to be different. Different abilities. Different skill sets. In a lot of ways, you want to make the game such that the player is the one adjusting the difficulty. You know they could choose to go a little bit further and try for this harder thing, or stick with the easy stuff until they're more comfortable. So in some sense a lot of it can be player paced. > > There are more advanced systems that are called DDA or Dynamic Difficulty Adjustment, where the computer behind the scenes is kind of watching what the player is doing, and if they're failing too much, the computer can actually lower the difficulty level or increase it if they are not being challeneged enough. But, in a lot of games, by giving the player enough freedom but also enticing them to try for the hard things-- if you try for this harder thing, you must get a bigger reward. So at that point, the player can kind of choose their own level and put themselves into the flow state. > > **Failure accelerates learning** > > There is a whole topic known as failure-based learning. And we have this -- failure is a loaded term, people tend to think of failure as bad. I don't want to fail. > > There was a great story I heard, it was an art teacher in an art class - it was actually a pottery classs. And at the beginning of his class, at the beginning of the year he divided his class into two halves. And the first half, he said, OK, your final grade is going to be based upon one pot that you make. I want you to make the best pot you could possibly make, and your grade is going to be based upon that. The other half of the class, he said, OK, your grade is going to be based on how many pots you make. I don't care how bad they are. The more you make, the better your grade. At the end of the year, of course, it turns out that the half of the class that were building the most pots were also building the best ones by far. They had built so many bad pots and had iterated so many times, they learned very rapidly, and by the end of the class they were building these amazing pots. Whereas the other half that spent all there time tinking about the one pot that they were going to build never got anywhere. So it was the failure that accelerated their learning. > > When players play games, they are failing most of the time. If you can make that understandable, humorous, enjoyable in some way - then that can be an enjoyable process, especially when you get past that first failure to the next level. > > **Design Nested Loops of Success and Failure** > > As a designer, we're constructing this mental model in the player. It's important that we ramp that model up smoothly and gradually for the player. You don't want to pile all this complexity on them right at the beginning of the game, its overwhelming. You should actually present them a simpler model. > > They can start building from that simpler model layer and layers of complexity onto it in their head as they encounter more and more things in the game either through more elaborate world items, monsters, opponents, abilities, tools, whatever. So the designer is responsible for ramping that model in the player's head. > > When you're playing an interactive experience, you're actually going through a set of nested loops of success and failure. You go from very tactical and very granular to longer and longer loops of success and failure. At every level, you are probably going to enounter failure. People are actually spending most of their time in games failing in different ways. It's not that you don't want players to encounter the failure. You want them to understand the failure and build a model around that failure so that next time they will succeed. That's part of the motivation. I understand that's good and that's bad. Next time I will not get stuck by that. > > With a game like sims, you have a character, and initially you first have to figure out how to make them move, walk around and interact with things. So in some sense that's the very first game loop we are dealing with here. We'll call this the first interaction loop. The next level is about keeping the sim happy which we'll call the happiness loop. This loop is roughly one minute at a time. The next one would be jobs, which is an even longer loop. > > In addition to dealing with all these game loops. The player is doing weird stuff like creating a story, or trying to replicate their family, or just exploring. So there are other loops, that are in a different dimension really, that don't have a lot to do with me succeeding on the game success curve but have more to do with the player exploring their own creativity, and their own expressiveness. Some players get totally invested in this and begin ignoring the main loop. The layers of their mental model very my coincide with these interaction layers. > > **Make Failure Fun** > > Most of what the player is going to experience is failure - again, and again, and agian, which doesn't sound very fun. But i's the game designer's job to present that in a way that it's entertaining and informative and that it's not frustrating. I don't want to be failing the same thing over and over especially when I know why I am failing. > > So when somebody fails in a game you want it to be understandable, and something that they can overcome. Also humor can be a great tool to alleviate the frustration. Sometimes you want a variety of failure states that become humorous, so at least when they're failing its not repetitive. You might have different animations for the same failure. > > **Build a Smooth Ramp in Complexity** > > The kind of games that I make tend to be more system-level games. Frequently they involve you constructing something that gets more and more elaborate over time. As you achieve success and your city grows or the sims add more stuff to their house, you are adding more complexity to their world. > > In The Sims, there's kind of this promise that if you buy this crap for your sims it will make them happy. But in some sense, as you acquire more and more of these items, they become time bombs. Each one of these things has a failure state or some maintenance requirement or whatever. Each one of these things adds complexity to their world and makes it much more difficult to play the game. It's a very natural smooth ramp in complexity. In some sense, the player is asking for it. > > **Create a Landscape With Different Paths** > > It's not just how much difficulty is in the path, but also how many paths are there? I think that the really interesting games are ones that allow different paths toward some kind of success. In some sense, the games that I do don't even make success that explicit. In some sense the player is choosing the goal state. Each one of these goal states is going to have a different path of difficulty, for me, it's more about a landscape of paths that the player can take. None of them have peaks. They all have different moderations of slope. > > It is an emergent property, so it's very hard to say, okay here's how we code that. A lot of time players will find exploits around it. Or it will turn out, again, pressing the red button is not that obvious. So this is something we will actually capture metrics on. How long is somebody spending on that stage? How many people are failing on this point? These attributes are fairly parametric, that you can adjust granularly. > > **Rewards and Incentives** > > Rewards in the game can come in many forms. You know, there's just the advancement of how far did I get in the game? Or there's special abilities that you might gain that now allow you to achieve things you couldn't achieve before. I think sometimes rewards are a little overly relied upon. When you have power-ups and stuff in game. It gets rote, boring, a little too obvious. > > I think a lot of the really interesting rewards are things that they think they came up with themselves, or things that they discovered in the game. And I think discovery is a huge part of this -- if you leave areas of the game that are maybe closed off to the player, but at some point you just open one of these gates and say hey, there's a lot of stuff hidden in here if you go a little bit deeper, or try a little bit harder. Players love stuff like that. > > You see things - people playing Grand Theft Auto or whatever. They manage to get on top of places that they weren't supposed to be able to - exploits. Then, of course, they make a movie of it. > > Incentive in the game is really coming from the player. The process that they are going through. It is generated internally from the player, not externally from the game designer. It might be a creative process, a social process, a challenge. That is something that the player innately has a desire to achieve. They come with their own objectives. > [!Abstract]- 7. Develop a Game Language > As a designer you are putting a player into this world of yours, and through their interactions and freedom and agency that you give them in your world, you're actually kind of developing a language with the player. They are basically learning this language of the game and it's the designer that is creating the world that is defined by that language. > > There's an interesting aspect to games - and this idea was way before computer games, of the magic circle. And this is the idea, especially in social games. Kids come together and decide they're going to play whatever, hopscotch, and the players of the game are basically now within this thing we call, the magic circle. They are bound by the rules of that game. Other people might be outside of that circle, observing and watching the game, but they are not part of that game. > > In some sense, you're kind of building a temporary community with the players within that game and they're all basically bound by the game rules and living in that world together. This is in some sense, one of the fundamental parts of game language. Are you playing or not? Who's playing in that game right now? > > **Teach the Player your Game Language** > > As a language within games, I think that we do have the same types of grammar that real language has. In the world, things are basically kind of nouns, verbs, and adjectives. You can almost interpret everything in the world according to these parts of speech. In a game players will encounter the same thing. > > When you're designing what the language of your game is - the nouns, verbs, adjectives, of course it depends entirely on the setting you are putting a single player into. You can give a player a setting or show them a screen and tell them, what would you imagine wanting to do here? As a player you are thinking "What are the things I should be able to do?" > > For a lot of players, once they kind of immerse themselves in this little world there's going to be a set of things that they would like to try. And if you give them a goal state and say, try to do this, it's going to be much more specific. > > You're going to start deciding how much freedom or agency does the player have in this world. What kind of things are they going to manipulate? What kind of things are we going to give them so that they do it very naturally? You also need to present things things in the world so that it is fairly obvious they are nouns you can manipulate. Or part of the game world. Or part of the game actions. > > I think you're informing the player about these things in a lot of different ways. Sometimes its just the art style. These things stand out a little bit against the background so they're important. A lot of times you'll have like the background trees and landscape are a little more muted, while the foreground things like Jeeps and Tanks are saturated in color. You're informing the player of the important nouns in the scene through the visuals. > > The verbs are going to be very dependent on the interface and the point of view of the game. Whether it's first person or third person or whatever. A whole set of things will occur to them and a whole set of verbs will occur to them. > > **Reference Real-World Play** > > Also part of the language, metaphors are very, very useful as a tool for designers, so that the player can come in and have at least some grounding for what kind of a system they're dealing with. And even if it's not direct, it can be an indirect metaphor. > > The Sims I used to refer to as dollhouse. Really, that's the metaphor for The Sims. When you see The Sims, it's a little house, with little characters and it pretty much is like an animated doll house. > > When I was building SimCity I really kind of felt like in some sense it was a digital train set. I wanted SimCity to kind of have that feel. Crafting this little world that came to life. This little automata. That metaphor of the train set became a guiding principle. I reference these childhood games a lot. These aren't things that were invented during my childhood. These were activities that have been around for hundreds if not thousands of years. These are basic aspects of play. > > I'm certainly not advocating that every idea that you come up with has to have some precedent, either in your childhood or in history or gaming in general. In fact, I'm sure there are a lot of very cool, unique experiences that are totally unique to this medium that we have yet to discover. > [!Abstract]- 8. Designing a Visual Aesthetic > As you start to refine your prototypes, you'll reach a stage where you need to define an aesthetic. The visual aesthetic is going to add a whole new layer of meaning and depth to your game. This is one of your primary ways of communicating to the player. Finding your own style is up to you as the designer. > > **Discover Your Style Through Research** > > I would tend to approach, you know, finding and discovering an art style, I think very much in the same way that I would approach game concept research. Basically go out and look. You know, there are a million references out there. Not just games obviously, back in historical fine art, or in whatever. You can just imagine all different areas to grab visual inspiration from. > > Kids will go back and play these retro games or like Minecraft, like Lego, they are visually basic, and it has become a style to them. You look at these Lego movies, which are great, and they make these amazingly entertaining very visually engaging movies out of a Lego world. As a style it's delightful. > > If you think about certain things a little more deeply to the next level, you know, how could that be a style? How would it animate? You might discover regions that are very unique. The games that I work on almost have a toy-like feel to them. To me that kind of makes it feel more playful and approachable. One of the things I really enjoy looking at is tilt-shift photography. Where they take pictures of the real world and make it look like a model. In some sense it's an invitation to agency. In a subtle way by making it feel a little more toy like or model like, you're kind of getting the player into that mindset that this is something for you to interact with. > > **Visual Inspiration for Spore** > > One of the things that I did on spore and this is in the fairly early stages is I downloaded hundreds of images that appeared on these pulp comic books back in the '50s and '40s. These were always some science fiction stories and it was always some weird tentacled alien holding a blonde who's passed out with some weird spaceship in the background. I loved just looking at the style of those comic book covers. We printed them out and put them all over the office. It became a guiding principle for the game. > > **Leverage Available Technology** > > The visual style of my games initially was on these 8-bit computers, and we were counting how many pixels we had, how many colors, it was really severely limited. Over time, those limitations eased up more and more until we got a high powered graphics card with pixel shaders and what not. We got to the point where we could achieve a high level of realism, which I didn't think we needed. On the other hand we could use these things in ways that were kind of unexpected. > > For instance, in Spore one of our programmers discovered that she could use the pixel shaders and the graphics card to actually simulate turbulence on a gas giant. She was getting these really beautiful turbulence patterns. It's just very simple manipulations of the UV coordinates within the graphics card. > > Things like getting the player more involved and more creative. So the fact that we could do procedural animation in Spore was really the result of the horsepower and the programming. It reflected itself in the fact that the graphics looked in the style, but the really important part was that the player created it. At that point it doesn't really matter what it looks like. If the player created it then it's a whole different ballgame. > > On the art side it's always been how can we get the player more involved in making these assets in a way that's natural and fun? > > **Art Direction Informs Overall Design** > > When working with great art directors it has been a matter of their vision bringing really great alternatives to me. In general, when confronted with alternatives, I would say "which one of these feels more playful to me?" Microscope. Layers of focus. > > **Collaborate With Your Art Director** > > Finding a good art director will be similar to finding a good sound director. You want somebody who listens, first of all, and tries to understand your vision. Somebody who can come up with ideas that you can't. To present you with choices. There's no one size fits all. Sometimes you'll want a very particular style as a designer and you don't really want somebody giving you five other styles when you know you want that one. Other times you should be more open. > > It also depends on the size of your team. If you've got a very small team the art director is also going to be one of your artists. You should enjoy collaborating with them. > [!Abstract]- 9. Game Mechanics > There are tools, or mechanisms, or patterns of interaction that you can use that you give the player. This kind of creativity, this kind of affordance, this kind of agency. Underneath the hood, the game is actually doing some causal connection between when the player does that - this happens. Or here's the limitation. > > It really comes down to an affordance or an action that the player is allowed in a game and how the game responds to that action. It kind of defines what that challenge is. If it's a locked door, what is the puzzle, or what are the items needed to unlock that door. If it's an exploration thing, what path do you have to take through this maze to get to that exit. If it's a resource allocation thing, it's what are the basic resources? How are they being consumed? How are they being earned? > > Each one of these is kind of what we call a game mechanic. They're like little closed systems of somehow interaction, balance, economy that you can connect together to make a larger interactive experience. > > **Enable a Conversation Between Player and System** > > Mechanic is some kind of process going on between the player and the game that you might attach metrics to. You might attach a leaderboard or scoring system to that. But once you have that process going on to moderate the player's progress, you can use that process to add difficulty. You can use that process to make the world more interesting, more mysterious, more kind of tangible. > > There's a lot of ways to use these, what I like to call micro processes to build up that larger process of here's what it feels like to be in that world. In some sense I think of this as the dynamics. You know, as a player's doing things in the game, how is the game responding to that player? What is the conversation that the player is having with the game system? Each one of these mechanics is kind of one type of phrase, or interaction , or word the player can kind of express within that system against the game. And the game will respond in certain ways. The player is kind of learning to converse with the game system through these mechanics. > > **Find the Right Mechanics** > > When we talk about game mechanics, to me these are parts. It can be a part that's been used many many times, or it can be a brand new part that you've invented on your own. To me what really matters is the whole that's built out of these parts. So I might have a fuel injection unit, and an engine, and a differential, and wheels, and I start putting these together to make some kind of car. Maybe I decide I want a flux converter and I invent a flux converter and I stick it in there, that's great. > > What really matters is the entire car. How is that car going to drive or not? With the existing mechanics that we have right now, obviously we can build a huge number of different kinds of interactive experiences. Every now and then you might want that flux converter. You might want some brand new thing. I don't think it's that you come up with a cool mechanic and say, how do I use it? It's more like, here's an interactive experience that I want to create, now what do I need to create it? If it turns out there's something brand new, something you need and can't figure out an existing mechanic that will provide that, that's where you'll go off and make your own. > > I am very happy to go off and make my own mechanics if I need to. I don't even really think about it in terms of, this is a new mechanic or not, it's more like this is the right mechanic. Whether it was invented by me or somebody else, I think there's always the right part to fill in that gap in your design. > > **Create Both Overt and Hidden Rules** > > If we talk about rules for a game, I think that there are almost like, two kinds of rules. You know, there are the really overt rules that you want to inform the player about. "You need to escape the dungeon." Whatever it is, there are certain things that you are very clear with the player about. > > Other rules the player will discover is that part of the early gameplay is the tutorial. You encounter objects as part of directed gameplay early on and the game itself is kind of teaching you how to use a sword. But then there are a lot of rules that you want to hide from the player, they're under the hood, they become mysterious. In a lot of ways you'll want your game world to be a black box at some level. > > This actually gets into the idea of immersion, that a lot of times somebody will look at a system - for example when people look at the simulation in "Sim City" they start imagining this ungodly collection of mathematics and things calculating this incredibly complicated city. In fact, it's far far simpler than that. You know, in fact, we found a fairly nice emergent system, so it was a simple set of rules that kind of emerged into the complexity of a city simulation. > > If players saw under the hood in some sense it would kind of destroy a lot of the illusion there. The illusion of life. It's very similar to the same reason why we didn't have the Sims speak in a known language because as soon as they started repeating the same things over and over they would seem incredibly simple and robotic. But when you can't quite understand them, you tend to read in a lot more. > > There was this thing we started calling "The Simulator Effect" after watching the first batch of players playing "Sim City" a lot, they would write letters to us "Oh, I love this game." They would describe things that happened to them in the game. Things like the plane crashed, and then the power lines caused a surge and the house set on fire. They would describe all these causal linkages that did not exist in the game. But in the player's head they did. Nothing about the game dissuaded them from the fact. So they were building their own mental models of how this game was working. That's when I realized that there are certain parts of a simulator that you want to keep a black box. > > The players can imagine their own simulation usually far more interesting than yours if you provide them enough scaffolding to build that in their imagination. We ended up calling that "The simulator effect" where they imagine your world or your simulation is more detailed, more rich, more complicated than it actually is. I don't talk them out of it. > > Part of exploring the world is, in fact, kind of uncovering these loops of complexity in these rules, and so part of learning the rules of the game are imbedded into the game, which is actually very natural. > > **Use Simple Mathematics** > > There's this thing called The Monte Carlo Method, which is using chance basically in the place of calculus. A lot of things would be simulated in the natural world, we have established mathematics, which is linear calculus. But it turns out that for most of these things with a computer, there's a whole other approach that basically can solve the same set of problems. It's basically throwing darts at a dartboard that have shapes on that dartboard that are about the right area. > > This is the kind of simple mathematics that we use a lot in simulations. This is relying very much on these probabilities and it's the way a lot of the emergence we can get out of these systems works as well. So from the design point of view, it's amazing how you can build very simple things like that in place of what used to be very elaborate mathematics. > > **Use Probability and Chance to Your Advantage** > > There's another kind of chance, though, that I encounter as a designer which is I'll be making something, doing prototypes, whatever, and something just pops up unexpectedly. Either we made a bug in the program, or it's not behaving the way I thought or something happens that surprises me. Through pure chance, I might trip over some new mechanic or some new feature. This is like serendipity. > > Players are always going to be trying to assign causality to something. You need to be sure that the feedback you are giving the player is signal and not noise against this complex model. > > **Ensure Player Agency Determines Fate** > > It depends on the feature of your world. What feels like an expectation of the player? You don't want the world to feel like arbitrary things are happening for absolutely no reason. What you really don't want to do is have the game feel capricious in terms of killing the player for no obvious reason. The player wants to always feel that success and failure are a result of their agency. > > **Expand Your Palette of Game Mechanics** > [!Abstract]- 10. Game Demo: Morey > Morey is a side-scrolling puzzle platformer. The premise is that you play as a woman named Nina who has been stranded on this abandoned space colony. She's trying to find the equipment she needs to get back home. The gameplay is like a traditional Metroidvania game. The premise and a lot of the upgrades involve changing gravity. > > One of the mechanics is that you don't start with light and eventually you get a torch. When dealing with a limited perception like a flashlight, sound is going to be a huge part of that. You're missing out on 30% of the experience without sound. > > Now that the core mechanic is established the idea of exploring a lot of different level designs become necessary. > > For a short game such as this replayability becomes a key factor. Shortcuts and upgrades which a player may be able to access early on will better lend themselves to replayability later on. > > Don't start with this game is a side scroller. Say this is a game about gravity > [!Abstract]- 11. Iteration and Scoping > As we get further into the development process, the prototyping we are doing is far more granular. There are a lot of things you can do and a very small subset of that is what you should do for the player. Scoping is really going to come down to what is the right sweet spot for complexity and interest. Prototyping is one of your tools for discovering that. > > For Spore we did 50 to 60 prototypes for areas of science that we might have included in Spore. After playing with the prototypes we decided either it didn't really fit in with the overall concept, or that system as a little toy, just wasn't a very fun toy to play with. The one's that were fun to play with we figured out, OK, which one of these can we now click together and build in to a larger experience. And then eventually they turned into gameplay prototypes, where actually there is a game there. > > **Experiment with Simple Scripting Languages** > > I could take the same little codebase, I as the designer, could go in and change the scripting of it and change the rules within the simple prototype. I was in fact doing a lot of the programming, on these prototypes to explore different rule sets. In fact I was able to recreate very simple versions of "Sim City" and a few other games within these Spore prototypes. > > Some of them were using very kind of interesting systems and topologies. Some were network-based, others were grid cellular automata based, and the fact that as a designer I could very quickly go on and script, over one evening I could try five or six different rule sets, play with them for a while, gravitate toward an area. Once I got into some area that I liked I could bring it to the programmer and say, "Ok now build me a better version of this." Or maybe it had some limitation and I wanted to copy a couple of more commands to the scripting language. It very rapidly allowed me as a designer to explore different rule sets. > > **Iterate on the Highest Risk Items** > > I would work with a triage design team and say "Okay what are our biggest risks." They could be technological risks, they could be design risks, they could be production risks. And then we step back and say, okay how do we mitigate that most effectively? "Can we actually build this?" Let's build a prototype and see. Every week we are basically trying to attack everything on that list. As you are going through iteration it should be a continuation of that process. Attack the highest risk item. > > One of the typical aspects of risk in this kind of development is that the longer you delay it, the more expensive it is. Because all of these other things are going to have to change around it. This is about efficiency now. How efficiently can I prune that design tree? And I want every pruning of every branch to be as expedient and as efficient as possible. If you can mitigate it early then you're on the right path. > > **Iterate Away From Local Maxima** > > There's so many times where you're developing something and it's really starting to calesce and starting to feel pretty good, but it feels that no matter where you push it, from that direction it gets worse. This is you being stuck in a local maxima. At that point, it can be kind of apparent intellectually to you, that what you really need to do is some major change to it. That's a very hard thing to do is maybe to take that hit. Try it. Maybe it gets worse. But with a little bit of iteration you'll find that the design is in fact better. That's a very kind of stressful process to go through especially with a team. > > In my experience, all the very best games, and all the games I've worked on that ended up as hits were things where we went through that several times, where we really had to kind of take this hit and say, OK, look, we're going to have to do something pretty radically different here, and I think it'll get us on a taller slope. In most cases it did. A few cases it didn't, and we had to kind of go back and do it twice. That's the difference between making a good, kind of mediocre game, and a hit. > > **When in Doubt, Double It** > > Tuning can be really challenging, and in fact, it's more a process of discovery. What I was doing for a lot of things, like for "Sim City" is I would actually build test patterns. So I would expect to see this pattern of road, or building. I would expect to see this result on the traffic layer, in my head, then I would actually draw these out. This is kind of what I would expect. Then I would run the model. And it would be nothing like my expectations. > > It wasn't apparent to me how I would change it to make it like that. Instead what I found was I had to make it easy to just explore that space. Change the rules very rapidly, very quickly and look at the result, to zero in on the right rule set. And again, because its an immersion system, there's not really a predictive way to know where to go. It's more like you had to learn to explore this space very, very rapidly. > > And in more of typical parametric tuning, Sid Meier actually had a really good rule of thumb, whic is that whenever you're tuning your variable in a game don't move it by 10%, 20% either double it or half it. Initially. Usually it's going to be way off. So you either double it or half it, whichever direction you need to go, until you're in the region. Then you can do the tuning. But really, you're probably way off to begin with on almost everything. Don't be afraid once you have it running to try it. Double it for the hell of it. > > **Learn From Failed Prototypes** > > Most of the prototypes that we've created for the games I worked on were failures, which is good, because again, they're helping us prune design branches. Do we want to go that way? You'll note that once I take this branching decision tree all the way down, most of the branches can be pruned. They're failures. > > We did some really cool prototypes of "Spore" of the galactic dyamics, the balance of interstellar matter and stars. It's a very cool dynamic of the way stars are formed. Gas cools, it coalesces, gathers into molecular clouds, starts more star formations, which propogates a wave around the galaxy. Very cool dynamics. As we began scoping it we realized that it really had no part in the context of the game. It's a cool dynamic, but it's not spore. > > It's really hard when you've invested a lot of time and effort into one of your passionate features or components and either through prototyping, testing, or whatever, it just foesn't have a place in the original design. Emotionally I think you kind of need to sit back as a designer and say, OK, am I designing something for myself aesthetically or something that I really want to impact a large number of people? > > Sometimes that thing you really passionately care about that doesn't have a place in your design, that doesn't mean that it won't have a place somewhere else. It might be that it's the thing that's eventually turn into what it should have been. Or maybe you even jump ship and go with that instead. Throwaway your original idea. There's no hard and fast rule for this. A lot of times it can be very hard emotionally. It's important to recognize a failure and sometimes celebrate it. I've failed, lets make it a monument to learning. > > **Scope Your Design** > > You can put any kid into a game and within a few minutes, they can intuit how open ended that game is. How much freedom and how much agency they have in that game. A lot of times, people over-engineer things, and programmers tend to do that too. "What if you decide you want this later so I'm going to go ahead and put it in now." And they'll build something twice as complex as what you actually need for the game. This happens all the time, especially on the programming side. > > A game developer has to have an understanding of the psychology of all the members of their team. This is how the artists think, the programmers think this way, the writers, the sound people. Make sure that no one side of that is spending too much time relative to the others. A lot of it is more of a balancing act across the different components of your game design. > > **Feature Triage** > > A lot of design teams do this. Basically form a triage. The designers - once they have some handle around what this game might be will come up with a set of features. It would be cool if it had this, that, or the other. Hand the information off to various members of the team and have them rate the features on a scale of 1-10. Analyzing cost, priority, etc. Reorder the list when finished. It is nice to have something playable sooner. > > **Triage in Spore and SimCity** > > There have been situations where it was so important to the designers the cost was almost irrelevant. It was really could we do it or not. When we did "Spore" we really wanted the players to design the creatures and we wanted to have a wide variety of possible creatures. We basically couldn't figure out how to animate these things, because we didn't know what they were yet. Typically animation is very data driven. So we kind of realized early on that we had to crack this nut of procedural animation to make it even viable. Without that, we couldn't go down that path at all. So we kind of stopped everything. Got some very skilled people, very smart people to work on this problem, for a few months. And they showed us they could do it. They built a few prototypes and showed us that they could do this. That's an example of where it was imperative that we needed the feature and we just had to figure out if we could do it. > > Ideally, everytime you add something to a game, it's like a force multiplier. It's making the other stuff even cooler, making the world seem ever richer, or more emergent. As a designer it's important that you are keeping in mind the entire design. Not just one little set of it. > [!Abstract]- 12. Prototyping Case Study: Proxi > Inside of each of us, there's a subconscious. There's a whole region of who you are that is, in some sense, inaccessible to you, but drives your behavior. The game I'm working on now is called Proxi, and my core motivation is can I build a gameplay experience, an entertainment experience where the computer is actively trying to gain a deeper understanding of the player? > > Primarily through the player's past experiences, through their memories, can I kind of interpret the memories of your life, the most important memories that made you who you are, and from that, come to some understanding of how you think? What makes you behave the way you behave? Why you connect these certain things in your mind that most people don't connect. What drives your interests. > > How much can I get a computer to learn that about you, and then try to build a representational avatar of your ID, of your subconscious, that you can now interact with. And as it learns more and more about you, it kind of, in some sense comes to life and can now interact with other people's ids. Kind of asynchronously. It can go off in the world and interact with your friends or with, you know, real or historic or fictional characters. > > How does your Proxi get along with the Pope's Proxi, or the president, or Homer Simpson. I want to know, can we build a map of that? Can we start to understand it? Can we build a structural description of how this thing works and the connections it makes? And what makes you different from another person? How is your id different than that person's id? How does it make you behave differently in a situation than they behave? > > If we can start getting that level of understanding, and we're analyzing memories, I think that's the path. And I'm not sure about this. This is just kind of my theory. But that's what we're trying to do with Proxi. > > Today, we're going to walk through the process of creating a game prototype. Basically, we're always doing this to answer some specific question about the design that we're working on. I'm here with my programmer Zecmo, and we're working on the this project here. In this project the user is creating memories that come into the world and basically turn into this kind of landscape. We're trying to figure out how should these memories come into the world. It just kind of pops up into the world right? > > So I want to prototype something where we try different ways to bring new memories into the world here. They come in on boats because it's mostly ocean here. So we could actually maybe have, when I create a memory it actually is on a little boat coming into the world. It sails around kind of looking for a place to live. As I'm looking at this world I get the opportunity, in fact I have to offload this memory, and as I do it will actually change the terrain. It actually makes the continents larger and change form. > > **Prototype One: Tangible Memories** > > So the players just created a new memory, and they've come back. So we're going to simulate this with a simple button press. So basically I am grabbing the memory off the boat. As I move it around, I get a sense of the landscape. It tries some good feedback so you know where the connections are. You can actually see the terrain before releasing it. I like the tangibility of this. These boats could have a lot more elaborate rules if we wanted to. Pathfinding. There will be shipwrecks. We could have collisions. The boats maybe have pathfinding and gravitate towards certain areas where it thinks it wants the memory to be. I think this is actually a good direction for us to go now. > > I think maybe we're done with this prototype. I'd like to play with it a little bit longer and figure out, you know, do we want to elaborate on this prototype or maybe go with another one? Oh, I got a turtle this time. I actually like that, it could be that the memory type is somehow related to the vessel. I hadn't thought about that, put just playing with this prototype, just because you threw that in there the idea of having different classes of memory seems tangible. > > So in this case, we've established basically a resolution to this question of how new memories come into the world. And just playing with this for a few minutes. I can clearly see that it feels much better that what we were doing before. And not only that, but based on just some things that Zecmo threw in there, it kind of inspired me to think in a different design direction slightly. So I'd say this was a very worthwhile prototype for the amount of time spent. It clearly gives us much more clarity. > > **Prototype Two: World View and Camera Controls** > > Prototypes like this help us explore the space much faster and more efficiently. We're still in an overhead view of the world and I think one of the things we should try is a different view of the world, whether we go to 3D, isometric, with a full camera rotation and all that. It's going to be a real balance there, I think. Between legibility of the world and the player being able to do interesting exciting things in there without having to worry about the camera angle. > > If we're thinking about a 3D view. I can take a day or two to do a very simple version. Where it's just simple objects, basic terrain generation, and just dragging things around and see how we like that. If we could do it without getting the user too involved in the camera manipulation, that is key. So perhaps just lock it to like 90 degrees, 45 degrees. It sort of frees them from that constraint and focuses on where you are placing them in the world. > > But also, this landscape, you know its a kind of mnemonic device. So as I get a sense of that landscape, all of a sudden, you rotate it, it looks different to me. The memory that I put in the upper right corner is now in the lower left corner. So that's why I'm a little reticent to go a full 3D, or at least constrain the camera direction. But we can still kind of tilt it back. Get some pitch on it. > > So no rotation, just locked orientation and just have that sort of gradual pitch. We're definitely going to want some amount of zoom. So maybe one of the things we might want to prototype is a world like this where I can now, you know, zoom in, have the camera pitch change with the zoom, pull back out, get the overhead of the map. Then I think we've gone a long way toward establishing kind of the user interaction and the look and feel. Then we'll have to produce at a production level. > > We don't want to spend more than a few days, a week at the most, on prototyping that. And if we had that plus this prototype, now we're well on our way to kind of knowing what's happening in that world, what the affordances are, how the user's picking the camera angle and all that stuff. I don't think it will take too many more prototypes like this to get pretty far down the design tree. And then we can start committing some real resources to this. > [!Abstract]- 13. Playtesting > Well, as you work on a project, in early stages, you're going to want to just get a sense of what does this thing feel like for me to interact with, or the other people on my team, how do we feel about interacting with this very simple little system? > > Sometimes it might now even be a prototype that we made, or it might be a game we pulled off the shelf. What do we like about this game or that game? Those are the cheapest prototypes really, if you can find some other game that has some aspect of what you want to include. Then, as you start buildng something, you start building not just the system, but also the interface, the player controls. > > Typically you'll want to bring in a few people who play games, but they've never seen this, just to figure out the interface. Can they understand the control scheme you've got? Does it make sense to them? Can they understand reading the topography, the landscape? Do they have some sense of what they're supposed to do? What occurs to them as you drop them into this environment? > > So it actually can become a fairly granular process. It's not like we build the game, then start playtesting. It's really like we're building prototypes from the very beginning that we are testing ourselves, and then over time, starting to test little game parts with a few people, here and there. And eventually, we're bringing in larger groups and maybe even at some point hundreds of thousands, capturing metrics and building these fairly complex diagrams of them moving through the game space. > > **Challenge Your Assumptions** > > This is the first time you really have a little bit of a peek into the player's mind about how they're going to interact with this thing that you've built. As a designer, you kind of had this idea all along that I'm going to give them this. They're going to be able to do A, B, and C. They're going to try to get to D, whatever. This is what you're imagining. As a designer I am trying to imagine "what would I enjoy?" "How would I think about this?" But I put it in front of somebody else and right off the bat you start learning things. Then you go back and revisit your assumptions and maybe ask them why. What did they see that caused them to think that way? > > I think that this is where for the first time, the designers are taking this concept out of their head and trying to put it into other people's heads and seeing how it fits. > > **Try "Kleenex Testing"** > > It's frequently very hard to kind of imagine the way other people are going to see or understand what you've made in a game. And there's really no replacement for actually testing it. We did a lot of what we called Kleenex testing, where we'd bring people in who had never seen the game before, put them in front of it with absolutely no instructions, and just watch what they started doing. See where they fail. See what's obvious. A lot of times, it's so obvious to you that they should press the red button. But it will not even occur to them to press the red button. And you sit there and watch 10 people not press the red button, and you start realizing, okay, that's not the typical person's understanding of the way this thing works. > > One very important thing is that we put two people in front of one computer. If you put one person in front of a computer, they'll sit there, but they don't talk. They get very quiet. You don't know what they're thinking. If you take two people- and they have to know each other. They might be friends or spouses or whatever. They'll be talking non-stop. You can sit back and think ok that's how they are understanding the game in front of them. > > After we get the feedback and make the changes, we'll bring in an entirely new set of people who have never seen the game before. They are unpolluted. That's why we call it Kleenex testing. We use the tester once and then throw them away. But there's really no replacement for that and it's amazing as a designer how frustrating, in some ways, it is to sit back and watch these people not do the obvious thing you were sure they were going to do. > > **The Playtesting Process** > > Playtests, usually it's a large room. The designers are sitting back a few feet away. And there'll be five or six different workstations set up. In front of each workstation we'll have two people. Again, people that know each other, friends, spouses, whatever. We put each group down. We give them some very, rough sense. Here's a game about controlling little people, and then we just turn it on. From that point on, we don't say a word unless they have some technical problem. > > They'll sit there as a pair and basically figure out how the game works. Maybe this will make this happen. The designers also, at that point, are not interacting with each other. Typically, this will be a design team of three or four designers, and we're all coming to our own conclusions independently observing this group. > > After it's all over, the desigers will sit down and collate their notes. And then we will come together as a design group and say, what did you see? What were our biggest issues? It will usuallly result in one or two or three things that we all agree on. We all agree it was too hard, or it was not obvious. They didn't enjoy this part. We'll take the three biggest design risks and make them action items. How can we mitigate those risks very rapidly? And we're repeating this process over and over. We're always looking at the top risks. > > **Early vs Late Testing** > > To test the engagement, you have to have so much of the game coming together as a whole. And it's so far down the path that the early testing has really nothing to do with that. The early testing is things like 'do they know how to operate this windshield wiper?' Or that headlight control. That's not going to tell you how well the car drives. As a designer this is where I think your vision has to carry you through. Not just your vision, but your ability to communicate that vision to the other stakeholders in the project. I know that if we can get the windshield wipers working, and the steering, and the brakes then this is going to be a really cool car to drive. > > That is going to really be more instinct and salesmanship on your part as a designer. As you get later on in the process now, and you have your working windshield wiper control, and your steering wheel, and your brakes and all that, now as soon as possible try to get some set of these things working together as a whole, such that you can sit back and see another person actually enjoy it and start building the model and start trying to head for the goals and get that flow state that you're really trying to achieve as a designer. > > **Decipher Underlying Problems** > > When you put a tester in front of a game, they are not going to sit there and tell you exactly what you're hoping to hear. They're having an experience and you can, again, by putting them with somebody else, have them verbalize their experience. But as a designer, you have to kind of decipher that. A lot of times, what they will express directly - they'll start describing solutions to you rather than the problem. You have to distinguish them offering you solutions, what problem does that actually point back to? That's the problem you need to solve as a designer. > > **Separate Signal From Noise** > > Well, when you're looking to playtest, the signal to noise issue really is going to be a matter of substantive data. If you do enough testing with enough people you'll start to be able to distinguish the signal from the noise just because that's consistent. The noise is all over the place, random. But when the same five people are all saying they didn't know to press the red button, but then they give you totally different feedback on everything else, you know that the red button is definitely a signal. You want to listen to what they playtesting groups have in common. Their problems and frustrations. When you compare notes, what problems were all the designers noticing? > > Too often you're expecting your players to be game designers. When a player is describing to you that in their head, if you had a garbage system, it would be so much cooler, they're imagining it a certain way that's probably not the way it works or the way you're thinking about it. But if you could understand why they're saying that, what limitation or failure or flat spot are they hitting that makes them think that their addition would make it better, then that's good. Often times they are telling you to add stuff when it's about removing stuff. > > One of my favorite quotes is about Japanese gardening. Your garden is not complete until there is nothing else that you can remove. > > **Interpret Metrics** > > Engagement is one of those things that has a very wide range. When we initially have prototypes, and we bring players in to try it out, it's more a matter of getting them to stay there in front of the computer. Keep playing, keep playing, keep playing. Towards the end, if you're really starting to nail it, it's a matter of you trying to pull them away from it. > > I think there a couple of very simple tricks. A lot of times when I am showing somebody a game and I'm actually playing it and explaining how it works, if they all of a sudden want to grab their mouse and say, let me try or I see a game somebody is showing me, and all of a sudden, I feel the urge to play, that's a great metric. This starts even before you see somebody playing it. It begins when you see the box and the ad for it. > > Down the road you'll know you've made a great game when the feedback is that people stayed up all night playing your game and forgot about the time. That means you kind of really nailed it. If a player is enjoying it that is engagement. It doesn't have to be challenging to be engaging. > > **Playtesting Sim Earth and The Sims** > > Sid Meier had a great quote. Some games you design for the players and some games you design for yourself. I experienced that, I think, with a game I did way back called "Sim Earth." I got fascinated with building this elaborate model of the planet earth, and the climate, and the oceans. It was a pretty cool little model for its time. Running on a PC it has all these little controls where you could adjust things about the planet. But it was very complex as a model. And I really enjoyed playing with that model. But later I realized as we were putting this in front of players, it was kind of like putting them in the cockpit of a 747 that's in a tailspin, heading to the ground, and all the gauges are spinning. I got really caught up in building this planetary model for myself. I think this really kind of reinforces the idea of testing. As a designer you have to go back to the drawing board when you see people interpret what you've done in a totally different way. > > The Sims is a better example of that, where I was so fixated on the architecture, and then we started putting it in front of a few people and saw how fascinated they were. And it makes sense that they were fascinated, basically messing with these little sims the house was a backdrop for it. It was one of those challenges and became an integral part of the gameplay. But the real focus of the game that the average player came to it was on messing with the people. As a designer you say, I think we really need to focus on that. You should be able to revisit your assumptions when you see people interpreting what you've done. > > **Determine the Best Demographic Fit** > > Whether it's older people or younger people. Once you get a sense of where it's hitting the mark, we can get a little bit more specific about the kind of people we want to bring in. We want to bring in more women, or more young players, or whatever it is. Customization. More personalization. That's something you discover over time. Then as a designer you focus on a path. The demographics are frequently very misleading. > > **Playtesting vs. Focus Group Testing** > > In my experience focus group testing has been pretty close to useless. In some sense you're kind of expecting your players to be designers. When we were describing The Sims to them, I know they could not unpack it in their head and be playing in their imagination the game that I was envisioning. And there was no easy way to communicate it to them. > > **Beta Test at Scale** > > People have different definitions of what a beta test is. You know, in my mind, I tend to think, a beta test is roughly your complete game, with all the components, all the functionality, in it, that you're handing over to people, usually a fairly large group of people, and you're basically confirming that it has the right kind of motivational hooks, the right player agency involvement that you thought it would. Also a much more mundane aspect is you're discovering bugs. Where is it crashing? > > A lot of times when you are beta testing you'll discover things that are a serendipitous upside. Wow, I never thought players would do that. I think the primary purpose of beta testing is testing if your game is behaving the way you thought it would, at scale. > [!Abstract]- 14. Designing a Sound Aesthetic > Sound design is a huge potential force multiplier. Sound design can take a really good game and make it great. If you ask a player why the game is great, they probably won't even tell you it's because of sound design. If it's really that good, it will probably be unconscious to the player. But it's influencing their emotional state. They're actually experiencing the graphics as being better or the gameplay as being better. Everything seems better to them because the sound design is putting them in the right state of mind. > > Sound design is usually the thing that gets the short stick in a lot of game designs. It's kind of like, we know we have to do the programming, we know we have to do the art, the UI, and all that. Oh, by the way, we need to do sound at some point. More and more I think sound is becoming one of the really primary, upfront components, of a lot of games. More and more games are based on music. That's the overt theme of the game. > > I think sound design, if I'm including music as well, is at least as tricky as the art side of things nowadays and at least as rich. > > **Expand the Player's Imagination** > > I think the primary indicator for me as to the quality of sound design is whether I turn the sound off or not. There are a lot of games where it's like, that is annoying as hell. Then I turn it off. Maybe the game is fun and I enjoy the game. But really great sound design is something that I notice. Every now and then, I play a game where the sound design just blows me away. > > There's an old game "Clive Barker's Undying" and you're going through this old house and it's dark. It was a first-person kind of scary game. Most of the sound you would hear doors creaking, the wind, and it was done so well, the blending between the creaking of your footsteps and you would start to imagine all these things in the soundscape that you were about to encounter. They were really tweaking your imagination with the sound design in a beautiful way. Every now and then I see a game that does something like that. > > The sound is really adding a whole level of dynamics to what I'm building in my imagination. That's really an indicator of great sound design. > > **Collaborate With Your Sound Designer** > > Within sound design, there are a lot of components to it. You'll have sound effects within your world. Typically, you'll have music. You'll have a lot of times user interface sound effects, which are very different from the in-world sound effects. Voices, voice acting. So across all these things, you're going to have to have somebody that kind of understands all these components at some level and brings them together. > > From the designer's point of view, the designer can kind of say, I want these things to sound realistic or deep, and I want the interface to be quiet, or I want the voice acting to be like this. That's something where you really need almost a jack of all trades for your main or only sound person. Somebody who's pretty comfortable at doing a lot of different things. > > A lot of games the sound is going to be very localized. Very in the world. These are the objects in the world making noise. As you move the camera around they need to kind of fade up and fade down. A lot of it is very kind of tactical like that. Other time's it's more global. It's like, I want to have this Zen experience. I want to hear this soothing music as I play this. There's a pretty wide variety of approaches depending on what game you're doing. > > The sound director probably has the ability to present you with even more options than your art director. It's pretty easy to quickly prototype these things on the sound side. > > **Make Sound and Art Cohesive** > > I think for the sound to really immerse a player effectively in a game, it has to live alongside the art and even the player interactions. But it has to feel like it's part of the same world. If the sound is cohesive with what you're hearing on the screen, then it comes together. That's when all of a sudden it becomes a real tangible world and I can kind of mentally displace myself into it. I think you can't just deal with the sound apart from the art. The have to basically live in the same kind of universe together. > > What is this world made of? What is the scale of this world? Is it whimsical? Is it serious? Is it spooky? Is it fantastical? There's a style of sound. Also how overt is it? Is this a very foreground sound? Is it a background ambience? Is it something that sounds very consistent through the whole world or is it something that indicates something special here? > > That kind of thing, it's very brittle in a way that if it's a little too much it totally blows it, and if it's a bit too little then you don't hear it. There's a very narrow sweet spot. I think you have to achieve on the sound design, especially when you're putting sounds against each other. On the music side, that is a much more subjective decision I think on the designer's part. > > In spore, we couldn't really have music coming from these little cities that we're supposed to be on different planets playing the same tune. So we took a stab at it. We had a generative music system. We actually had Brian Eno come in and help us design the musical system in "Spore." And he'd been actually doing generative music for many years. My sound designer Kent Jolly was actually coding up these systems that Brian had been doing manually. > > **Build Sound Design In Layers** > > Depending on where the camera is, how high it is above the ground you get kind of different layers of effects that would come in and out. Way up high, you'd get more environmental wind effects. Like you're up in the clouds and as you came in, you'd start hearing things - creatures, people, whatever - moving on the ground, vehicles. If you came all the way down to the ground level, there was another kind of ambience of almost like gravel blowing across the train or wind going through leaves, that kind of thing. But it's actually a fairly technical system and I think more and more of the sound design in games is getting to that level of sophistication. We actually had a whole different sound library depending on what scale you were at in space. > > **Use Timing for Emotional Punch** > > It seems like every game you kind of expect it to have some background song playing. I think that when we watch film and somebody scores a film there typically is, even at a very low ambient level, a little bit of a running film score kind of running through the whole thing. I think it's, in fact, a delicate thing, in terms of how you approach it when you bring it in to a product. > > When I was working on "The Sims," one of the things I really wanted to try - and did try - it was a failed try. But a fun failed try. I wanted to put a laugh track in. I did in fact put a laugh track in during certain things. As I was doing research it turned out to be a secretive thing. There are really only a few people who do it, and they're very secretive about how they do it. The machines they use are custom-built. It surpised me that it was such a black box. For the game it would actually interrupt their stories. That's why we took it out of the game. > > **Fall Back on Humor** > > We'll hit a problem that seems almost intractable. How do we solve this? This is a really messy problem. And so many times we just fall back on humor. The unconscious metaphor we were trying to achieve with the sims is that is a dollhouse. These wanted to be like little, tiny people. The gibberish of the characters supported the idea. > > **Sound Design in The Sims** > > Really the idea was that if you were watching people from a balcony, you couldn't hear what they were saying. You could still kind of get a sense of their emotional state by the way they animate, they gesture, their body language, and the tone of their voice - not what they were actually saying, but the tone. > > I initially brought in a few voice actors using languages that we just were not very familiar with. We first tried Estonian, because Estonian sounds very strange. We actually couldn't find enough voice actors. Then we tried voice actors who spoke Navajo. But that sounded actually a little too American Indian. Eventually we found these two voice actors that were also improv comedians that knew each other. We tried to describe to them what we wanted. They just kind of started speaking this gibberish to each other. It was through the talent of those two actors that we kind of zeroed in on what we ended up with. > [!Abstract]- 15. Pitching Ideas > Whenever I got to the point where I decided, OK, I'm building a game about this, I start imagining "How do I present this idea to other people?" What am I kind of imagining the process to feel like? The activities, the agency I have in this? I'm starting to actually play that game in my own head at a more and more detailed level. While at the same time thinking, "Okay how do I offload or download that play experience into somebody else effectively?" And that becomes part of the pitch. > > **Pitch the Feeling** > > Whether you're trying to communicate your design vision to your team or to executives or to your audience, you need to kind of remember why you want to do it. What got you excited? What is the key thing that's really motivating you? And then you step back and say, OK, how can I recreate that process in that person's head? How can I make them see or understand or feel the way I feel about this design direction? > > And maybe it's not the explicit, overt description of what your game is going to be. Maybe it's more a getting into their head, into the emotional motivation that drives you. And maybe it's more about the creativity you'll have in this, or the expressiveness, or what it's going to feel like, this nostalgic - go back to your childhood playing this thing that you used to play. There might be a lot of directions you kind of take that. But in some sense, like game design itself, you're hacking psychology. You're trying to imagine, what does it take to make that person feel the way I feel. It's almost like reverse empathy -- how do I push my feelings into that person? > > Interestingly, most of the hits I've had -- the really big hits, SimCity, The Sims were the ideas that I got an amazing amount of pushback from with almost everybody I described it to initially. And at some point, I actually had to reformulate the way I was thinking about it to then communicate it effectively. And I did. You know, I kind of thought, OK, what is it about the way I was talking about this thing that's not hitting the mark in their head the way it hits in my head? Eventually, I found ways to actually communicate what I was really thinking, which wasn't an explicit description of the game design, but more the feeling I was going to have playing this game. And if I could now figure out, OK, now how can I make them imagine that feeling? And what do I say to them to make them imagine how it would feel to play this game? So I took, like, one step deeper, really. > > **Pitch Early, Pitch Often** > > Right off the bat, as soon as you think, I have an idea for a game, tell your friends. See what they say. Tell other people. You can just observe and learn from the result from the questions they ask you, what they seem interested in, or what they want to know more about. Or they want to talk about something else. You'll learn very rapidly. Refine the idea. The elevator pitch. Repetition is probably the best idea. > > **Communicate Your Vision as It Evolves** > > Frequently, the game designer is also the person that's trying to assemble the team that's going to build this product. And as you're building that team, one of the very first things, skills- that you really have to have is the ability to communicate your design to your team. And continually, even when you're refining your idea or changing it, you need to make sure the team is aware of that. It's more understanding the direction you're going, not the destination. The first game you are designing is actually the pitch. > > **Adjust for Your Audience** > > If you're pitching to your team members, designers, whatnot, they want to know - they're going to want to hear something that's unique and interesting they're going to be proud to build, and something that's buildable, because they're going to be responsible for actually having to build it, and something that sounds creatively challenging. That's what they're looking for. > > When you're pitching to a big company, take the big hit of last year, and then say it's like that, but better. That's kind of the cliche. One of the most successful genre's in any format is the sequel. If it's an original thing, they're going to basically be measuring against that. Should I invest in this original thing or put more money into the next version of this popular franchise? > > Pitching to a journalist is a whole different thing, they are going to want to write an interesting story, something where they can actually exhibit a fair amount of creativity in their review, or in their writing of it. General media is a different story, for them it's like why does my audience care? People who don't even play games will be interested in this because of X, Y, and Z. > > **Reference the Topic and the Player** > > I found that the more we can reference the player in the pitch, generally the better the pitch went. It's not like, here's a world in which this happens, but here's a world in which you are the mayor, and you get to ddecide where to put the roads, and you get to do this, that, and the other. So if you start to say, these are the things that you can do in the game and make that sound interesting, that kind of reverses the whole thing - rather than here's this thing that I want to sell to you. > > **Anticipate Questions** > > One of the fundamental questions that you're probably going to get, especially if the pitch is very unrefined, is why is that going to be fun? Which is a hard question to answer, because if your pitch really conveyed what it needed to convey, they wouldn't be asking that question. It would already be fun in their imagination. They wouldn't ask you that question. So that really indicates a key part of your pitch that you're missing. > > People will try to trianulate your idea against other games, and they'll say, oh, is it kind of like this game but a little bit of that? Or this game that's turn-based instead of real-time? In their mind, they're looking at the landscape of all the games they know about and trying to figure out where yours falls into that landscape by finding landmarks nearby, saying it's somewhere between there and there. And that's going to be very common. And if your game is not in that landscape, that's both good and bad. It's hard for them to triangulate, because they've never seen anything like that. On the other hand, it could feel fresh if you could pitch it the right way. If they can download why it's different and why that's good, it can be very successful. > > **Pitching Tips** > > In particular, I think you need to feel like your thing, whatever it is, is standing on it's own legs, on it's own merits, and it's not just going to be successful because it's part of this trend that's happening this month. > > Another really important idea is that when you've sold your idea, don't continue and unsell it. It's better to leave a lot of blanks in there. The person you are pitching to will generally fill in the blanks. It's important to realize when to stop. > > **Common Mistakes** > > Do not start with the Genre. By pitching a genre you've already put it into a box in their minds. The other one is people tend to be too verbose. They tend to add way too many details way too early. I think for your pitch, you want to remove every possible word that is unnecessary and refine it down to that level of consciousness. > [!Abstract]- 16. Flooded Market > Game demo shown in the video > [!Abstract]- 17. Choosing and Understanding Your Platform > I think of the technology as just one part of the platform. I think just as important is the cultural platform. What kind of culture? Is this being played in China, in America? Is it being played by serious gamers in Germany? The third being the actual demographic, the person. Is it a very social experience? > > Really we're almost dealing with three platforms here really. There's the technological platform, the cultural platform, and the demographic platform. It's important to understand all three, and I tend to think of all three together as the platform. > > **Platforms are Changing** > > The whole world has changed so much in terms of app markets, mobile, tablets, online. With console development and PC game development the teams were getting larger and larger, and the budgets in the tens of millions of dollars. All of a sudden it looked like we were doomed. > > Now it's totally reversed. Now we're back to where a small group of passionate people can create a cool game on an iPad or whatever, and release it pretty effectively on the app store. Now it's a matter of, you know, press, marketing, and how you actually get people to download it and try it out. > > The dynamics have changed dramatically, and I like that idea just as a design point of view that now I have the opportunity to learn much much more effectively and much faster from our players, and shift directions -- you easily know, pivot very easily. Whereas before pivots were incredibly expensive. > > The fact that the game is becoming more platform independent is very attractive to me as a designer. > > **Consider the Economics** > > I think nowadays we have a much wider range of business models than we used to. It used to be that you basically had to put this thing in a box and sell it for $40. Now we have a wide range of ways. Free to play. Monetize incrementally. Whatever it is. > > From the designers point of view, you fundamentally have to create a compelling, excellent, unique experience. If you really hit that mark, now you have all number of opportunities for monetizing it. I don't think in terms of monetizing it first and now let's design it. I think in terms of "Let's design something that's so damn cool that people are going to want it. And now we have this whole range of ways that we can choose to monetize it." > > **Don't Depend on Platform-Specific Affordances** > > The goal should be that the interface and my agency into the game should be transparent. So if anything actually makes that agency feel more transparent and disappear in my head, fine. I'll use it. Whether it's VR, or whether its accelerometer on my phone, or a joystick on my desktop. I'd say that I would not want to build a game concept that's just built around the accelerometer, for instance. > > Use these things as a way to lower the friction of the interaction with the player. But not something that the game features are totally dependent on. I found that I actually enjoyed racing games on my ipad more. > > **Pros and Cons of Development Platforms** > > PC is more malleable. Consoles are in a lock-step. > [!Abstract]- 18. System Design > Within these games, within these worlds, there are a lot of moving parts, a lot of dynamics. You want this to be a rich interesting environment for the player to explore. My approach has always been to step back and kind of think of this whole thing as a system. What is the system that's happening here? And actually, when you get down to the engineering of things like simulations, you really do need to think of it as a system. And you need to think "What is my paradigm?" "What is the way in which I'm going to structure the world?" "How is it going to operate?" "What are the parts?" "How do they interact with each other?" > > **Systems Define Possibility Spaces** > > Systems are interesting. In some sense what they are going to lead us to is this idea that everybody in a game is going to be exploring the possibility space of that game. What are all the possible states that the world could be in? > > For something like chess, it's fairly obvious, although it's a very big, branching tree. It is a branching tree. Every move in chess leads to another set of possible moves. And you unfold that branching tree of all the possible moves of chess and you come up with an astronomical number, but it's still finite. There are a finite number of possible states in chess. > > The very early games had very simple branching trees, very much like chess. Basically structure branching trees that were basically put there by the designer. And this is very much like one of those choose your own adventure books. You know, if you're going to go into the cave, go to page 7. But, basically the writer is having to fill out every possible branch of that book. So it's a very limited structure, a very limited world to explore. > > Later games started doing what I call gated experiences, a game like Quake or Doom, you're within a level and you have all this agency and freedom within that level, but until you complete the level, basically you're in this little room. A small regional possibility space. Once you get through that, it opens another regional possibility space. So you basically have these little island of possibility space with gates between them. > > Then there have been basic hybrids of these two models over time. But then as designers started building more open-ended simulations, it opened up a lot more. So as we started building open ended games, sandbox games, GTA, Sims, we're actually looking at a possibility space that's vast, large. And this is when we really have to now view it as a system, not as a branching tree of possibility. We're not going to map out every possibility. What we're going to do is build a set of things that interact in a way to generate these possibilities for us. > > For the Sims, the way I visualized it was you basically had two directions that you could go for achievement. You could go for social achievement or material achievement. You could try to make a lot of friends in the Sims, build a big family, have people like you. Or you could try to make a lot of money, buy things for your house, grow, acquire. > > The way I visualized it was almost like a bowling alley. If I went down one path or the other, it was like getting stuck in a gutter. To achieve maximum success you had to balance the two achievements together to get the highest level of achievement, which is right down the middle. We actually mapped these metrics out with 3D visualizations. > > **Understanding Parts and Structure** > > Going a little bit deeper and thinking about "How do we build this?" "How do we think about it?" "How do we engineer it?" I needed to find two things here in the way that I think about them. What is structure? What is something made of? What are its parts? A structure of a tree, it has a trunk, it has branches, it has leaves. Then there are dynamics, this is process, this is what happens over time. In this case it's what can happen to a tree. How does it grow? Can you cut it down? Can you turn it into firewood? What happens over the seasons? Those are all the dynamics of a tree which is very different than the structure of a tree. > > From that, I started imagining the different things I use as a designer to build these systems. And structurally, I basically think in terms of three types of structure. One is what I call agents. These are objects that can move around, interact in a world somehow. Next is networks, these are things that are connected through some type of relationship formally. And it could be relationships. It could be economic. It could be biological. It could be anything. And the last one is layers, and this tends to be more spatial. Something like SimCity, basically, there's the pollution layer, there's the traffic layer. These are things that are specialized. Everything in the game is one of these three things. It's either an agent, a network, or layer. > > In SimCity, the road is a network of intersections connecting areas. Something like pollution, crime, are layers. Cars moving around, people, even buildings are agents, sitting on the landscape with some identity and some parameters. That's kind of the typologies, or the structure, of games, the way I think of systems. > > **Dynamics Create Paradigms** > > When we get into dynamics, within any of these topologies, any one of these dynamics can occur, things like propagation. "How does something spread through that?" Growth, grouping, order, allocation, mapping, specialization, all these are dynamics that occur within these typologies. In some sense, these are now the verbs. The topologies are the nouns that we're building the game out of. These dynamics are the verbs. > > Lastly, how do we think about this? What is our underlying metaphor for bringing these things together? That's what I call paradigms. Initially, there were things way back in the '40s called cybernetics. But really, it was very simple systems, like a thermostat. Originally this was developed for things like autopilot, a very simple machine control. Governors on steam engines, even, are an example of a cybernetic system. But in essence, it's a very simple, little system trying to seek a behavior, seek some set point. It might be temperature, it might be the speed of an engineer, whatever. > > It was only in the '50s when the very first primitive computers started coming around, that the idea of system dynamics came out. A guy named Jay Forrester kind of came up with this concept. It's almost hydrological. It's almost based upon a chemical refinery, in that in system dynamics, you just basically have valves, and flows, and containers. A container might be population, or it might be number of cars. A flow might be birth rate or death rate. And you have little algorithms that will adjust the flows. And he would build these very elaborate models of very complicated systems, things like the world food production. In fact, he was the first person to actually build a city model using this kind of paradigm. > > The next one I'm going to talk about is cellular automata, which really kind of came to its own when PCs were really starting to come out and people had access to cheaper computers. Although, in fact, cellular automata predated system dynamics. Cellular automata are basically the idea that there's a grid and cells. And these cells can either be on or off, or have quantities in them. Basically all the dynamics that are within that are based upon the neighbors and the behavior of the neighbors. > > The simplest example of this is a game called Life. John Conway, a mathematician, came up with this very simple system, and it's a grid. So in Conway's Life, you basically have a little world. It's a grid. Within this grid, every cell can either have one of two states, it's either alive - full, or it's dead - and it's off. Now, the rules for Life basically say that if one cell has exactly three neighbors around it, then the empty cell now comes to life. On the next turn the new cell appears. Now if the existing cell, has two or three neighbors it stays there. If it has less than two, or more than three neighbors then it dies on the next turn. So basically, that's the whole rule set for Conway's Life. > > It turns out that when you turn this simulation on and you put a few cells in there, there's an explosion of complexity. All this stuff starts happening, really unpredictable. Surprising stuff, and people have studied this thing for years. In fact, I taught myself programming trying to program Life and make it faster and faster. > > It turns out when you make certain kinds of shapes, they will unfold exactly the same every time, it's deterministic. But it's all a result of two simple little rules. This is one of the best examples of emergence. Conway, who programmed this, discovered it. There's no way that the could have predicted the elaborate behaviors that were going to happen in this little world based upon those two rules. It just emerges as a result of that. It's emergent complexity. > > So you have this amazingly complex little world, that's emerging out of this incredibly simple little rules set. Somebody asked me recently what my favorite game was and it's Go. The reason Go is my favorite game is because Go has very much the same property. Go has two very simple rules. But yet the strategy of Go is incredibly complex, relative to the rule set. And for me, that's a wonderful aesthetic for game design. > > When it's the simplest set of rules that you can create that leads to the widest range of complexity and the most interesting world that you can explore, with strategy and behavior. > > Cellular automata actually became a key part of SimCity in the way it operates. A lot of complexity of SimCity comes from Conway's game of Life connected to a system dynamics model like Jay Forrester had. Again, Jay Forrester's model was basically, containers with whatever, let's say population. And then little valves that would control the flow rate of different layers. > > Now, Jay Forrester came up with this model, system dynamics, and people started trying to model a lot of different things with it. Back in the late '60s early '70s, there was a group that started building what they called the World Dynamic Model. And they actually started modeling the world economy, food production, population growth, all this stuff to get some sense of where the world was headed. In fact, they started a group called the Club of Rome. There was a very famous book published called "The Limits to Growth" and in that book they were basically showing the results of their growth simulation. They made a few predictions of the world that ended up not happening, food scarcity, climate predictions. What turned out is they looked back at the model and they found that they were off on a few little factors. What was surprising is that, the little bit that they were off led to an incredibly different result than what really happened. That was really our first inkling into what became known as Chaos Theory. > > Chaos Theory, the idea that the initial starting position of something can lead to a totally different outcome if it's just a little bit displaced. A good way to think about Chaos Theory, we have basically chaotic systems and stable systems. All of a sudden Chaos Theory started putting real limits on things that we could predict with simulations. As it turns out things like weather, and economies tend to be chaotic. So even if we have a detailed simulation and we put a lot of horsepower behind it, there's still going to be a very deep level of unpredictability to these kinds of systems. > > Another direction that these paradigms have taken is called Network Theory. A network is anything containing nodes and links. Turns out you can visualize so many things as a network, such as biological systems and metabolic systems. Economics, social systems, all these things can visualized as a network. It turns out that these networks have some surprising properties. Things are just not obvious. One for example, is that all you need is and average of about one connection per node to have a fully connected network. For any sized network. Another surprising result is that for any sized network the distance, or what is termed the graph width, between any two points on this network is almost never more than six steps. This is that Six Degrees of Kevin Bacon thing. > > So these are very non-intuitive things, but actually, as a designer this is part of your language that you can use within your game to build these systems. You can represent any kind of system in your game using multiple paradigms. You can choose which paradigms best suit your game, and this occurs both at the conceptual level, but also at the engineering level as well. > > **Consider System Dimensions** > > So these become a lot of things that I think of as a designer of systems that I use to build games. On top of this, there are also certain properties that I find interesting to think of in terms of dimensions within the system. One is local to global, how much of local effects versus global effects and where do they meet. In SimCity, something like traffic is very local to that one spot on the road. The overall tax rate of the city is global. And there's some things that are kind of in between. What's the police effectiveness within the city? Order to disorder. Things that are very ordered become very predictable, and sometimes you want that in a game. Other things are totally disordered, random, chaotic. Even things like cooperation to competition is a dimension within a game. Sometimes the game can actually shift where sometimes you are playing cooperatively and sometimes you are playing competitively. > > One of my favorite old games is Mule, where you're competing with other players, but in some sense if you don't cooperate with them to some degree the entire colony collapses. I love the fact that the game actually had cooperation and competition in the same game structure. > > **Visualize Complex Systems** > > I tend to be a very visual person. In school, I didn't think math was that interesting at all until, at some point, I started realizing that I could basically turn almost all of math into geometry. As soon as I could imagine it as geometry, I love it and it makes sense and it's totally intuitive to me. The way I visualize things is I tend to try to bring them into the visual realm. There's a certain part of my mind that does very good spatial reasoning. > > As a game designer, I am imagining as a game player when I come into a game. I'm trying to imagine what are the things I could do in this game? How far can I go? How far is that? In some sense, I'm building a map. Not an explicit overt map of the terrain, but a map of my abilities, my agency, my freedom. I tend to always visualize that as some type of topology. If it's a gated experience, maybe with rooms, I see these as nodes with connectors. Even the behavior, what we call phase space in mathematics, can be viewed as a topology. A lot of the really cool work in Chaos Theory has come by visualizing these systems. Collapsing something very complicated into something that you can now view as a picture. > > It's a good lesson for players. If you can take things that seem overly complex at first and make them more visual. So the player can interpret it with their intuition, rather than having to do some more abstract reasoning. You can make something that's very complex actually seem much more approachable. > > **Games Exist in a Networked System** > > We have these things that we can build our systems out of Agents, Networks, and Layers. Layers tend to be more rigid, and Agents tend to be more flexible. Topologies, that we can have a strucutre from these things. These networks are not just within the systems of our games. The overall context of what we're dealing with, the players, the world, the way we distribute and market games, can also be viewed as networks. We have the technology networks of our computers to be connected to the internet, we have platform networks, we have format networks, brain networks, and social networks. These Networks and Systems are not only used in our games and simulations. They can help us understand the world that our games are being played in. > [!Abstract]- 19. Leadership and Collaboration > A design leader on a team can take a number of different roles. You know, they can start the vision for a design. This is where I think we should go. They can be the one initially pitching the team members. "Hey, doesn't this sound cool?" "Don't you want to come build this with me?" At some point, I think if things are running nicely, that's when I start feeling like a traffic cop. Where all the ideas are good, you know, let's do that one now and this one later. Let's combine these two and build a prototype for that. You know, it's more a matter of that. > > Sometimes you do have to get dictatorial, you know, and you have to just kind of put your foot down. A lot of times you'll kind of get stuck in this standoff stalemate, and you just have to make a decision. That's where you just have to go with your gut, your intuition, and your instinct, and say, OK I'm just going to resolve this now. You try to avoid that if you can. At the same time you're not just leading the design of your product. But you're leading the process of your design team. You're telling the design team this is how I want us to resolve disputes. This is how I want us to make creative decisions. You basically establish a process, or an etiquette, some kind of rules of the road for how these design decisions can get made, how you want them to work on your team, what you want the team's philosophy to be for design. I always want to have design spread out throughout the team if possible. > > **Integrate Ideas From Your Team** > > I've been talking about kind of like the design team almost like it's separate from the rest of the team, which it's not. On a lot of larger games that I worked on, we had several people who were purely designers. But everybody on the team was contributing to the design, at some level, any idea could bubble up from anywhere. > > Ideally you'll want to start distributing a lot of the design tasks through the entire team. Because somebody working down here on the sound system, or that guy on the graphics system might have some really creative ideas, and they probably know a lot more about the way a thing actually works, and what you could do with it than a designer might know. As a designer, you want to have a rough idea of how all these things work. But you're not going to have the specialized knowledge of how a particular cell shader might work. > > Ideally you want to find design talent within your team, learn to rely on it. Basically make it visible to other members, so it's not just that person going around somebody's back. You really respect that person's idea and want to go with it. A lot of times people will enter a game team as a programmer, an artist, or whatever, but their real aspiration is to be a designer. That's where they really want to go. If you could help nurture that and help them down that path, one day, you might end up with a great designer alongside you, or competing with you. > > **Collaborate with Living Digital Documents** > > What I usually think of when I hear the word document is something that you write down, print out, and give everybody a copy of it. What I think is typically much more useful in game development is something like a Wiki. Where it's changing all the time to show the current thinking. Because I think even the game design is going to be changing, if not daily, at least weekly. Aspects of your game design are always going to be changing. You don't want everyone on your team to come back to you and say, what's the plan this week? But, as you're making these incremental or iterative changes, you're updating it on the Wiki, pretty consistently, everybody can always go back there and find out, OK, what's our current plan for our animation system? Or this or that? We found that to be pretty effective. > > One thing I noticed when I started doing games. I was writing the manual, doing the art, sound, and all that. Then I started working in small teams, you know. I found that for teams of about 10-20 people we would do about 3 hours of work for every 1 hour we spent in meetings together. As I started working on larger and larger teams, up to 80 or 100 people, it was the inverse. That is obviously top heavy. You're wasting way too much time on communication there. But now we have more and more tools, coming online that allow us to collaborate more effectively with a lot less effort. > > For these documents really, it's more a matter of group memory, you know. That's what a wiki kind of is. If a person has an issue with it they can come to us and say hey, there's a problem with what you decided. Then we kind of revisit it. But you kind of wait for these things to happen and you wait for the team to respect that mode of communication. > > **Embrace Criticism** > > Criticism actually depends a lot on your background. We find the artists on our team are very familiar with the idea of criticism, because they go through art critiques in art school. They're very comfortable with that idea. Programmers are not, programmers hate other people looking at their code and criticizing it. You know, designers tend to be somewhere in between really. > > I would much rather feel like an idea was tested against criticism and survived it, then feel like it sailed through unchallenged. And if somebody comes to me with a criticism of my design, at first I will try to say that "I'm glad you're at least speaking up." And I might disagree. But, you know, in the back of my head it might just sit there for a while. Everybody is going to have the initial defensive reaction to criticism. If you can just kind of take a deep breath, get past that defensive reaction, even to yourself and imagine, OK, well what if that is a good idea? If somebody comes to me with creative criticism, or real constructive criticism, and I eventually do think it's a good idea, or they sell me on it, that's a big process and a big part of it. When somebody's criticizing it, can they present an alternative? Can they say "I think this would be better than that." > > Now it's in a Darwinian process. That's a place I would like it to be. You know, you don't want an idea that is getting through nepotism, or favoritism. If you feel like your idea went there in the Thunderdome and battled the other ideas, and came out the victor, then I think that's a nice way to approach it. As long as you don't end up with a bloodbath of ideas fighting forever. At some point you want to make a decision. You want the team to be happy about that decision as well. > > **Look for Outspoken Collaborators** > > In any type of collaborative endeavor, you want somebody who is not going to be too dogmatic. But at the same time, is going to have a very clear, strong voice for what they believe. They need to be clear about what they believe. Not somebody who, when they really don't like something they just get quiet. I would rather someone, even if I think they're wrong, have them speak up and clearly say what they think. I would rather have people push back on my ideas and do things like that. > [!Abstract]- 20. The Future of Game Design > I think recently, we've seen games evolve in an area that was kind of unexpected let's say 15 years ago, when we had the rise of the app market, and tablets, and smartphones. We're seeing a lot of what I would call interstitial gaming now. These are very short, consumable game experiences on a small screen that I could do in a few minutes on my smartphone. > I've seen some of the most creative games that I have ever seen appearing on tablets. It's actually a really nice format for gaming wherever you want to be. And it's, you know, something that doesn't have the stigma of I'm carrying around a game machine everywhere because they're using tablets for everything now. I think all this has allowed games to reach a much wider audience. It's also allowed diversification and exploration of kind of indie games and new experimental gameplay that probably would not have been economically viable on the older platforms. > **The Rising Potential of VR and AR** > Going into the future, I think, we have VR starting to become more and more accessible. I've played a lot of the VR games, which I enjoy. It's interesting. As immersive as VR is though, it's not the type of thing where I'm going to be up all night like I was playing "Doom" in a dark room for five hours. There seems to be a limited time for everybody, that you can be in that box in that world without starting to feel really uncomfortable. Part of it is the fact that you're totally blocked off from the world around you. There's something kind of inherently disconcerting about that. For that reason, and a few others, I think there's a much bigger potential for gaming in augmented reality. > Games now are without consuming the world around me, are actually placed in the world around me. They have maybe some context even to where I am and what I'm doing. I think that the technology there that I've seen is still several years off. But that stuff is coming at us so rapidly, I wouldn't be surprised if I was seeing some really cool creative stuff in about five years from now, you know as the headsets get lighter, more transparent. > **Intelligent Game Systems** > Alongside of augmented reality, I think that AI, in fact, really is going to make the biggest impact by far. When I say AI, I don't mean intelligent opponents. But an intelligent game system that is understanding the player, watching what the player is doing, what motivates the player, what they enjoy, what they don't like, topics they find interesting, things that it can pull in, other people they might want to meet or interact with on certain topics. > I think that AI moderating either as a game master or even as a game designer can fundamentally alter the landscape of game design. If you could imagine an AI that could actually craft a game uniquely for you, it might be that we all start with the same kind of generic game. As we start playing, it starts learning more about us. There's a great book by Neil Stephenson "Diamond Age" and he describes this magical book, which is in fact a supercomputer that understands this little girl, the world she lives in, the context of her day-to-day life, and starts teaching her, very effectively the skills that she needs to know to survive. I can imagine a game system that sits there and customizes itself to you. > This is extreme personalization - basically. If you had a master game designer sitting over your shoulder very quickly and rapidly iterating, reprogramming the game around you to make it more interesting to you. If an AI could understand you to that degree, it could also find other people that are similar to you and put you in a shared experience. So it could be that it finds what other people have had their game world evolve to fit them in exactly the same way that you've had your game evolve to fit you and all of a sudden but you both in the same game world. There might also be collaborative experiences based upon this kind of an idea where the AI is trying to moderate. We can build an AI that understands the player at a deeply fundamental level the same way a game designer tries to. > In some ways it scares me. I mean, it almost sounds dangerous that, you know, something like that could be so addictive if it was effective. I almost wonder if we should somehow avoid it. I know that if it's possible, we will build it. But I think that more than anything else that is going to be the most interesting, disruptive, fundamentally game changing thing that's probably going to happen in our field. And I think that could happen within 15 years or less. > **An Unpredictable Future** > The most fundamental aspect of the future of game design, is like almost everything else, it's becoming more and more unpredictable. If you went back 100 years ago and asked people what's the world going to be in 50 years, I think they would have given you a pretty reasonable description of the world. If you went to 1950 and asked the same question, they would have been quite a bit farther off. Basically, the future is becoming less and less predictable. > This ties into the basic idea known as the singularity. In almost any dimension we measure humans, it could be energy consumption or population for example, it's accelerating to this asymptotic curve. There are these transformative properties that are approaching so rapidly, and it might be biotechnology, nanotechnology, AI. One of these could rapidly alter the world around us over a few decades. That's an indication that our future is becoming less and less predictable. > **Stay Open-Minded** > Game Design is one of these fields where you're basically committing yourself to lifelong learning, because it's not only so rapidly advancing, but also you have such a wide palette of things you can do within that field. Don't get too dogmatic about any approach, any platform, and philosophy. It's really about being adaptable, and flexible, and open-minded, and looking ahead, not too far, but far enough to get a sense of three-to-five years. Assume that you're standing on shaky ground. The terrain is not so deterministic anymore. That's probably the best advice I can give any up and coming game designer right now. > [!Abstract]- 21. Final Thoughts > I hope from this point on you'll go out into your field, whatever that is, and use these new tools in your toolbox to do something maybe a little more outside your own box, and create things that even surprise yourself. Really more than anything else, I'm looking forward to the games that you'll create. The generation that's creating games now has so many opportunities, and the things I'm seeing come out right now are amazing. I really just want to sit back, have a comfortable retirement, and play these cool games that I only right now can imagine but I know that one day you will make as designers. > > The possibility space for your next game is huge. So find something you're passionate about and start exploring. Remeber look around you. Your next idea may be lurking somewhere nearby, waiting for you to catch it. --- ### **References** [MasterClass | Will Wright Teaches Game Design and Theory](https://www.masterclass.com/classes/will-wright-teaches-game-design-and-theory)