I will attempt to try to organize my beliefs about playtesting in a chronological order over a series of posts. That will be more useful as a reference for when you run your own playtests. If you do use it, just remember that you are taking advice from someone who has never been published. Kids, don'’t try this at home.
A guiding principle of economics is that people respond to incentives. These incentives can be costs or benefits. If a strategy is too weak the most obvious fixes are that you can either add a benefit to it or reduce a cost to employ it. However, you can also (and this is what is easy to forget) increase costs for NOT employing that strategy. For example, take the action of helping build the castle in Caylus. If you wanted to increase the frequency with which players send workers to the castle, you could have increased the number of "favors" given to people who do (or the value of those favors), decreased the resources used to build a piece of the castle (either the cost of deploying the worker or the actual number of building materials), or increased the penalties given to people who have not built any of the castle at the end of each of the 3 sections of the game.
The reverse of these methods can be employed for deemphasizing a particular strategy that is seeing too much play. Before you nerf a strategy, make sure that there isn't a viable counter-strategy that is just failing to be employed. If there is, you might want to begin by incentivizing the counter-strategy before punishing the problem strategy. High levels of tension between opposing strategies are more preferable to low-stakes choices where failure to choose properly results in only small differences in game state. Of course, there is a logical limit to how important you want to make a decision to pursue one of any number of strategies (you don't want an hour-long game to be won or lost by a 30-second decision in the first round), but try to begin by adding power to one choice before removing power from all others.
The other most common change you will need to make is regarding game length. This refers both to real-world time and number of rounds. As I learned at Dreamation, the amount of time a game should last is not an absolute number, but varies with proportion to the complexity and variety of mechanics presented to the players. My game, Black Market, was taking far too long when the central action was bidding. Now, I never intended bidding to be the main part of Black Market, but the way the game played out almost nothing else was happening.
I have since made some changes to speed up the game to a more palatable pace for a relatively small and straightforward mechanic set. I increased the frequency at which the victory condition, plutonium rods, appears on the market. I also changed the bidding system from Enlgish auction to once-around. I made it so that each turn's production is auctioned as a single lot, not separate pieces. These will each have a small effect on the game length that will hopefully yield a large enough net result that more drastic action will not be necessary. Specifically, the odds of production of plutonium increased only from 33% to 42% per turn. Originally I planned to increase it to 50%, but decided to keep my changes small, even if it means having to change it again later.
This brings up an important part of making changes: KAoYIDCaSaPS. That stands for "Keep All of Your Intermediate Development Changes as Small as Possible Stupid". Not the catchiest acronym ever, but woe is the Game Designer Wannabe who fails to heed its simple creed.
Black Market had a slippery-slope problem in initial testing. Whoever made the first big sale (usually by winning an early auction) became nigh-unstoppable. They overbid every subsequent auction, controlling the markets so that they could recoup the overbids with the now-inflated market values. This happened in every single test. I grew frustrated at the inability of other players to compensate, even through collusion. So I took drastic action. I increased the starting cash by 150%, lowered the rate at which market prices increased, auctioned off production asseparatee items, raised the rate at which market prices decreased, and did not allow players to take more than one unit when they went to the market to sell.
I was successful at ending the slippery-slope problem. Every test after that the game looked great. The players immediately understood how the changes affected the bidding and selling strategies. Then the Dreamation test happened. I learned that I had overcorrected for slippery-slope and made the game stagnate. Instead of the previous over-incentivization of early high bidding, now early high bids were so severely punished that the players all managed to dig themselves into inescapable financial black holes. Now I understood the importance of KAoYIDCaSaPS. Development is for small tweaks, not massive changes.
There is a time and place for large changes. This is called design. Do not forget to understand the difference between design and development. You can send a game in development back to the design stage. But when it comes back to development you must test it as if it is an entirely new game.
I am actually considering radically changing Black Market. I want to position it as a middle-weight game, not a filler game. I have quite a few ideas for adding player decisions that affect production probabilities and a technology tree that would further encourage purchase of goods (including plutonium) for consumption purposes. First I am going to test the small changes I've made and see if this is currently a game worth playing in its own right. Perhaps I will end up being happy with Black Market ending up as a filler game. But if not and I add the complexity, I will make sure to approach testing with no assumptions about how players will act or how long the game will last that are based on my experience with the previous incarnations. To reinforce this mentally for both myself and my playtesters, I will probably rename it too.
Part 1 - Create a Playtest TeamLet's assume that you've realized that your prized creation is actually a hideous cardboard abortion, or at least that's what your testers are calling it. Your notes from the test and the feedback should provide you a list of things that need to be changed. Most often these changes will be of the sort "this strategy is too weak/powerful". Thankfully, these are the easiest changes to make.
Part 2 - Organize a Playtest Session
Part 3 - Introduce the Game
Part 4 - Play the Game
Part 5 - Get Feedback
Part 6 - Make Changes
A guiding principle of economics is that people respond to incentives. These incentives can be costs or benefits. If a strategy is too weak the most obvious fixes are that you can either add a benefit to it or reduce a cost to employ it. However, you can also (and this is what is easy to forget) increase costs for NOT employing that strategy. For example, take the action of helping build the castle in Caylus. If you wanted to increase the frequency with which players send workers to the castle, you could have increased the number of "favors" given to people who do (or the value of those favors), decreased the resources used to build a piece of the castle (either the cost of deploying the worker or the actual number of building materials), or increased the penalties given to people who have not built any of the castle at the end of each of the 3 sections of the game.
The reverse of these methods can be employed for deemphasizing a particular strategy that is seeing too much play. Before you nerf a strategy, make sure that there isn't a viable counter-strategy that is just failing to be employed. If there is, you might want to begin by incentivizing the counter-strategy before punishing the problem strategy. High levels of tension between opposing strategies are more preferable to low-stakes choices where failure to choose properly results in only small differences in game state. Of course, there is a logical limit to how important you want to make a decision to pursue one of any number of strategies (you don't want an hour-long game to be won or lost by a 30-second decision in the first round), but try to begin by adding power to one choice before removing power from all others.
The other most common change you will need to make is regarding game length. This refers both to real-world time and number of rounds. As I learned at Dreamation, the amount of time a game should last is not an absolute number, but varies with proportion to the complexity and variety of mechanics presented to the players. My game, Black Market, was taking far too long when the central action was bidding. Now, I never intended bidding to be the main part of Black Market, but the way the game played out almost nothing else was happening.
I have since made some changes to speed up the game to a more palatable pace for a relatively small and straightforward mechanic set. I increased the frequency at which the victory condition, plutonium rods, appears on the market. I also changed the bidding system from Enlgish auction to once-around. I made it so that each turn's production is auctioned as a single lot, not separate pieces. These will each have a small effect on the game length that will hopefully yield a large enough net result that more drastic action will not be necessary. Specifically, the odds of production of plutonium increased only from 33% to 42% per turn. Originally I planned to increase it to 50%, but decided to keep my changes small, even if it means having to change it again later.
This brings up an important part of making changes: KAoYIDCaSaPS. That stands for "Keep All of Your Intermediate Development Changes as Small as Possible Stupid". Not the catchiest acronym ever, but woe is the Game Designer Wannabe who fails to heed its simple creed.
Black Market had a slippery-slope problem in initial testing. Whoever made the first big sale (usually by winning an early auction) became nigh-unstoppable. They overbid every subsequent auction, controlling the markets so that they could recoup the overbids with the now-inflated market values. This happened in every single test. I grew frustrated at the inability of other players to compensate, even through collusion. So I took drastic action. I increased the starting cash by 150%, lowered the rate at which market prices increased, auctioned off production asseparatee items, raised the rate at which market prices decreased, and did not allow players to take more than one unit when they went to the market to sell.
I was successful at ending the slippery-slope problem. Every test after that the game looked great. The players immediately understood how the changes affected the bidding and selling strategies. Then the Dreamation test happened. I learned that I had overcorrected for slippery-slope and made the game stagnate. Instead of the previous over-incentivization of early high bidding, now early high bids were so severely punished that the players all managed to dig themselves into inescapable financial black holes. Now I understood the importance of KAoYIDCaSaPS. Development is for small tweaks, not massive changes.
There is a time and place for large changes. This is called design. Do not forget to understand the difference between design and development. You can send a game in development back to the design stage. But when it comes back to development you must test it as if it is an entirely new game.
I am actually considering radically changing Black Market. I want to position it as a middle-weight game, not a filler game. I have quite a few ideas for adding player decisions that affect production probabilities and a technology tree that would further encourage purchase of goods (including plutonium) for consumption purposes. First I am going to test the small changes I've made and see if this is currently a game worth playing in its own right. Perhaps I will end up being happy with Black Market ending up as a filler game. But if not and I add the complexity, I will make sure to approach testing with no assumptions about how players will act or how long the game will last that are based on my experience with the previous incarnations. To reinforce this mentally for both myself and my playtesters, I will probably rename it too.
No comments:
Post a Comment