I am currently working on the third version of Karma in the Dark:
One of my core editing goals at this point is to create a cohesive, streamlined system for the rules. The rules will have some crunch to them, but I want it to all fit together tightly and make both mechanical and conceptual sense.
This is probably the hardest part of the design process for me. Before games, I studied architecture. My process was predictable: get a design problem, come up with some off-the-wall radical twist, create the super complicated version of my design . . . then spend 90% of my time editing: refining, streamlining, simplifying. Creative ideas are easy; elegant execution requires blood, sweat, tears, and many sleep-deprived work sessions.
Here's a classic example:
Me, the obstacles should be X or Y, but in this case, the obstacle would be Z.
Testing team: why not obstacle A?
Me: ... Okay, the obstacle is A, but when narratively relevant, it requires the same test that any skill requires in the game.
Testing team: that works!
I am currently GMing Torchbearer for the first time, and that experience is teaching me a ton about game design. I like Torchbearer. I like games that focus on creating a specific experience, and using their mechanics to insure that experience. Here's my problem with the rules, though: they require you to memorize multiple different mechanical systems, most of which have exceptions or twists.
Memorize how helps works, wises work, traits work, and don't forget persona/fate. Advancement is different for skills/abilities, leveling up, wises, traits. You roll on different random tables for camping and town. Recovery rolls are different for each condition. Also--help is different if you are using a skill, instinct, nature, or beginner's luck. And is different again when you engage the conflict system. And on and on.
All of the different systems play nice with each other, fit together, and support the intended experience...but you still need to memorize each of them, with their specific nuances. It reminds me of Shadowrun, which uses a different mechanical system for magic, rigging, decking, combat, etc.
I don't want that kind of complexity in Karma. I want there to be strategy in how you advance your team, how you use your karma, how you position yourself for you effect level, how you leverage your social connections, how you balance ideals vs. gaining more power , , , but I want that complexity and strategy to come from having to make difficult gambles, choices, or narrative positioning...not from needing to memorize excessive amounts of rules.
Here are my KISS design rules:
1) One core system. If all else fails, you can always fail back on the core system.
2) Any "special exceptions" are captured in special abilities, and can be explained concisely enough to fit in the 1-sentence space on the character sheet
3) No more than 2 parallel systems at the same time. For example, there are two forms of team advancement. They have separate nuances, but you never need to know more than "here are the two types of advancement." Similar to special abilities, the rules should be naturally reflected in the team sheet and need minimal explanation.
3) If the rules cannot be explained by straight-forward mind map, clean them up (e.g. no complex web or crossing lines)
4) Player rules can all be summarized on one cheat-sheet; GM rules can all be summarized on one cheat-sheet.
5) When in doubt, ask, "How does this rule place the players into a position to make a tough decision? How does it reinforce the two game challenges of maintaining ideals/integrity and building social currency?"
6) The rules act like scaffolding for the experience: the support a specific type of experience, but all of the details will be filled in by the narrative during play.
I am officially at the KISS design phase for Karma version 3. The rules/systems are all in place, now I need to streamline, simplify, and write the result in rulebook form. It's both a relief to declutter my rules, and the biggest challenge of the entire process.
This blog is a mix of game design analysis, commentary on issues affecting indie dev spaces, and some personal reflections.