System Design Tips

Recently, my friend and fellow dev, Dan Miller (https://linktr.ee/fraculation), posted in a Discord server we both hang out in and linked to this Reddit post, The Systems Visionary Trap. Dan lamented his own struggles with getting stuck over-engineering systems games. 

In my own experience, systems games take longer to develop and “find the fun”. They are harder to pin down in the prototyping phase than something more action-based. A common story from developers who work on big systems games, like 4x strategy games or complicated city sims, is that their games aren’t fun until very late in development, when every planned system is working together.

Unfortunately, as indies, we often don’t have the luxury to take that long for our games to be fun. To succeed, we need to build small-scope games that are easy to grok and offer something novel. That requires finding the fun quickly in the prototyping phase of development. 

I think it is a mistake to describe The Systems Visionary Trap as an engineering problem. The key to solving the problem is to develop stronger design sensibilities to guide the approach to engineering. When you know what features are needed to iterate and find the game’s design it is easier to execute on the engineering without falling into wasteful architecture traps. 

In response to Dan’s posts and the larger Discord discussion, I offered some tips that have helped me rapidly prototype systems games. Here they are with some further editing and a few added tips: 

1. Split the design into modules of subsystems. The more each module can be fun and tested by itself, the better. Later, you can stitch them together. Often, you can use placeholders for mechanics from other systems before they are ready. For example, give the player 10 gold each day automatically if the trading system to sell goods isn't finished yet.
2. Be chunkier. Be more like board games. The less stuff, the easier it is to reason about. Think about the feel or process you want to invoke, and use the smallest numbers and least complex systems to get that across. Scale things up later when you have a justification.
3. Avoid procedural generation early in development. Hand author everything temporarily so that you have less random noise during testing and have fewer systems to maintain.
4. If you are making a game with multiple play styles, build only one play style to begin with. For example, if making a deck builder, just make one deck work for now and keep different decks in your back pocket for later. If you are making an RPG, only build one class. Working on multiple play styles at once can create a lot of noise in playtesting and make it harder to parse what’s wrong with the core systems of the game.
5. Try to design as "orthogonally" as possible. Build stuff that doesn't overlap much so you can learn a lot quickly and set up pillars of the design faster. Also, the game will be more fun and support stronger theming when each mechanic feels different. Example: if we were prototyping Pokémon status effects, only build the Poison effect and not the Burn effect. Both status effects do damage each turn and essentially behave the same. They fail to have a unique identity from one another. If the design does call for subtle variants, don't bother making them until later in development. It's better to implement 2 different mechanics than 20 similar ones.
6. Don't start by designing an endless game. That's too difficult to balance in the prototyping phase. Every playtesting session will end with your player being bored and quitting at the end, because the rough design of your prototype is inevitably imbalanced and can't support the weight of continuous play without limits. This is disheartening and spoils your test data. Instead...
7. Introduce phases to your game that don’t get looped. Novice designers know they should make a game with loops. Sometimes, in their focus on establishing a loop, they often make something so simple or repetitive that it is uninteresting. Players love games that have a beginning, middle, and end that feel different from each other. Hence, the popularity of phrases like “early, mid, and late game” when discussing strategy. Games with this property have more narrative potential, more drama, and invoke a sense of time. Add mechanics that enforce change in state over the course of the game, and get these quickly into the design.
   
8. In terms of engineering, build the minimum of what you need to do the above stuff to start. Scale up later. More than likely, the extra features and ideas you are planning will be cut or changed anyway as you learn more about the core of the game. There's an art to engineering things to be extensible in ways that took no extra time to add, versus other ways that are ultimately a waste of time because they end up never used.
9. If programming makes you slow at doing design work, consider doing paper prototyping instead. Personally, I’ve reached a competency at prototyping mechanics in which I can work more quickly and efficiently than if I were working with a paper prototype. Building skills to support being that fast is a valuable investment. It's a different set of values than doing the engineering for a full game. In the meantime, however, doing paper prototyping might level up the design sensibilities you need to get better at not getting stuck in engineering traps.