Has it really been 6 months since I posted here? My concept of time has been simply mad this year.
A couple of hiatuses from, and subsequent returns to, game design, have lead to a crystallization of my thinking on the process. I find I'm less inclined to go down poor paths, to flesh out ideas that aren't workable. My instincts for good and bad designs are growing more keen, and I can bring them to bear on less well-formed designs. I was attempting to pin down what exactly the insights are, but they're slippery. Here's a start:
- Don't fall in love with engines. I sometimes figure out a conceptual way that certain game entities might interact, creating an engine that the player can influence. This is a bad starting place for a design, and placing such a mechanism first is going to put you down a design path that is unlikely to actually be fun, and will to tough to deviate from mentally. This was the biggest problem with much of my early designing.
- What is the challenge structure? This is the biggest insight I've had, is to ask this. Challenges, as I think I discussed in a previous post, are at the heart of interesting gameplay. When the player sits down, what challenges are presented to them? Ask this of any new design you have, if you don't have a good answer, work on the idea until you do. If you still can't solve it, its not a good design.
- What is the simplest version possible of this game? God, this exercise is useful, this is a great way to judge the early viability of a game.
- What are the first two sentences you say to a new player when you sit them down to play this game? Imagine you are just sitting down to play this game, and it is being explained to you, is it something that you want to play? This is an important step-back method later in the process, when you're trying to sort the details out. Is there a core way to explain the game to someone new that is understandable (grokable even) and appealing? So often you wander from the core of what you wanted to do in a game, get so excited about some mechanism that its become impenetrable to the new player.
I think games need to be constructed in layers of elegance, and that this can be detected by the way that a new player perceives the game. Is there a quick, high-level picture of what the game's about? Does the rest of the stuff fall under that as reasonable extensions of the initial principles?
My point is, a teachable game is a good game. The more easily players can internalize the logic of your game, the sooner they can get to the business of playing it. Thinking about how you would present the game as it currently exists is a valuable exercise in the quality of the design.
---
This is all to say these are techniques for seeing your game in terms of the experience it provides, rather than the makeup of its parts. And this doesn't mean the decisions that are presented, or the per-turn nuances that you're trying to create: that's the sort of stuff you think about naturally while you're designing. The challenging part is to see the big picture, to see if all that stuff is adding up to a game.
Because honestly, usually when you take a stab at the detailed mechanics of a game, you're going to end up with ones that just don't work. Its such a fragile, fickle, brittle, wicked thing, game design, the low level stuff you create that seems good in isolation just rarely works in the broader context. The trick is to recognize that early on, and try again, and again, and to keep your searches shallow and your process broad. When you dive too deep into a given mechanic, and invest too much time into it, and allow too many assumptions inherent to it to calcify, you've ruined the entire design for yourself. You're no longer able to throw it away and try something else, it has crusted into place around the rest of your design the two have to live or die together. So they die.
---
So yes, this is all a bit dramatic, mostly for effect. Of course generating ideas is good, as is exploring them, falling in love with them, honing them and being patient. Finding elegance is hard work. But I rant like this because I think that the other side of the coin is easy to ignore, especially for the novice designer (like me, still, to be honest). Of course, yes, you can throw ideas away, and good designers do. But my point is, its harder than you think, and hard work and focus on a given idea that shows promise is not always the right course of action.
--
This ties into two general design theories that have come into focus for me this year, that I will allude to just briefly here:
1) Design is about creating approximations of the outcomes and experiences that you expect your design to lead to. You need to create sketches, models, mental simulations, actual simulations and other approximations of your design, and see how they fare in approximated practice. This is tough in board game design, where the actual experience is borne of the complex unknowable interactions of mechanics and human minds, but the tips I mention above are a start.
2) There are special challenges when you are designing information-based products such as software and board games, when you are creating not a physical object but a system of rules and ideas. In these cases, too much depth early on is a death stroke. Its as if your first step in designing a building was to lay down a huge iron column and decide what to do from there (with apologies to Christopher Alexander).
Here's the myth about software design and board game design: that mental design decisions are wholly malleable. The ideal is that you just think about stuff, and if a given solution doesn't work, well, you'll just try something else. You won't.
Once you've thought about a given idea in enough depth, put the effort into developing it, gotten used to thinking about certain idea's you've developed as givens and constraints to work around, they become solid. They become as solid as if you'd physically started building something.
What you need to do in board game design, and software design as my ongoing research is trying to prove, is take lots of little stabs at the problem. Explore it from a variety of angles at minimal depth, and slowly work your way in. The preliminary work on one angle will provide the means to understand the other angles, and as long as you don't go deep on one too early, you won't lock the whole thing up and ruin it.
Some of the tips I mentioned above are towards this aim. You think about the challenges, the simple version, the explanation of the game. They yank you out of your current angle, show you the others, show you where they clash. And if you're lucky, you can try to build an elegant solution that involves the shifting of all of the angles' needs, instead of building them around one big calcified spike of an idea that you're just too attached to.
---
Again, I know, this is all very dramatic. The idea of spikes you can't move, of all these angles, of clawing your way back out of your ideas? Its only to draw contrast to what you might think about game design.
Every idea you generate is a double edged sword that represents progress in one direction, but resists deviations from that path. Its a fortress. You've staked out a space, and now you can use it, but if you try to uproot it, it will bristle with crossbows from palisades. Build little outposts on the landscape, but don't let any of them get so strong that they defy you.
Edit: added 3rd section as something of a response to Chad's comment - thanks Chad!
Showing posts with label Design Theory. Show all posts
Showing posts with label Design Theory. Show all posts
Monday, April 13, 2009
Monday, August 11, 2008
Victory Conditions
How do I see myself succeeding at this game design game? I'd like to create something playable; something fun. I see three main ways this might be achieved, three kinds of games, or more accurately three kinds of game designs, that might forge that path.
1. The real game. The traditional-sized, fairly complex game that doesn't reinvent the hobby, but that I just happen to make better than average through some effective designing. This is the hardest to accomplish, the hardest to prototype, and the most daunting to playtest.
My Examples: Pirate coop, nearly every early game I designed
Real-World Successes: Puerto Rico, Arkham Horror, most games.
2. The simple game. Sure its not the best game you ever played, but its an illustration of a clever mechanic or interaction, and it was obviously designed as a "small" game. Pet games might use cheap components, or existing components like traditional dice or cards, piecepacks, or minimal custom decks. Can seem unexciting, but are far more feasible to prototype and play.
My Examples: Several designs, tellingly though, few that get talked about here.
Real-World Successes: Many public domain games, many cheapass games, card games such as 6-nimmt and rage, For Sale, many smaller Knizia games.
3. The innovative game. Take a simple idea and make it fly, providing something really new, without necessarily recombining things that you'd seen in the past. This best explained through:
Real World Successes: Apples to Apples was able to go with nothing but a decko f words and like 3 rules to create gameplay. Tales of the Arabian Nights brought the book of tales concept to its full height (and most of the rules they added afterwards really weren't necessary). Finstere Flure built a simple set of rules around the idea of an autonomous monster, Roborally added some (too many, perhaps) rules around the basic notion of prealigning moves with a card each. Magic obviously blew things up with its collectible notion (though the game itself is one of the most complex around if you really get down into it).
The real game is the hardest to create, the hardest to work with, but its easy to slip into. I often start with something simple or innovative, and I really like it. But it doesn't quite work, and I can't quite get it to come together, but I liked the original idea enough that I can't really let go of it. Soon I've painted myself into a corner, and don't know it, or cling onto the idea anyway. Making a real game work requires, as I've described recently, resources and/or bravery that I currently don't have, and rather than fight it, I'd like to satisfy myself with smaller designs for a while. So, how to proceed.
1) Accept the growth and go ahead and try to make the "real" designs that start to emerge work.
2) Show more discipline in keeping ideas simple. Easier said than done, but something I'm working on.
3) Generate more simple ideas, creating a large number of them, and not getting too attached to any one.
This last one is where I'm going with all this. It seems a little unintuitive, essentially a strategy of quitting. To explain: I think its far, far too easy in design in general, and game design in particular, to get hung up on a given idea, work out some additional rules/constraints/decisions to make it work, get locked into those ideas, and find yourself in a failing state in the space of possible designs, without the will/wisdom/wherewithall to know how to salvage what was working. In fact, in the midst of working on a given idea, I'd say its nearly impossible to even throw away everything other than the core idea and try a different direction on it, let alone retreat to a more complete, later, partially successful state.
But that idea was good - what's needed is a way to keep it, but to get a clean conceptual start on it. I wonder if rather than hashing out a single idea, it would be wiser to create a large number of ideas, take a stab at working out each, but then log them, move on, and use the time working on newer ideas as a palette cleansing period to take on those that have fallen by the side.
Perhaps I'm not succeeding in explaining the motivations behind this process, let alone the process itself. But I want to find a way to:
1) ride that enthusiasm of an idea, which is fun
2) explore it a bit
3) but not keep pounding on it until its broken
4) find away to return to it later
In short, going a bit more breadth first with my design process for a bit - increasing my chances of keeping the core good ideas straight and sticking to those simple and innovative games without letting the need to make them work distort them. This might involve a more rigorous approach to my sketchbooks and filing, or might emply this blog somehow. We'll see.
1. The real game. The traditional-sized, fairly complex game that doesn't reinvent the hobby, but that I just happen to make better than average through some effective designing. This is the hardest to accomplish, the hardest to prototype, and the most daunting to playtest.
My Examples: Pirate coop, nearly every early game I designed
Real-World Successes: Puerto Rico, Arkham Horror, most games.
2. The simple game. Sure its not the best game you ever played, but its an illustration of a clever mechanic or interaction, and it was obviously designed as a "small" game. Pet games might use cheap components, or existing components like traditional dice or cards, piecepacks, or minimal custom decks. Can seem unexciting, but are far more feasible to prototype and play.
My Examples: Several designs, tellingly though, few that get talked about here.
Real-World Successes: Many public domain games, many cheapass games, card games such as 6-nimmt and rage, For Sale, many smaller Knizia games.
3. The innovative game. Take a simple idea and make it fly, providing something really new, without necessarily recombining things that you'd seen in the past. This best explained through:
Real World Successes: Apples to Apples was able to go with nothing but a decko f words and like 3 rules to create gameplay. Tales of the Arabian Nights brought the book of tales concept to its full height (and most of the rules they added afterwards really weren't necessary). Finstere Flure built a simple set of rules around the idea of an autonomous monster, Roborally added some (too many, perhaps) rules around the basic notion of prealigning moves with a card each. Magic obviously blew things up with its collectible notion (though the game itself is one of the most complex around if you really get down into it).
The real game is the hardest to create, the hardest to work with, but its easy to slip into. I often start with something simple or innovative, and I really like it. But it doesn't quite work, and I can't quite get it to come together, but I liked the original idea enough that I can't really let go of it. Soon I've painted myself into a corner, and don't know it, or cling onto the idea anyway. Making a real game work requires, as I've described recently, resources and/or bravery that I currently don't have, and rather than fight it, I'd like to satisfy myself with smaller designs for a while. So, how to proceed.
1) Accept the growth and go ahead and try to make the "real" designs that start to emerge work.
2) Show more discipline in keeping ideas simple. Easier said than done, but something I'm working on.
3) Generate more simple ideas, creating a large number of them, and not getting too attached to any one.
This last one is where I'm going with all this. It seems a little unintuitive, essentially a strategy of quitting. To explain: I think its far, far too easy in design in general, and game design in particular, to get hung up on a given idea, work out some additional rules/constraints/decisions to make it work, get locked into those ideas, and find yourself in a failing state in the space of possible designs, without the will/wisdom/wherewithall to know how to salvage what was working. In fact, in the midst of working on a given idea, I'd say its nearly impossible to even throw away everything other than the core idea and try a different direction on it, let alone retreat to a more complete, later, partially successful state.
But that idea was good - what's needed is a way to keep it, but to get a clean conceptual start on it. I wonder if rather than hashing out a single idea, it would be wiser to create a large number of ideas, take a stab at working out each, but then log them, move on, and use the time working on newer ideas as a palette cleansing period to take on those that have fallen by the side.
Perhaps I'm not succeeding in explaining the motivations behind this process, let alone the process itself. But I want to find a way to:
1) ride that enthusiasm of an idea, which is fun
2) explore it a bit
3) but not keep pounding on it until its broken
4) find away to return to it later
In short, going a bit more breadth first with my design process for a bit - increasing my chances of keeping the core good ideas straight and sticking to those simple and innovative games without letting the need to make them work distort them. This might involve a more rigorous approach to my sketchbooks and filing, or might emply this blog somehow. We'll see.
Saturday, December 15, 2007
Flexibility in Representations / Racetrack Design
I've been sketching lots of maps for the Pirate Co-op game, just trying to get a feel for the design space. But it occured to me it would be really nice to have a way to be really flexible about this, to have a physical map that could be readily rearranged during playtesting.
Heroscape tiles might be nice if we ended up with a hex-based game (this is still not certain, believe it or not!). But just starting with a map with a blank grid, and then placing island / trade route / dangerous seas tiles on it could work too. Its strange, I assumed we would have a printed map, but there's really no reason that must be the case, especially not during playtesting.
-
The concept of a flexible, intermediate representation of design ideas is something that I've been thinking about a lot. When you're designing, its often a matter of finding a medium that reflects the properties you're looking for and then:
1) creating a representation of your ideas in that medium
2) evaluating that representation to see if it has the qualities you're looking for
3) adjusting or creating a representation based on what you saw
Ideally, you end up in Schon's of Reflection in Action, where this all happens as a unified, creative thought process, where you're evaluating as you create.
So, you want a representation that is easy to create, but that tells you what you need to know. These are the two steps I've always focused on when thinking about this stuff, ignoring that third step of adjusting course. Maybe that's because most of the books I've seen on this subject focus on sketching, where you usually make sketch after sketch, rather than trying to adjust a previous drawing.
But what about a representation that lends itself to changing its configuration? That is, rather than sketching map after map, should I be creating a physical set of objects that can be nudged around as I see fit?
-
So I was already thinking about this a bit, but what prompted me to post was seeing this show about a guy who designs racetracks. They had this footage of his studio, and I immediately started to wonder, what sort of representations would you use for this? As he pointed out, you need to consider making the course challenging to drive, interesting to watch, you need to work with the topography of the land. They showed these drawings of course layouts, but I didn't see how you could get to those just by drawing squiggle after squiggle and saying 'that looks like a good one!'
About 5 minutes later, I wasn't disappointed. They had built a topographical model of a location out of layers and layers of cardboard, and were using pins with yarn between them to lay out possible course routes. They had multiple routes in different colors, and when one guy placed this red segment, they talked about how it had this nice drop down the hill, and how the cars would really fly down it given the angle and the speed they would have. How cool is that?
The lesson I got from this was how to build prototypes so that you can readily adjust them as you're playtesting. More specifically, don't assume that the approach you're going to use in the final game is the approach you have to use for a playtest: even if you plan to use a static map in the end, tiles might do you good in the meantime. For reasons I won't get into here, I firmly believe playtesting is one of the only good ways to get feedback about a board game design, and ensuring that third "adjusting" step is as easy as possible seems like a good idea.
Is this obvious? Maybe? Its something I overlooked though, and it seems like an observation worth holding onto.
[Finally started adding labels. Will maybe go back and add them to the old ones some day.]
Heroscape tiles might be nice if we ended up with a hex-based game (this is still not certain, believe it or not!). But just starting with a map with a blank grid, and then placing island / trade route / dangerous seas tiles on it could work too. Its strange, I assumed we would have a printed map, but there's really no reason that must be the case, especially not during playtesting.
-
The concept of a flexible, intermediate representation of design ideas is something that I've been thinking about a lot. When you're designing, its often a matter of finding a medium that reflects the properties you're looking for and then:
1) creating a representation of your ideas in that medium
2) evaluating that representation to see if it has the qualities you're looking for
3) adjusting or creating a representation based on what you saw
Ideally, you end up in Schon's of Reflection in Action, where this all happens as a unified, creative thought process, where you're evaluating as you create.
So, you want a representation that is easy to create, but that tells you what you need to know. These are the two steps I've always focused on when thinking about this stuff, ignoring that third step of adjusting course. Maybe that's because most of the books I've seen on this subject focus on sketching, where you usually make sketch after sketch, rather than trying to adjust a previous drawing.
But what about a representation that lends itself to changing its configuration? That is, rather than sketching map after map, should I be creating a physical set of objects that can be nudged around as I see fit?
-
So I was already thinking about this a bit, but what prompted me to post was seeing this show about a guy who designs racetracks. They had this footage of his studio, and I immediately started to wonder, what sort of representations would you use for this? As he pointed out, you need to consider making the course challenging to drive, interesting to watch, you need to work with the topography of the land. They showed these drawings of course layouts, but I didn't see how you could get to those just by drawing squiggle after squiggle and saying 'that looks like a good one!'
About 5 minutes later, I wasn't disappointed. They had built a topographical model of a location out of layers and layers of cardboard, and were using pins with yarn between them to lay out possible course routes. They had multiple routes in different colors, and when one guy placed this red segment, they talked about how it had this nice drop down the hill, and how the cars would really fly down it given the angle and the speed they would have. How cool is that?
The lesson I got from this was how to build prototypes so that you can readily adjust them as you're playtesting. More specifically, don't assume that the approach you're going to use in the final game is the approach you have to use for a playtest: even if you plan to use a static map in the end, tiles might do you good in the meantime. For reasons I won't get into here, I firmly believe playtesting is one of the only good ways to get feedback about a board game design, and ensuring that third "adjusting" step is as easy as possible seems like a good idea.
Is this obvious? Maybe? Its something I overlooked though, and it seems like an observation worth holding onto.
[Finally started adding labels. Will maybe go back and add them to the old ones some day.]
Thursday, August 16, 2007
The Euro RPG
I've worked out the begginings of a list of attributes for Chad's suggested approach to the drawing game. Perhaps I'll post it here for discussion in a bit.
On the subject of RPG's, one more time, I've been considering how RPGs, at least as I know of them, have been distinctly American.
That is to say, in the American tradition of fringe board games, often wargrames and fantasy games, there is an emphasis on ensuring that every case is covered, usually by piling on rules as needed. Meanwhile, Euro-style games demonstrate an efficiency of rules, even if this means streamlining away certain choices or themes.
Its strange to me the way that every RPG I've come across (and I've seen my share, just as research, if nothing else) is distinctly American-style. To some extent, in a game where any action is supposed to be possible, and you are up against a subjective game master, having rules for every case doesn't seem like such a bad idea. But there is this weird lack of:
- Efficiency in rules
- A willingness to allow for abstraction and improvisation
- A willingness to adopt an elegant solution that might provide slightly less realistic results
- Challenging, subtle decision-making during combat or other moments of crisis
There's a couple counter-examples: the luck-point system in Battlestations, and some improvements in 3rd edition DnD, but its not great out there.
The assumption in RPGs, shared with many 80's style American games, is that you want answers, even if the game's willingness to provide them hinders smooth, elegant gameplay. The fact is, I want a system where I can keep every rule in mind, without ever having to refer to a book or chart. If anything has been guiding my design process, it is that I don't want you to have to ever stop playing the game to look something up. Such moments are killers of board-game sessions, and I don't think RPG sessions are any different - RPG'ers have just come to accept them.
No! I say.
Maybe this is all nonsense to anyone who hasn't given any thought to RPG design, I reckon its an especially esoteric interest. Just to entice said folks, possible upcoming subjects:
- The pass-your-hand mechanic: its alure and pitfalls
- Scoring card/tile configurations: Rummy vs. Koi Koi vs. Scrabble
- A rant about shallow fantasy sports systems
On the subject of RPG's, one more time, I've been considering how RPGs, at least as I know of them, have been distinctly American.
That is to say, in the American tradition of fringe board games, often wargrames and fantasy games, there is an emphasis on ensuring that every case is covered, usually by piling on rules as needed. Meanwhile, Euro-style games demonstrate an efficiency of rules, even if this means streamlining away certain choices or themes.
Its strange to me the way that every RPG I've come across (and I've seen my share, just as research, if nothing else) is distinctly American-style. To some extent, in a game where any action is supposed to be possible, and you are up against a subjective game master, having rules for every case doesn't seem like such a bad idea. But there is this weird lack of:
- Efficiency in rules
- A willingness to allow for abstraction and improvisation
- A willingness to adopt an elegant solution that might provide slightly less realistic results
- Challenging, subtle decision-making during combat or other moments of crisis
There's a couple counter-examples: the luck-point system in Battlestations, and some improvements in 3rd edition DnD, but its not great out there.
The assumption in RPGs, shared with many 80's style American games, is that you want answers, even if the game's willingness to provide them hinders smooth, elegant gameplay. The fact is, I want a system where I can keep every rule in mind, without ever having to refer to a book or chart. If anything has been guiding my design process, it is that I don't want you to have to ever stop playing the game to look something up. Such moments are killers of board-game sessions, and I don't think RPG sessions are any different - RPG'ers have just come to accept them.
No! I say.
Maybe this is all nonsense to anyone who hasn't given any thought to RPG design, I reckon its an especially esoteric interest. Just to entice said folks, possible upcoming subjects:
- The pass-your-hand mechanic: its alure and pitfalls
- Scoring card/tile configurations: Rummy vs. Koi Koi vs. Scrabble
- A rant about shallow fantasy sports systems
Monday, July 16, 2007
Mistake 2: Monsters in the City
So this isn't actually a continuation of the big theory described below, just a side philisophical point that was occuring to me today. I was thinking about premises for 2-player games and happened upon "monsters attacking a city" from my 100 adventurous themes list. I've dismissed this idea in the past, the problem being that everyone wants to be a monster, and its really a matter of monster vs. the city, not monster vs. monster. In short, its not a theme thats really that compatible with player interaction. But in a 2-player setting, we can have an asymetrical game of monster player vs. city player, and that might actually work.
But the important thing is, it reminded me of my first attempt at designing a game about this theme. A couple years ago I got this vision in my head of a game where players monsters and can destroy buildings, knocking them over into eachother, causing some to explode, potentially causing chain reactions. Stuff flying all over the place. I then proceeded to design a terrible game around this premise. I added army units that each player also had a complement of. Players would choose move cards that let their monsters and armies do special things. A variety of scoring systems were thrown at it. In the end though, the whole thing was terribly fiddly and arbitrary. It would be a game I would hate to play.
Worse still, I didn't detect the problems with the game early on, and spent far too much energy in a fruitless direction. I ended up mocking up boards and pieces in Illustrator so I could simulate movements, and even wrote a simple card shuffling and dealing java app for handling cards.
I'm not saying I necessarily regret the effort, but it was a lot of work, and the only payoff it yielded was in lessons learned. I think I'm finally ready to learn those lessons. Where did I go wrong in that game?
Goals and Outcomes
I think a lot of your success in design relies on your goal setting, on the qualities you use to guide your idea generation and selection. In board games this is tricky. Your goals are usually on the order of the game experience you want to create, either in terms of tension, socialization, enacting a given theme, creating an envisioned situation, etc. Your ideas are usually on the order of specific mechanics, rules, cards, physical components - the elements that make up an actual game design.
The problem is, outcomes in board games are usually emergent: they are the result of several, subtle interacting ideas. If a game has tension, that might be the result of some finely tuned interactions between the actions players can take and the victory conditions. If a game really captures the feel of exploring a haunted house, that might be the result of streamlined mechanics, well-designed physical components, well-considered card designs and an objective system that drives players to play in the "right" spirit for the game. So you have to come up with ideas that mesh together well, and that serve a variety of purposes.
And there are so many ways that an outcome can fail. If the strategy is too obvious, if there isn't enough player interaction, if there is too little control, if the rules are too complicated, if the pieces are too fiddly, if there is a runaway leader, if the game takes too long, if the game is too physically bulky, etc etc etc: then that kills the design. So you're trying to meet these emergent outcome goals, while ensuring that you don't fall into one of dozens of pitfalls.
In a way, you have this idea, and you're just trying to get some approximation of it out there without falling into some pitfall. (I see something similar in software design, and I find myself wanting to refer to them as "negative design fields". I think it is an artifact of having an information-based product.)
So what does all this have to do with my old Monster game design? I didn't have good goals. My goal was to enact a particular sequence of game events, and I met that goal. The problem was, the resulting game was not any fun.
On some level, I need to consider the player experience when you're designing a game. I can't get wrapped up in some vision of the board, or the way the pieces move around, or the situation that I want to create. At the end of the day, what you are creating is an experience, and you need to have goals that reflect that.
Now, its tough to just keep in mind "I want my players to have a good experience" and expect that to guide you towards good designs. Rather, there are some subgoals that I think you can keep in mind.
I've begun to develop a series of "step-back exercises". There's nothing formal about them, they're just patterns I've noticed in my own thinking that demonstrate a tendency towards giving me insight and getting me past blocks. And from them, I've started to hatch some goals and ways of thinking that will help to ensure that I can work my way towards successful designs, without falling into problems. In a way, I think a way to be successful in game design is to flit between different perspectives, ensuring that you don't paint yourself into a corner. If you can sense problems of a given sort developing early, you can prevent getting yourself into a dead end that will be psychologically disheartening, if not cognitively impossible, to back out of.
Here's and early stab at goal-based approaches that I've found useful so far:
Component Reality Check
This was the first one I started with, back in the day, which I suppose says something about the sort of bloated designs that I made back then. Basically, when I sense that I've reached a certain critical mass on a game's component, I list them out and imagine whether they seem reasonable laid out on the table or as a manifest for a mass-produced game. Sometimes this is relative - if the gameplay is fairly light or if each game is pretty quick, it seems silly to demand a lot of component, either just in terms of setup time or (eventually) the marketability of the game relative to the cost of production.
I think in the past I was a bit to lax with this in the past, but then my focus has been on cleaner designs lately, and generally more disciplined. Beyond setup time and production, I think this can be a warning sign that your design is getting inelegant, as you tack on a deck of cards or board to track values. Ensure that all of the physical elements of your design are pulling their weight, and you might get some insight into your conceptual efficiency as well.
Explain this to a New Person
This is another simple one that I've increasingly used lately. Too often I accumulate assumptions about how things should work, check them off as solved and spend hours trying to mentally tackle the remaining issues. I start rearranging the established stuff to fix the problems with the remaining stuff, shifting pieces around in response to local threats, sort of stepping my way through things. Its like trying to solve a sudoku puzzle by slamming in a bunch of numbers and trying to spot-correct the inconsistencies: you end up chasing your tail. Sometime's I'll feel like I have just one more issue left, but when I look at the finished product, its a mess.
I've found the problem is an inability to design with the gestalt, the elegant whole of the design, in mind. This is no small challenge. But something that helps is envisioning myself trying to explain the design, as I have it so far, to someone who knows nothing about the game. I try to imagine what their reaction is likely to be as I progress. Are they nodding and following the logic of what I've said thus far, or are they getting overwhelmed with ambiguities, details or exceptions? For the parts that are still difficult, how might I more elegantly explain them.
On the surface, its important that players a game understand it easily the first time they play it. But I also think there is a connection between the initial understandability (or explainability?) of a game and its overall playability. Sure, there's many a game that seems easy once you get the hang of it, certainly and defininitely granted. But the game that you immediately understand usually remains understandable (though there is the issue of strategic confidence, which I get into below). I find taking this step helps me get my head around the state of the design, where it's straining, where there are details that I might need to prune. Performing this step a little earlier in the process seems to be helping me back out of directions destined to spin into unworkability.
Interaction Checks
A more recent, even nacent, approach. I realized that too many of my designs were basically focused on creating interesting sets of interacting mechanics that the players' actions were variables in. Or I effectively came up with an interesting, puzzley situation and allowed multiple people to participate in it. But I believe that the heart of a good game is very often in its ability to provide a medium for compelling interactions between players, and this will rarely emerge on accident.
In short, I've started to focus my design process on player interaction. This has primarily manifested itself early in the process, as a way of evaluating initial designs or thinking of direction to take a given theme. In short, if you aren't going to have an interesting interaction mechanism, your design's liable to be doomed. Games are much more interesting when your ability to pull off your plans depends on your opponent's actions, and when your goals must be balanced against efforts to thwart those of your opponents. I think explicit focus on this aspect of a design will do me good.
Fundamental Decision Structure
This sounds fancier than it is. Somewhere in the back of my mind there's a model of the decision trees that players face over the course of a game, and which are more appealing than others. But in the meantime, I've started using a basic version of this concept to evaluate the experience provided to players. After all, its a player experience you're really hoping to create, the game is just the means.
During a game, a player will be faced with a large number of decisions. In most games, there are certain patterns that govern these decisions; each decision is unique, but they are of certain constant types. For example, in backgammon your decisions revolve around which pieces to move with your roll for the turn, and possibly how to handle doubling decisions based on board evaluations. In Puerto Rico, you are looking at questions of role selection, as well as decisions within role-turns, such as which boats to ship on, where to place colonists, and what buildings to buy.
The issue is, which of these kinds of decisions are fun? I think there is some value in Knizia-like designs, where the the player has limited options at any given moment, but where the implications of those decisions are sublte enough that choosing between them is difficult. I think games where you have a great many decisions can be ok, as long as you can categorize them as being productive to your goals or not, and quickly prune your search to those that you're interested in. For example, there's a veritable ton of things you can do on a turn in Arkham Horror, but you generally end up deciding between a few, reasonable alternatives, as you take advantage of the opportunities the game presents you.
This approach is really about avoiding pitfalls. For one, there's analysis paralysis. If you give the players a ton of information to work with, and a ton of choices, trying to find the best one can be daunting. For example, imagine that on a player's turn of Carcassonne they received 4 tiles from the player to their right and one from the stack. They played one, and passed the other 4 to the left. Sure, the game might be more strategic, but the enormous number of options it opened up would mostly just grind the game to a halt. Players would have to look at tons of possible plays, and also worry about what they were giving their opponents. Downtime would increase, and I reckon it would often just give players a sour taste of feeling like they missed the best move. The same goes for playing Metro where you can play tiles in any direction, or games where nearly-un-memorizable past information is kept open for people to consider.
On the other hand, there's the problem of lack of control. If a player's decisions don't affect their chances of success in remotely predictable ways, they're likely to see the whole exercise as not worth thinking about. This is often manifested in terms of large amounts of luck or hidden information, but it might just be an issue of the complexity of the system in which the players are working. I find the initial chaos of a game of Tigris and Euphrates to be daunting to this day.
What it comes down to is, what is the basic decision you are asking the player to make, and does this represent a fun challenge, or at least a means to exert control over the game situation? This is about as close as you can come to the question "is the game fun?", at least from a purely mechanical standpoint. Or at least, recognizing this aspect of a given design helps me to avoid situations where I've managed to simulate something, or even create an interaction, where the basic activity of playing the game just isn't any fun.
Side Note
I might be hatching a new theory here, where a game is essentially decision structures, interaction structures and theme. That is, enjoyment from puzzling out answers, enjoyment from interacting with others, and enjoyment from the story told by the events the game simulates. I'm not sure if that's a complete list, or if there's an elegant way to encapsulate them, but they seem related somehow.
But the important thing is, it reminded me of my first attempt at designing a game about this theme. A couple years ago I got this vision in my head of a game where players monsters and can destroy buildings, knocking them over into eachother, causing some to explode, potentially causing chain reactions. Stuff flying all over the place. I then proceeded to design a terrible game around this premise. I added army units that each player also had a complement of. Players would choose move cards that let their monsters and armies do special things. A variety of scoring systems were thrown at it. In the end though, the whole thing was terribly fiddly and arbitrary. It would be a game I would hate to play.
Worse still, I didn't detect the problems with the game early on, and spent far too much energy in a fruitless direction. I ended up mocking up boards and pieces in Illustrator so I could simulate movements, and even wrote a simple card shuffling and dealing java app for handling cards.
I'm not saying I necessarily regret the effort, but it was a lot of work, and the only payoff it yielded was in lessons learned. I think I'm finally ready to learn those lessons. Where did I go wrong in that game?
Goals and Outcomes
I think a lot of your success in design relies on your goal setting, on the qualities you use to guide your idea generation and selection. In board games this is tricky. Your goals are usually on the order of the game experience you want to create, either in terms of tension, socialization, enacting a given theme, creating an envisioned situation, etc. Your ideas are usually on the order of specific mechanics, rules, cards, physical components - the elements that make up an actual game design.
The problem is, outcomes in board games are usually emergent: they are the result of several, subtle interacting ideas. If a game has tension, that might be the result of some finely tuned interactions between the actions players can take and the victory conditions. If a game really captures the feel of exploring a haunted house, that might be the result of streamlined mechanics, well-designed physical components, well-considered card designs and an objective system that drives players to play in the "right" spirit for the game. So you have to come up with ideas that mesh together well, and that serve a variety of purposes.
And there are so many ways that an outcome can fail. If the strategy is too obvious, if there isn't enough player interaction, if there is too little control, if the rules are too complicated, if the pieces are too fiddly, if there is a runaway leader, if the game takes too long, if the game is too physically bulky, etc etc etc: then that kills the design. So you're trying to meet these emergent outcome goals, while ensuring that you don't fall into one of dozens of pitfalls.
In a way, you have this idea, and you're just trying to get some approximation of it out there without falling into some pitfall. (I see something similar in software design, and I find myself wanting to refer to them as "negative design fields". I think it is an artifact of having an information-based product.)
So what does all this have to do with my old Monster game design? I didn't have good goals. My goal was to enact a particular sequence of game events, and I met that goal. The problem was, the resulting game was not any fun.
On some level, I need to consider the player experience when you're designing a game. I can't get wrapped up in some vision of the board, or the way the pieces move around, or the situation that I want to create. At the end of the day, what you are creating is an experience, and you need to have goals that reflect that.
Now, its tough to just keep in mind "I want my players to have a good experience" and expect that to guide you towards good designs. Rather, there are some subgoals that I think you can keep in mind.
I've begun to develop a series of "step-back exercises". There's nothing formal about them, they're just patterns I've noticed in my own thinking that demonstrate a tendency towards giving me insight and getting me past blocks. And from them, I've started to hatch some goals and ways of thinking that will help to ensure that I can work my way towards successful designs, without falling into problems. In a way, I think a way to be successful in game design is to flit between different perspectives, ensuring that you don't paint yourself into a corner. If you can sense problems of a given sort developing early, you can prevent getting yourself into a dead end that will be psychologically disheartening, if not cognitively impossible, to back out of.
Here's and early stab at goal-based approaches that I've found useful so far:
Component Reality Check
This was the first one I started with, back in the day, which I suppose says something about the sort of bloated designs that I made back then. Basically, when I sense that I've reached a certain critical mass on a game's component, I list them out and imagine whether they seem reasonable laid out on the table or as a manifest for a mass-produced game. Sometimes this is relative - if the gameplay is fairly light or if each game is pretty quick, it seems silly to demand a lot of component, either just in terms of setup time or (eventually) the marketability of the game relative to the cost of production.
I think in the past I was a bit to lax with this in the past, but then my focus has been on cleaner designs lately, and generally more disciplined. Beyond setup time and production, I think this can be a warning sign that your design is getting inelegant, as you tack on a deck of cards or board to track values. Ensure that all of the physical elements of your design are pulling their weight, and you might get some insight into your conceptual efficiency as well.
Explain this to a New Person
This is another simple one that I've increasingly used lately. Too often I accumulate assumptions about how things should work, check them off as solved and spend hours trying to mentally tackle the remaining issues. I start rearranging the established stuff to fix the problems with the remaining stuff, shifting pieces around in response to local threats, sort of stepping my way through things. Its like trying to solve a sudoku puzzle by slamming in a bunch of numbers and trying to spot-correct the inconsistencies: you end up chasing your tail. Sometime's I'll feel like I have just one more issue left, but when I look at the finished product, its a mess.
I've found the problem is an inability to design with the gestalt, the elegant whole of the design, in mind. This is no small challenge. But something that helps is envisioning myself trying to explain the design, as I have it so far, to someone who knows nothing about the game. I try to imagine what their reaction is likely to be as I progress. Are they nodding and following the logic of what I've said thus far, or are they getting overwhelmed with ambiguities, details or exceptions? For the parts that are still difficult, how might I more elegantly explain them.
On the surface, its important that players a game understand it easily the first time they play it. But I also think there is a connection between the initial understandability (or explainability?) of a game and its overall playability. Sure, there's many a game that seems easy once you get the hang of it, certainly and defininitely granted. But the game that you immediately understand usually remains understandable (though there is the issue of strategic confidence, which I get into below). I find taking this step helps me get my head around the state of the design, where it's straining, where there are details that I might need to prune. Performing this step a little earlier in the process seems to be helping me back out of directions destined to spin into unworkability.
Interaction Checks
A more recent, even nacent, approach. I realized that too many of my designs were basically focused on creating interesting sets of interacting mechanics that the players' actions were variables in. Or I effectively came up with an interesting, puzzley situation and allowed multiple people to participate in it. But I believe that the heart of a good game is very often in its ability to provide a medium for compelling interactions between players, and this will rarely emerge on accident.
In short, I've started to focus my design process on player interaction. This has primarily manifested itself early in the process, as a way of evaluating initial designs or thinking of direction to take a given theme. In short, if you aren't going to have an interesting interaction mechanism, your design's liable to be doomed. Games are much more interesting when your ability to pull off your plans depends on your opponent's actions, and when your goals must be balanced against efforts to thwart those of your opponents. I think explicit focus on this aspect of a design will do me good.
Fundamental Decision Structure
This sounds fancier than it is. Somewhere in the back of my mind there's a model of the decision trees that players face over the course of a game, and which are more appealing than others. But in the meantime, I've started using a basic version of this concept to evaluate the experience provided to players. After all, its a player experience you're really hoping to create, the game is just the means.
During a game, a player will be faced with a large number of decisions. In most games, there are certain patterns that govern these decisions; each decision is unique, but they are of certain constant types. For example, in backgammon your decisions revolve around which pieces to move with your roll for the turn, and possibly how to handle doubling decisions based on board evaluations. In Puerto Rico, you are looking at questions of role selection, as well as decisions within role-turns, such as which boats to ship on, where to place colonists, and what buildings to buy.
The issue is, which of these kinds of decisions are fun? I think there is some value in Knizia-like designs, where the the player has limited options at any given moment, but where the implications of those decisions are sublte enough that choosing between them is difficult. I think games where you have a great many decisions can be ok, as long as you can categorize them as being productive to your goals or not, and quickly prune your search to those that you're interested in. For example, there's a veritable ton of things you can do on a turn in Arkham Horror, but you generally end up deciding between a few, reasonable alternatives, as you take advantage of the opportunities the game presents you.
This approach is really about avoiding pitfalls. For one, there's analysis paralysis. If you give the players a ton of information to work with, and a ton of choices, trying to find the best one can be daunting. For example, imagine that on a player's turn of Carcassonne they received 4 tiles from the player to their right and one from the stack. They played one, and passed the other 4 to the left. Sure, the game might be more strategic, but the enormous number of options it opened up would mostly just grind the game to a halt. Players would have to look at tons of possible plays, and also worry about what they were giving their opponents. Downtime would increase, and I reckon it would often just give players a sour taste of feeling like they missed the best move. The same goes for playing Metro where you can play tiles in any direction, or games where nearly-un-memorizable past information is kept open for people to consider.
On the other hand, there's the problem of lack of control. If a player's decisions don't affect their chances of success in remotely predictable ways, they're likely to see the whole exercise as not worth thinking about. This is often manifested in terms of large amounts of luck or hidden information, but it might just be an issue of the complexity of the system in which the players are working. I find the initial chaos of a game of Tigris and Euphrates to be daunting to this day.
What it comes down to is, what is the basic decision you are asking the player to make, and does this represent a fun challenge, or at least a means to exert control over the game situation? This is about as close as you can come to the question "is the game fun?", at least from a purely mechanical standpoint. Or at least, recognizing this aspect of a given design helps me to avoid situations where I've managed to simulate something, or even create an interaction, where the basic activity of playing the game just isn't any fun.
Side Note
I might be hatching a new theory here, where a game is essentially decision structures, interaction structures and theme. That is, enjoyment from puzzling out answers, enjoyment from interacting with others, and enjoyment from the story told by the events the game simulates. I'm not sure if that's a complete list, or if there's an elegant way to encapsulate them, but they seem related somehow.
Initial Strategy
Finally, a small observation of a quality shared by many members of the upper pantheons of successful lightweight Euros. I've noted that many good games are characterized by brand new players' ability to learn the rules and immediately say "I think I'll try to do this". That is, rather than blindly performing moves, or sort of needing a prod from the experienced players (T&E, Acquire, Battle Line, I'm looking in your direction), players can hatch at least a rudimentary overall strategy that will guide their initial moves.
For example, the tickets in Ticket to Ride provide an imputus to some initial train placements and interest in certain areas. In Settlers, interest in certain expansion points, the allure of development cards or the kind of resources you happen upon in the early turns can definately guide you towards certain approaches.
I'm not sure what to do with it yet, but it seems like creating a game where the player is immediately seduced by their own ability to have a plan is a quality to strive for. Its something I've tried to keep in mind in some early designs these days.
In conclusion, game design is certainly not as simple as starting with a theme and creating some mechanics around it. Nor can you come up with some mechanics and make a terribly fun game out of them. It sounds obvious, but this was too often the way I ended up approaching things. Rather, there's a variety of qualities you need to converge upon, and its a process of careful triangulation.
A final note on themes. I'm finding I need to avoid getting hung up on a particular approach to a theme until there's some mechanical groundwork that provides a basic level of interaction and compelling decision-making. I need to avoid getting seduced by thematic, cinematic events, they're very demanding on the rules, and can create cracks all over the place, and aren't usually necessary to make a game truly fun. Assuming you want to start with a theme: I think its more a matter of finding a theme that will inspire some interesting possible mechanics, massaging those until they work pretty well, allowing the theme to poke in when its welcome, and then allowing it to act as a coat of paint at the end. The basic mechanical inspirations, and the naming and art and sheen, should be enough to tie the game to the mechanics, and if those are sound the game just might work. Its a tricky balancing act to say the least, but I'm hoping by better acknowledging it to end up with more designs that are fully successful.
New Simplified Design Framework (Draft)
Here's a stab at it, this blog seems as good a place as any to take a try. This is a bit of a draft, with no images yet. I will add them later. Feel free to ignore this for now, just felt like throwing it up early.
The Old Process/Product Models
Here's the part of my design framework you need to understand to get what I'm getting at here. First, I see design as an information gathering process. Basically you are trying to learn about 1) the outcomes that will satisfy all of the stakeholders of the design situation, and 2) the designs that will lead to those outcomes.
[Basic image of design space and outcome space]
So lets look at the design space first. A design is a representation that can be translated into an outcome. A blueprint is a design, the building is an outcome. The design space is the space of all possible designs.
We also have a space of every outcome that could be possibly conceived, and when a given design is executed, it will result in an outcome. A given design is assumed to be interpreted according to some professional standard, but there is always some wiggle room in the exact outcome that will be realized by a given execution of the design. Sometimes, a design is preliminary, and might result in a great many outcomes. If I sketch a building on a napkin and say "build it", there's a lot of ways you might interpret my sketch, and a lot of buildings that might result. If I give you a full blueprint, I have a lot more confidence about what outcomes I'm going to see. You still might make certain choices about materials, brands, numbers of nails, but I can be assured of certain dimensions and qualities.
[Image of stakeholders and outcome spaces]
This constraining is important because we want to ensure that we achieve outcomes that are desirable. Among all the stakeholders in the design process, each has some concept of what makes them happy. The client who contracts the opera house says "make it reflect the grace and generosity of my family". The city says "obey these zoning laws and we get to sign off on whether it fits our vision of the city". The architect himself says "I want this to reflect my genius, to be a true Bob Buildington Building". There are certain outcomes that are going to meet all of these needs and keep everyone happy, and some that are not. You want to be assured that your design is "desirable" that is, that it meets the desirability standards of all your stakeholders.
Now, of course, this may not be possible, there may not be any outcomes that truly make everyone happy, so you might need to be flexible. Some of these desirability spaces might be a bit fuzzy. Furthermore, you need to consider which outcomes are feasible. That is, you might design a skyscraper on a thin glass pillar, which is a vision that everyone envisions as a desirable outcome, but you can't build it. Its not a feasible outcome.
So you need to make sure that, when you create a design, all of the ways it might be interpreted are desirable. Therefore, it might be a good idea to be specific, and ensure that the enactor of your design doesn't haul off and create some awful shit that your design didn't tell him not to.
In short, design is all about learning about what outcomes you want, and what kind of designs will achieve them, and then settling on a design that leads to the outcomes that you want. To put it another way, if you knew everything, you could just say "Aha! Here's the design, I will hand it off, and any way its interpretted, that design will make everyone happy". Or at least you would know if that was impossible, and what comprimises could be made. Designing is about gathering enough information to approximate this kind of omniscience, learning enough about the situation at hand to slam down a design and say "this'll do it".
Now, I have a process model that also describes the information that feeds into this process of creating designs. In short, you have Ideas about what form your design should take, Knowledge that spans projects but that can be applied to the situation at hand, Goals that tell you what Ideas and Knowledge should be used and which should be passed on, and Representations, your link to the outside world, your way of passing information between people and learning about how things actually work.
Representations
[Rep as abstraction image]
The main pertinent point here is Representations. Basically, you can use a representation intentionally and exploratoraly. Intentionally: someone put some information in this representation, and now you can get it out. It might be a note to yourself, a conversation with someone, or a design document. Its the way we take the purely mental ideas, knowledge and goals and let them move from mind to mind. Exploratoraly: This is the key one. We can create physical objects that are approximations of real-world situations, and they can give us insight into fitness of outcomes, and the design-outcome connection.
For example, if I create a sketch of a building, I can look at it and go "huh, that doesn't look right", and maybe create another sketch (if I can merge this reflection and action into a single action of Reflection in Action, I can start a hallowed Reflective Conversation with Matertials, as described by Schon, which is sort of a design-representation-related version of a Flow state as described by Csikszentmihalyi). This sketch tells me some things, but it leaves out others. I might not have a sense of the shadows the building will cast on the surrounding populace based just on a sketch. So I might create a scale model with the surrounding areas. Then I can look at that and think about where the problems are, what does and doesn't work. I might later create a full-scale facade of what the building is going to look like, to get a feel for the materials and the appearance.
In this running building example, I'm creating an approximation, an abstraction. It isn't practical to create a whole building and decide if it's right, and then tear it down and try again if not. Instead, I make a tradeoff between ease of creation and realism. I can use a very easy sketch to tell me some things. I can spend a little more time to create a scale model to learn others, and so on. Generally, those approaches that are strictly more difficult than others, while providing similar information, have been weeded out from common practice, and the common approaches present a pretty smooth tradeoff along these dimensions.
So this is our way of learning about the outcomes we make. We have some ideas, we create approximations of them, and then we evaluate those approximations, and therefore those ideas. We keep the ideas that seem promising, we discard those that don't, and we slowly learn more and more, hopefully generating ideas that are better and better, until we are satisfied, or get pissed off and give up.
That is, because some fields are harder than others. In the next section, I'll describe some actions that I see as fundamental to the design process, and explain how some fields have a harder time with some of them than others. When certain actions are difficult, trying to execute them can hinder the designer's basic creative flows, and the designer must find ways to adjust their process and their state of mind to creatively attack the troublesome problems. But now its nearly 3.
The Old Process/Product Models
Here's the part of my design framework you need to understand to get what I'm getting at here. First, I see design as an information gathering process. Basically you are trying to learn about 1) the outcomes that will satisfy all of the stakeholders of the design situation, and 2) the designs that will lead to those outcomes.
[Basic image of design space and outcome space]
So lets look at the design space first. A design is a representation that can be translated into an outcome. A blueprint is a design, the building is an outcome. The design space is the space of all possible designs.
We also have a space of every outcome that could be possibly conceived, and when a given design is executed, it will result in an outcome. A given design is assumed to be interpreted according to some professional standard, but there is always some wiggle room in the exact outcome that will be realized by a given execution of the design. Sometimes, a design is preliminary, and might result in a great many outcomes. If I sketch a building on a napkin and say "build it", there's a lot of ways you might interpret my sketch, and a lot of buildings that might result. If I give you a full blueprint, I have a lot more confidence about what outcomes I'm going to see. You still might make certain choices about materials, brands, numbers of nails, but I can be assured of certain dimensions and qualities.
[Image of stakeholders and outcome spaces]
This constraining is important because we want to ensure that we achieve outcomes that are desirable. Among all the stakeholders in the design process, each has some concept of what makes them happy. The client who contracts the opera house says "make it reflect the grace and generosity of my family". The city says "obey these zoning laws and we get to sign off on whether it fits our vision of the city". The architect himself says "I want this to reflect my genius, to be a true Bob Buildington Building". There are certain outcomes that are going to meet all of these needs and keep everyone happy, and some that are not. You want to be assured that your design is "desirable" that is, that it meets the desirability standards of all your stakeholders.
Now, of course, this may not be possible, there may not be any outcomes that truly make everyone happy, so you might need to be flexible. Some of these desirability spaces might be a bit fuzzy. Furthermore, you need to consider which outcomes are feasible. That is, you might design a skyscraper on a thin glass pillar, which is a vision that everyone envisions as a desirable outcome, but you can't build it. Its not a feasible outcome.
So you need to make sure that, when you create a design, all of the ways it might be interpreted are desirable. Therefore, it might be a good idea to be specific, and ensure that the enactor of your design doesn't haul off and create some awful shit that your design didn't tell him not to.
In short, design is all about learning about what outcomes you want, and what kind of designs will achieve them, and then settling on a design that leads to the outcomes that you want. To put it another way, if you knew everything, you could just say "Aha! Here's the design, I will hand it off, and any way its interpretted, that design will make everyone happy". Or at least you would know if that was impossible, and what comprimises could be made. Designing is about gathering enough information to approximate this kind of omniscience, learning enough about the situation at hand to slam down a design and say "this'll do it".
Now, I have a process model that also describes the information that feeds into this process of creating designs. In short, you have Ideas about what form your design should take, Knowledge that spans projects but that can be applied to the situation at hand, Goals that tell you what Ideas and Knowledge should be used and which should be passed on, and Representations, your link to the outside world, your way of passing information between people and learning about how things actually work.
Representations
[Rep as abstraction image]
The main pertinent point here is Representations. Basically, you can use a representation intentionally and exploratoraly. Intentionally: someone put some information in this representation, and now you can get it out. It might be a note to yourself, a conversation with someone, or a design document. Its the way we take the purely mental ideas, knowledge and goals and let them move from mind to mind. Exploratoraly: This is the key one. We can create physical objects that are approximations of real-world situations, and they can give us insight into fitness of outcomes, and the design-outcome connection.
For example, if I create a sketch of a building, I can look at it and go "huh, that doesn't look right", and maybe create another sketch (if I can merge this reflection and action into a single action of Reflection in Action, I can start a hallowed Reflective Conversation with Matertials, as described by Schon, which is sort of a design-representation-related version of a Flow state as described by Csikszentmihalyi). This sketch tells me some things, but it leaves out others. I might not have a sense of the shadows the building will cast on the surrounding populace based just on a sketch. So I might create a scale model with the surrounding areas. Then I can look at that and think about where the problems are, what does and doesn't work. I might later create a full-scale facade of what the building is going to look like, to get a feel for the materials and the appearance.
In this running building example, I'm creating an approximation, an abstraction. It isn't practical to create a whole building and decide if it's right, and then tear it down and try again if not. Instead, I make a tradeoff between ease of creation and realism. I can use a very easy sketch to tell me some things. I can spend a little more time to create a scale model to learn others, and so on. Generally, those approaches that are strictly more difficult than others, while providing similar information, have been weeded out from common practice, and the common approaches present a pretty smooth tradeoff along these dimensions.
So this is our way of learning about the outcomes we make. We have some ideas, we create approximations of them, and then we evaluate those approximations, and therefore those ideas. We keep the ideas that seem promising, we discard those that don't, and we slowly learn more and more, hopefully generating ideas that are better and better, until we are satisfied, or get pissed off and give up.
That is, because some fields are harder than others. In the next section, I'll describe some actions that I see as fundamental to the design process, and explain how some fields have a harder time with some of them than others. When certain actions are difficult, trying to execute them can hinder the designer's basic creative flows, and the designer must find ways to adjust their process and their state of mind to creatively attack the troublesome problems. But now its nearly 3.
Subscribe to:
Comments (Atom)