Yesterday, I talked about about "Why use a new system?" Today, I want to talk a little about the other half of the discussion. Why make a new system? When is it worth the effort?
If you're making something for yourself, then the answer is simply: when you want to, because you want to. I enjoy making systems and experimenting with them. If you're remotely interested in game-design, there's no better way to start than to start.
If you're making a system with other people in mind, then the situation changes some. So, when is this a good idea? A discussion on the Story Games forum provides some insight. The ever-knowledgeable Eero writes:
"I generally create a new system for one of two reasons: either I want the small, tight, to-the-point experience that only a highly specific custom job can provide, or the manner of play I'm envisioning has not been evocatively presented in a prior system, and I thus need to write a new one."
I've argued before about mechanics being inherently representative of the game-world, and that's usually the baseline criteria I have. If I'm going through the effort to write a new system, it's because I am looking for fiction to be defined and experienced in a way that I don't get from an existing system. You write a new system when no current system adequately facilitates the kind of experience you want to have.
When designing a new game though, you might not need a new system at all. If your focus is on setting or genre, and you don't have specific ideas about the mechanics or mode of play, then you may just want to look at something like Savage Worlds, or even Apocalypse World. If you have more retro-tastes, look at some of the OSR games that were published specifically with the intentions of allowing new people to produce content for old games. OSRIC is a great example. After having really fooled with B/x for a while, I can honestly say a number of game concepts I've had over the years would work just fine on that platform with a little tweaking. Lamentations of the Flame Princess is a brilliant example of this.
That creates the second point of discussion, iterative game design vs designing from first principles.
In iterative design, you begin with a basis of some other system or concept, and continue making tweaks and changes until you have arrived at your desired result. The Burning Wheel family of games are a good example of this, as Torchbearer and Mouse Guard have a lot of shared mechanics with Burning Wheel, but are indisputably separate games. This actually brings up the Ship of Theseus. How many planks can you replace before it's a different ship? At what point of tweaking have you created a new game? Is LotFP inherently a new game, or is it an elaborate modification? It's something of a moot point, only important insofar as it illustrates that "new design" vs "existing system" is a smooth gradient, rather than a hard dichotomy.
It is not a false dichotomy, however, as you do have the choice of designing from first principles. In this mode, you are starting from scratch. Literally "I want to use a handful of d10s" scratch. In this case, you're completely free to push things in whatever direction you wish.
In most cases, you're actually better off working with iterative design. This is especially true when you're either relatively inexperienced in designing a game, or a system you're already familiar with does a reasonably good job on its own. This is also extremely handy as a process when you've already built a system from scratch, but want to tweak it towards a specific end (see: Burning Wheel, Lamentations of the Flame Princess, or Blade of the Iron Throne).
Sometimes though this approach can actually hold you back. Working iteratively keeps you in some ways tied to basic assumptions from the original design. When these assumptions become a constraint, you need to be willing to toss out whatever you need to make your mechanics work.
This is actually what happened to us in Band of Bastards. Like Blade of the Iron Throne, we began as an iterative hacking of The Riddle of Steel, but halfway through the process we realized the origional chassis were holding us back. Instead, we wound up tossing out everything and began again from first principles.
Designing from first principles is way more work, but you get a ton of valuable experience out of it and have more flexibility than you otherwise would. This is especially important for games where you want to change the actual mode of play from other default assumptions. Starting from a blank slate is a huge boon to creativity. This is also an excellent place to play with design for design's sake. I have a handful of mechanics that are floating around in a notebook looking for an excuse to use one day, with no immediate game idea in mind. I recommend anyone interested in game design try this at least once.
My two cents, anyway.
Until next time,