- According to Kobold’s Guide to Board Game Design the author states that the difference between game developers and game designers are their positions in the process of a game’s creation, from inception to release. Game designers create the skeleton of the game: the theme, mechanics, game play, and initial rules of the game. Upon finishing a working draft, developers then take the game and polish it to make the game more inciting to publishers and players alike. Dale Wu, and Mike Selinker, in their review of Dominion’s mechanics and development, equated designers to book authors and developers to editors who make suggestions and revisions before the publisher.
- Using Dominion’s development as inspiration, Selinker mentions four key events that occur in game development: Initial play testing, rule setting/refining, blind play testing, and theming/titling. In the initial play test, the designers ensure that the game is playable, and lacks key flaws missed during development. Rule setting is when the rules are drafted that better interact with the mechanics. Blind testing is putting the game in front of new players to test whether they can understand the game’s mechanics and uncover any oversights. Titling and theming is developing the core metaphor or theme that the game is based around. These events to not always happen in the same order. The theming can come before the play test, and the blind test can come before key rules are developed.
3. Two key challenges that Paul Peterson mentions in game balancing is accounting for every combination of actions, and understanding the cost of each action. A large challenge in game design is ensuring that every action is balanced around so that a sequence of actions or cards, does not create an unfair situation. Doing this is time-intensive and difficult with more complex games. The solution is to test the most unfair combinations. Another challenge in game design is balancing around the cost of an action, like playing a card or taking an action. All games have an inherent cost, and I associate with risk. If the cost of an action is not justifiably high or low, actions will feel overpowered or under powered. Peterson’s solution was to lean into the imbalance, but develop around it.
4. Every player in the game should believe that they have an equal chance to win. Dave Howell cites this as one of the most important principles of game design. Without the belief, even a small one, that any and all players can win, players will psychological divest themselves from the game and become apathetic to the outcome. In short, players must feel like they can win up until the end, because if they don’t they can become apathetic.
5. There are many things designers can do to avoid stealing players’ fun. Many of them involve how players interact with each other, rather than how players interact with the game. One of these things is avoiding “Kingmaking” (allowing players to choose winners), because “Kingmaking” leaves the fate of the game to the players, which often relies on chance and not skill. Games should also not reward winners and punish losers too much, as they create situations where momentum keeps players ahead or behind. They also create situations where hopeless players grow apathetic.
6. The ten maxims Mike Selinker mentions(along with my interpretations) are:
- Use no intermediary terminology: “Call things what they are.”
- Use real words: “Make your rules understandable from the get-go, and ensure that they are consistent”
- Make no more work than necessary: “Do not over complicate core processes of the game”
- Add flavor (but not too much): “Understand how much flavor your game needs”
- Make your text no smarter than your reader: “Do not obfuscate rules”
- Discard rules that cannot be written: “If a rule is too complex to understand (or even write), remove it or alter it.
- Take a breath: “Break your text up if it is getting to long”
- Go easy on the eyes: “Make your rules readable”
- Playtest your final version: “Review your rules in a final play test to fully understand their interpretations.”
- Fix it in the FAQ: “Make subsequent clarifications later (do not ignore them).”