The most important thing when designing a game is to keep it simple and build slowly. Start with the simplest possible set of rules, play it, if the game functions (and has a hint of fun), add or change one thing, repeat. That is called iteration. But how do you know what to add/change next? Well that kind of depends on the state of the game. If the game is horribly unbalanced, then focus on making the weaker player's game stronger (give them more advantages) or weakening the strong player (take away some of their advantage). If the game isn't fun, then figure out where the fun got lost or where you think the interesting choices should be found and focus on those. If the game is playing well, but it seems to be the same game for a player (that is, if there seems to be one optimal way to play the game), then it may be time to add another system or more options for the player to take. No matter what you're adding, the important things are to start with the simplest and easiest to implement changes first and to try to avoid making special case rules for any part of the game.
If you can try a change without having to get new pieces or change game components, those should take precedence. For example, changing balancing (e.g. how much damage something deals), changing what information each player has (e.g. whether cards are revealed at certain times or not), or changing game flow (e.g. players take turns simultaneously or alternately). You should always keep in mind what future complicated systems/variations you want to add to the game (if you have pawns, maybe you would want special types of pawns) and add those in one at a time when the game is in a stable(ish) state.
Special case rules should be avoided in game design for the same reason that quick hack fixes should be avoided in programming. Sure, you may fix that one weird case your playtesters found, but not only is that fix going to be hard to communicate to your players, but what if you missed other weird cases? It's far better to try to figure out the root cause of the problem and simplify things where you can or maybe completely change how one part of your game works. It's almost always better to simplify things to fix a problem than to add more systems to fix it. As much as it may hurt sometimes, never be afraid to oversimplify things.
No comments:
Post a Comment