I'm constantly looking at the world in game design terms, but this can lead to lots of excitable trips down dead end paths. Oftentimes, I find:
1. Modeling an interesting real-world decision process in a game does not necessarily result in an interesting game mechanic.
2. Introducing an interesting real-world effect as a rule does not necessarily make for an interesting rule, let alone interesting gameplay.
There's getting inspired, and there's getting distracted. Telling them apart is difficult.
Showing posts with label Mistakes. Show all posts
Showing posts with label Mistakes. Show all posts
Tuesday, July 29, 2008
Friday, November 16, 2007
The Theme and Mechanic Traps vs. Tension-Resolution
This idea is something that I have had percolating for some time now. I don't know if I can quite bang the whole thing out, but I wanted to get the essence down.
My early game designs fell into two approaches, both "traps", in the sense of leading me down wrong paths and ending up at games that weren't going to work.
The Theme Trap
The theme trap is where you think of an awesome scenario, and want to make a board game that creates the awesomeness of that scenario. For example, my early versions of my Monster-in-the-city games were born from this. I liked the idea of monsters wrecking a city; you could wreck buildings! Stomp tanks! So I started from that point, and let some major, important decisions be made in that spirit.
I.e.: Each player has a monster. But who controlls the city? Well, each player also has a set of army units! What are some appropriate army units, how about infantry, tanks and planes? How should those move? Well, infantry should be slow, planes should be able to move really far in a long line. And monsters should be able to have fire breath and eye beams and...
It sounds really childish, and I am giving myself a hard time a bit, but its really easy to fall into this trap. Some games can pull it off, but they usually do so with an (unpredictable) one-effect-per-card deck, give the cards to the players, and let the whole thing fall out as it may. It sort of can work, but the gameplay is usually pretty unsatisfying.
The Mechanic Trap
This is where you come up with a clever mechanic or interaction, and try to build a game around it. You would think the outcome is a successful game with no theme, but that's not quite it in my experience. For me, it doesn't even turn into a workable game.
A lot of my designs have fallen into this trap. And I think the problem is, I see an interesting interaction of rules, and I build a game around them, but there often isn't any game there. I might call a sub-problem of this the "engine trap", where basically I build an interesting engine that the players can toy with, hoping that their doing so in opposition to one another will lead to interesting gameplay, but it just doesn't. It doesn't lead to good player interaction, there are positive feedback loops of success or failure, the whole thing ends up feeling like its playing itself, or its just not fun for some reason.
I had a game design (lets call this Mistake Explanation #4) where you were a scientist/wizard who was collecting body parts and workers and buildings, and using them to create zombies, which could be used as workers, and made money for more buildings, all powered by some kind of drafting mechanic (which I spent far too long in love with). Basically, one thing lead to the next, lead to the next, lead towards a victory state, and it was up to the players to grab the right stuff. But the game ended up feeling totally arbitrary and frustrating from the player side, and the player interaction was minimal at best.
It ended up feeling like sitting with your opponents at one of those conveyor-belt sushi bars, trying to get full the cheapest (god dammit, that sort of sounds like a doable game). But my point is, it was a clever machine, and you were competing, but it wasn't much of a game.
The 2-Player Monster/City Experience
Recently, its mostly been the theme trap that's been messing with me on the 2-Player Monster/City game (any name suggestions? this is getting ridiculous). I realized I wasn't getting the gameplay I wanted out of the top-down city map, and kept shrinking the board, turning the easy knobs, without looking at the root of the problem. Shouldn't it be more interesting to maneuver around the city? Why wasn't it?
I realized that I had decided on the city unit types/abilities/stats basically for thematic reasons, but not because they actually figured to lead to interesting gameplay. There should be artillery, it should have infinite range. There should be infantry, they should basically be canon fodder to slow the monster down.
Even monster rules came about this way, and I fell into traps of things that seemed to have nice synergy, but that didn't necesssarily contribute to overall gameplay. I want infantry to slow down the monster, and thematically it seems like the monster should be able to stomp right over human units, so I'll say he can kill the first unit he gets to, but then has to stop. This, lead to other decisions that were made in similarly willy-nilly ways.
This wasn't wholly responsible for the failings of the design, but it wasn't the right way to make the decisions. I wanted, at one point, for the game to be about containing the monster, but I made decisions counter to that. Artillery as a unit made no sense at all in this game, but I liked the image of artillery shooting at a monster, and in the unit went.
Solutions?
I've cone to realize that player interaction is crucial as a starting inspiration point and evaluation criteria, especially in a 2-player game, you would think. Further, I've started to see designing in terms of tensions. The core of a game is establishing tension and providing satisfying resolution. You have to create a situation where 1) the outcome is in question, and possible results fall into categories that are more or less advantageous to the player, 2) where the player is able to affect the outcome in a way that makes its resolution satisfying. I won't go into a long string of examples, but I think this is present in nearly any good game I can think of.
Conversely, games where the outcomes aren't forseeable enough to be hoped/pushed for, or where the possibility of outcomes produce tension but the resolution is so arbitrary that the player loses interest, abound - and can blame many of their problems for this failing. I was working on a list/taxonomy of game problems, and many of them fall into here in one way or another. A game with too much luck is an obvious choice, but the runaway leader problem is on a larger scale; it is an inability to maintain tension because while the short term outcomes are still predicatable and affectable, players are so far behind they aren't compelled to care.
So can your mechanics yield tension in the short term, on a move by move basis, and maintain it over the course of the game? And, on repeat plays, does the game remain unpredictable, yet controllable enough that it remains compelling. I think the double-sided loop game Chad and I worked on in Seattle last year was actually well designed in the sense that we put move-by-move tension as a first priority, but its most-pips-wins aspect eventually killed it, since the overall result no longer seemed to resolve satisfyingly (there's still something in that game).
Anyway, this has gone on quite long enough, I'm going to try to rethink this monster game drastically, get back to the kinds of tensions I'm trying to build, and make my choices around supporting them. Interestingly enough, I think there might be futures for both the top-down and side-scrolling games - at least if I get stuck on one I can work at the other for a bit. Cheers to you if you read this far!
My early game designs fell into two approaches, both "traps", in the sense of leading me down wrong paths and ending up at games that weren't going to work.
The Theme Trap
The theme trap is where you think of an awesome scenario, and want to make a board game that creates the awesomeness of that scenario. For example, my early versions of my Monster-in-the-city games were born from this. I liked the idea of monsters wrecking a city; you could wreck buildings! Stomp tanks! So I started from that point, and let some major, important decisions be made in that spirit.
I.e.: Each player has a monster. But who controlls the city? Well, each player also has a set of army units! What are some appropriate army units, how about infantry, tanks and planes? How should those move? Well, infantry should be slow, planes should be able to move really far in a long line. And monsters should be able to have fire breath and eye beams and...
It sounds really childish, and I am giving myself a hard time a bit, but its really easy to fall into this trap. Some games can pull it off, but they usually do so with an (unpredictable) one-effect-per-card deck, give the cards to the players, and let the whole thing fall out as it may. It sort of can work, but the gameplay is usually pretty unsatisfying.
The Mechanic Trap
This is where you come up with a clever mechanic or interaction, and try to build a game around it. You would think the outcome is a successful game with no theme, but that's not quite it in my experience. For me, it doesn't even turn into a workable game.
A lot of my designs have fallen into this trap. And I think the problem is, I see an interesting interaction of rules, and I build a game around them, but there often isn't any game there. I might call a sub-problem of this the "engine trap", where basically I build an interesting engine that the players can toy with, hoping that their doing so in opposition to one another will lead to interesting gameplay, but it just doesn't. It doesn't lead to good player interaction, there are positive feedback loops of success or failure, the whole thing ends up feeling like its playing itself, or its just not fun for some reason.
I had a game design (lets call this Mistake Explanation #4) where you were a scientist/wizard who was collecting body parts and workers and buildings, and using them to create zombies, which could be used as workers, and made money for more buildings, all powered by some kind of drafting mechanic (which I spent far too long in love with). Basically, one thing lead to the next, lead to the next, lead towards a victory state, and it was up to the players to grab the right stuff. But the game ended up feeling totally arbitrary and frustrating from the player side, and the player interaction was minimal at best.
It ended up feeling like sitting with your opponents at one of those conveyor-belt sushi bars, trying to get full the cheapest (god dammit, that sort of sounds like a doable game). But my point is, it was a clever machine, and you were competing, but it wasn't much of a game.
The 2-Player Monster/City Experience
Recently, its mostly been the theme trap that's been messing with me on the 2-Player Monster/City game (any name suggestions? this is getting ridiculous). I realized I wasn't getting the gameplay I wanted out of the top-down city map, and kept shrinking the board, turning the easy knobs, without looking at the root of the problem. Shouldn't it be more interesting to maneuver around the city? Why wasn't it?
I realized that I had decided on the city unit types/abilities/stats basically for thematic reasons, but not because they actually figured to lead to interesting gameplay. There should be artillery, it should have infinite range. There should be infantry, they should basically be canon fodder to slow the monster down.
Even monster rules came about this way, and I fell into traps of things that seemed to have nice synergy, but that didn't necesssarily contribute to overall gameplay. I want infantry to slow down the monster, and thematically it seems like the monster should be able to stomp right over human units, so I'll say he can kill the first unit he gets to, but then has to stop. This, lead to other decisions that were made in similarly willy-nilly ways.
This wasn't wholly responsible for the failings of the design, but it wasn't the right way to make the decisions. I wanted, at one point, for the game to be about containing the monster, but I made decisions counter to that. Artillery as a unit made no sense at all in this game, but I liked the image of artillery shooting at a monster, and in the unit went.
Solutions?
I've cone to realize that player interaction is crucial as a starting inspiration point and evaluation criteria, especially in a 2-player game, you would think. Further, I've started to see designing in terms of tensions. The core of a game is establishing tension and providing satisfying resolution. You have to create a situation where 1) the outcome is in question, and possible results fall into categories that are more or less advantageous to the player, 2) where the player is able to affect the outcome in a way that makes its resolution satisfying. I won't go into a long string of examples, but I think this is present in nearly any good game I can think of.
Conversely, games where the outcomes aren't forseeable enough to be hoped/pushed for, or where the possibility of outcomes produce tension but the resolution is so arbitrary that the player loses interest, abound - and can blame many of their problems for this failing. I was working on a list/taxonomy of game problems, and many of them fall into here in one way or another. A game with too much luck is an obvious choice, but the runaway leader problem is on a larger scale; it is an inability to maintain tension because while the short term outcomes are still predicatable and affectable, players are so far behind they aren't compelled to care.
So can your mechanics yield tension in the short term, on a move by move basis, and maintain it over the course of the game? And, on repeat plays, does the game remain unpredictable, yet controllable enough that it remains compelling. I think the double-sided loop game Chad and I worked on in Seattle last year was actually well designed in the sense that we put move-by-move tension as a first priority, but its most-pips-wins aspect eventually killed it, since the overall result no longer seemed to resolve satisfyingly (there's still something in that game).
Anyway, this has gone on quite long enough, I'm going to try to rethink this monster game drastically, get back to the kinds of tensions I'm trying to build, and make my choices around supporting them. Interestingly enough, I think there might be futures for both the top-down and side-scrolling games - at least if I get stuck on one I can work at the other for a bit. Cheers to you if you read this far!
Thursday, August 30, 2007
Mistake 3: The Hand Passing Mechanic
Years ago, I spent a week's worth of inconsequential grad class sessions pondering the idea of a hand-passing game. The basic idea was that you had a hand of cards, each of which could be played to achieve some effect. At some point, you would pass your entire hand to the player on your left, thereby affecting their choices.
The Appeal
At the time I created this game, I was mired in creating game systems that had interesting interactions with the player, but didn't necessarily provide interesting opportunities for interactions between the players. I was finding ways to force this back in.
What a nice, fundamental way to affect someone else than to wholly provide them with all of their options. You would have to balance what you wanted to do against what you were providing them with. You could theoretically set them up with dangerous situations, different combinations of cards that might be disadventagous to their paticular situation.
The Office Idea
The original concept I used for this was that cards were tasks to be performed in an office. The board was, predictably, an office, with a series of spaces representing rooms. Each card told you a place you had to be, and a number of negative points (effort) that were incurred by playing that card. Your goals was to make a move that caused you to move onto another player's token, at which point you could shirk all (or some?) of your cards onto them, absolving yourself of the need to actually take on the negative points you would have gotten if you had played them yourself.
The Problem
Well, the basic problem was that there was no real game here. It was a cute idea, where I lept onto a conceit that took advantage of it, but nothing in terms of gameplay or fun really emerged.
More fundamentally, the problem with this mechanic is decision trees. You have enough on your plate worrying about you want to do, to have to get into another player's shoes, figure out what they want, balance not giving it to them against what you want. Its too much, especially in what is supposed to be a light game. It's not any fun.
Is the idea salvagable? I think maybe so, but I need:
* Very simple cards, which other players might be forced to use
* Your primary goal needs to be to mess other people up. If you're going to have to spend all this time looking at what the other players are going to do, that should be the main thrust. That's hard enough to play your moves, planning what someone else might do is really, really hard. It can't be something that you do as a side goal to advancing your own options.
I'm not sure what that would look like. I'm picturing something like Roborally, where you pass move cards to a player, trying to force them to hurtle into bad situations.
But how much control does the recipient have when they receive cards? If they can order 7 cards as they see fit, its pretty tough to really overtly enact your will on them in any effective way.
And is it any fun to have something forced on you this way?
My verdict for now: its an idea that sounds nice, but its flawed. Its a bad combination: you make basic choices, while another player makes the final choices. Trying to make that fun for the passing player is potentially impossible, and if you succeed, the recieving player is making false "final" decisions, and may not be having any fun.
Maybe its a thematic switch we need. Maybe you pass cards to a player who makes final choices with them, about *your* piece. But still, not all that fun.
Still a nice idea to have in the arsenal, just in case a situation ripe for it arises.
The Appeal
At the time I created this game, I was mired in creating game systems that had interesting interactions with the player, but didn't necessarily provide interesting opportunities for interactions between the players. I was finding ways to force this back in.
What a nice, fundamental way to affect someone else than to wholly provide them with all of their options. You would have to balance what you wanted to do against what you were providing them with. You could theoretically set them up with dangerous situations, different combinations of cards that might be disadventagous to their paticular situation.
The Office Idea
The original concept I used for this was that cards were tasks to be performed in an office. The board was, predictably, an office, with a series of spaces representing rooms. Each card told you a place you had to be, and a number of negative points (effort) that were incurred by playing that card. Your goals was to make a move that caused you to move onto another player's token, at which point you could shirk all (or some?) of your cards onto them, absolving yourself of the need to actually take on the negative points you would have gotten if you had played them yourself.
The Problem
Well, the basic problem was that there was no real game here. It was a cute idea, where I lept onto a conceit that took advantage of it, but nothing in terms of gameplay or fun really emerged.
More fundamentally, the problem with this mechanic is decision trees. You have enough on your plate worrying about you want to do, to have to get into another player's shoes, figure out what they want, balance not giving it to them against what you want. Its too much, especially in what is supposed to be a light game. It's not any fun.
Is the idea salvagable? I think maybe so, but I need:
* Very simple cards, which other players might be forced to use
* Your primary goal needs to be to mess other people up. If you're going to have to spend all this time looking at what the other players are going to do, that should be the main thrust. That's hard enough to play your moves, planning what someone else might do is really, really hard. It can't be something that you do as a side goal to advancing your own options.
I'm not sure what that would look like. I'm picturing something like Roborally, where you pass move cards to a player, trying to force them to hurtle into bad situations.
But how much control does the recipient have when they receive cards? If they can order 7 cards as they see fit, its pretty tough to really overtly enact your will on them in any effective way.
And is it any fun to have something forced on you this way?
My verdict for now: its an idea that sounds nice, but its flawed. Its a bad combination: you make basic choices, while another player makes the final choices. Trying to make that fun for the passing player is potentially impossible, and if you succeed, the recieving player is making false "final" decisions, and may not be having any fun.
Maybe its a thematic switch we need. Maybe you pass cards to a player who makes final choices with them, about *your* piece. But still, not all that fun.
Still a nice idea to have in the arsenal, just in case a situation ripe for it arises.
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.
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.
Subscribe to:
Comments (Atom)