Tuesday, July 24, 2007
Principles of Score-Golf Design
God damn blogger. I somehow lost some huge post about the sports golf game. The short version is, you pick a game and a winner, your distance is your winner's score, reduced by the difference between the other team's score. If your team doesn't win, you also get a left/right, hook/slice penalty. So you want a close game for a lengthy shot, but failing to pick the winner will cause you to deviate left-to-right. I'll try to rewrite this properly tomorrow.
Monday, July 23, 2007
Predictable vs. Unpredictable Decks
Can't sleep tonight, and I definately don't have the patience for finishing my big theoretical thrust. But I did want to jot down some thoughts about decks of cards.
When you want to simulate a variety of effects, its tempting just to assign each to a card and throw them into a deck. Want to make a game where players can attack eachother with fire spells and lightning bolts and mind control? Make a deck with one card for each of those with the details, and let players hold a hand of them!
My trouble is with unpredictable decks. In particular, I have a problem because I'm lately rather taken with the mechanic where the success of a given strategy relies on your opponent not having a given card or type of card. Lost cities is an example, where your willingness to discard a given card or start on a given color depends on what your opponent has. Gin Rummy has a similar dynamic. I like decisions that are nearly-calculable. That is, those decisions where you can derive some heuristic of the expected overall value of a given move, but can't truly know much anything. Your opponent "probably" doesn't have that card, but you likely can't math out the exact odds, much less use them to determine your "best" move. And what has your opponent told you by the way they've played thuse far? Are they playing like they have that card? Are they cagey enough to be actively deceiving you on this matter?
I think its a rich class of effects, and it fits nicely with my own sensibilities as a player, in terms of what kind of games I can play without overanalysing them.
But these rely on some easily considered concept of the deck's makeup, usually summarized in terms of a number range and suit range. As soon as you have a deck of random effects without overriding rules governing them, it gets a little more complicated. The guesses so thoroughly defy calculation as to step outside the realm of reasonable guesses. And furthermore, and perhaps most damningly, your ability to make any kind of guess depends on knowing the deck. Someone can't just tell you what the spread of values are, you have to know the fireball, the mind control, the lightning bolt and the summon: troll. Its difficult to reason with, and the experienced player holds a huge advantage, if this "what's he got" comes into play strongly with decks like this.
(More broadly, this is another of my themes, immediate accessibility of strategy)
I guess my point is, the custom deck, with an effect-per-idea is an easy out, but there's something to be said about a deck with easy description, and easy understanding. Suit-value decks are the obvious answer, but 7-Nimmt and No Thanks! have just-number decks that work. An even better example is Heave Ho! There's a learning curve there, but mostly you just need to know the basic spread, that there's a dragon, and a kill-you-if-you-got-the-dragon card. Knowing about the switch sides card helps to. But my point is, there's a deck that is heterogeneous, but that has a readily describable distribution, and that lends itself to the immediate engagement in the sort of has-he-got-it strategizing that I'm seeking.
Definately a tradeoff, and I think the virtues of a predictable deck are often underappreciated.
When you want to simulate a variety of effects, its tempting just to assign each to a card and throw them into a deck. Want to make a game where players can attack eachother with fire spells and lightning bolts and mind control? Make a deck with one card for each of those with the details, and let players hold a hand of them!
My trouble is with unpredictable decks. In particular, I have a problem because I'm lately rather taken with the mechanic where the success of a given strategy relies on your opponent not having a given card or type of card. Lost cities is an example, where your willingness to discard a given card or start on a given color depends on what your opponent has. Gin Rummy has a similar dynamic. I like decisions that are nearly-calculable. That is, those decisions where you can derive some heuristic of the expected overall value of a given move, but can't truly know much anything. Your opponent "probably" doesn't have that card, but you likely can't math out the exact odds, much less use them to determine your "best" move. And what has your opponent told you by the way they've played thuse far? Are they playing like they have that card? Are they cagey enough to be actively deceiving you on this matter?
I think its a rich class of effects, and it fits nicely with my own sensibilities as a player, in terms of what kind of games I can play without overanalysing them.
But these rely on some easily considered concept of the deck's makeup, usually summarized in terms of a number range and suit range. As soon as you have a deck of random effects without overriding rules governing them, it gets a little more complicated. The guesses so thoroughly defy calculation as to step outside the realm of reasonable guesses. And furthermore, and perhaps most damningly, your ability to make any kind of guess depends on knowing the deck. Someone can't just tell you what the spread of values are, you have to know the fireball, the mind control, the lightning bolt and the summon: troll. Its difficult to reason with, and the experienced player holds a huge advantage, if this "what's he got" comes into play strongly with decks like this.
(More broadly, this is another of my themes, immediate accessibility of strategy)
I guess my point is, the custom deck, with an effect-per-idea is an easy out, but there's something to be said about a deck with easy description, and easy understanding. Suit-value decks are the obvious answer, but 7-Nimmt and No Thanks! have just-number decks that work. An even better example is Heave Ho! There's a learning curve there, but mostly you just need to know the basic spread, that there's a dragon, and a kill-you-if-you-got-the-dragon card. Knowing about the switch sides card helps to. But my point is, there's a deck that is heterogeneous, but that has a readily describable distribution, and that lends itself to the immediate engagement in the sort of has-he-got-it strategizing that I'm seeking.
Definately a tradeoff, and I think the virtues of a predictable deck are often underappreciated.
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.
Sunday, July 15, 2007
Try-and-see test
Tonight I sat down with some components from various games, jamming them against eachother, testing any sets of rules that seemed promising. I ended up working with the following:
Triominoes: http://www.boardgamegeek.com/image/104712
Cards from Rage: http://www.boardgamegeek.com/image/91475
Cubes from El Grande: http://www.boardgamegeek.com/image/167025
I started off with just the triominoes and cards from Rack-o, letting 2-digit numbers 0-5, 10-15, etc coorespond to pairings of the 0-5 numbers on the tiles. Nothing really great there. Also, there was no actual 0 cards, which got me thinking about card decks that do go to 0. How about Rage? I've used those cards in a lot of experiments before. But they have 6 colors, might as well do something with those.
So I tried this, pretty much off the top of my head, with only a little misstep or two requiring adjustment.
Rageominoes: A game for 2 players
Setup
- Use a deck made of red, green, blue and yellow Rage cards from 0-5, 12 cubes of each of those colors, and all the tiles.
- Each player gets 5 cards and 4 tiles, hidden from their opponent. One tile is placed face up in the play area, the others are all face down.
Game Play
- Each turn a player plays a tile adjacent to an existing one. If both numbers on the tile match the adjacent numbers (ie, a legal play in triominoes, if I remember correctly), then a card with one of those matching numbers may be played. The card is discarded, and a cube matching its color is placed on the played tile. The player takes a cube of that color.
- Then the player draws up to 4 tiles and 5 cards, as necessary. Play passes to the other player.
Game end and Scoring
- The game ends when a card must be drawn, but there are none left.
- Each set of touching tiles that have cubes of the same color on them form a group. Cubes of a given color are worth one point for every tile in the largest group of that color. Players add up the points provided by the cubes they have taken, the highest score wins.
I like the simple ruleset, and the way that you must manage both tiles and cards. I like the potentially explosive scoring of rattling off a large group and collecting the cubes necessary for that group.
It didn't really work though. You were too often just at the mercy of the cards and tiles you had, without enough information about your opponent to work with. That said, there's already an information overload, an artifact of using the triominoes tiles. Too often, I would look at the colors and cards I had, and just try to find a way to place that card, looking for a matching tile space. Plus its an annoying, unfun kind of decision search, with limited options in a Knizia-ish sense, but requiring a lot of visual scanning.
I'd been envisioning lots of designs with those triominoes tiles, but I learned something important: that the basic search of matching tiles is annoying as hell already, and tacking a game on top of it is likely a bad idea. Good to know, sealing off directions that have a low chance of bearing a good idea, so that I can focus my thoughts elsewhere, is very productive. I may still use them face-down though, as movable triangular spaces. There are sort of cool "swinging" moves you can make.
I was watching the Phillies lose their 10,000th game today, and someone had a sign referencing a famous Edison anecdote. Basically, he said he made 10,000 mistakes on his way to creating the light bulb, but considered it a 10,001 step success. In my thoughts about design fields and their points of difficulty, I become frustrated at my inability to tell what's going to work in a board game design; the difficulty in mapping designs to outcomes before implementing them. It might just be one of those fields where the only way to know is to try try try over and over again. It took one mistake to learn some properties of triangular dominoes, I guess after 10,000 lessons I'd probably have a handle on things well enough to publish a game. One a night for 30 years I'm there. Mistake 1.
Triominoes: http://www.boardgamegeek.com/image/104712
Cards from Rage: http://www.boardgamegeek.com/image/91475
Cubes from El Grande: http://www.boardgamegeek.com/image/167025
I started off with just the triominoes and cards from Rack-o, letting 2-digit numbers 0-5, 10-15, etc coorespond to pairings of the 0-5 numbers on the tiles. Nothing really great there. Also, there was no actual 0 cards, which got me thinking about card decks that do go to 0. How about Rage? I've used those cards in a lot of experiments before. But they have 6 colors, might as well do something with those.
So I tried this, pretty much off the top of my head, with only a little misstep or two requiring adjustment.
Rageominoes: A game for 2 players
Setup
- Use a deck made of red, green, blue and yellow Rage cards from 0-5, 12 cubes of each of those colors, and all the tiles.
- Each player gets 5 cards and 4 tiles, hidden from their opponent. One tile is placed face up in the play area, the others are all face down.
Game Play
- Each turn a player plays a tile adjacent to an existing one. If both numbers on the tile match the adjacent numbers (ie, a legal play in triominoes, if I remember correctly), then a card with one of those matching numbers may be played. The card is discarded, and a cube matching its color is placed on the played tile. The player takes a cube of that color.
- Then the player draws up to 4 tiles and 5 cards, as necessary. Play passes to the other player.
Game end and Scoring
- The game ends when a card must be drawn, but there are none left.
- Each set of touching tiles that have cubes of the same color on them form a group. Cubes of a given color are worth one point for every tile in the largest group of that color. Players add up the points provided by the cubes they have taken, the highest score wins.
I like the simple ruleset, and the way that you must manage both tiles and cards. I like the potentially explosive scoring of rattling off a large group and collecting the cubes necessary for that group.
It didn't really work though. You were too often just at the mercy of the cards and tiles you had, without enough information about your opponent to work with. That said, there's already an information overload, an artifact of using the triominoes tiles. Too often, I would look at the colors and cards I had, and just try to find a way to place that card, looking for a matching tile space. Plus its an annoying, unfun kind of decision search, with limited options in a Knizia-ish sense, but requiring a lot of visual scanning.
I'd been envisioning lots of designs with those triominoes tiles, but I learned something important: that the basic search of matching tiles is annoying as hell already, and tacking a game on top of it is likely a bad idea. Good to know, sealing off directions that have a low chance of bearing a good idea, so that I can focus my thoughts elsewhere, is very productive. I may still use them face-down though, as movable triangular spaces. There are sort of cool "swinging" moves you can make.
I was watching the Phillies lose their 10,000th game today, and someone had a sign referencing a famous Edison anecdote. Basically, he said he made 10,000 mistakes on his way to creating the light bulb, but considered it a 10,001 step success. In my thoughts about design fields and their points of difficulty, I become frustrated at my inability to tell what's going to work in a board game design; the difficulty in mapping designs to outcomes before implementing them. It might just be one of those fields where the only way to know is to try try try over and over again. It took one mistake to learn some properties of triangular dominoes, I guess after 10,000 lessons I'd probably have a handle on things well enough to publish a game. One a night for 30 years I'm there. Mistake 1.
Saturday, July 7, 2007
stray idea - [moved]
a light game where you build spiderwebs between household objects
dice grids - role selection - guessing
dice grids - role selection - guessing
Subscribe to:
Posts (Atom)