Tuesday, November 24, 2015

Writing Every Day 19: Simplification

Game design requires a tricky balance between simplification and complexity. In general you want to present a rule in the most straightforward manner possible so it is easy to remember and understand. I've mentioned before the workload a Game Master has while running the game. Simple and memorable rules mean the Game Master can keep more of them in his or her head at the same time, reduces confusion, and helps a game run smoothly.

On the other side of things, oversimplification doesn't provide as satisfying of an experience. A mechanic that strips things down to the barest of bones and doesn't allow for variation is dull and contributes to a less immersive experience. What's a designer to do?

One step I try to take when working on rules is to look at the number of component parts a single rule requires, often expressed by the number of rolls it requires a player to make. Almost always I'm of the opinion that a roll should only be required if failing that roll would have some kind of consequence for the character or characters attempting it. Sometimes the consequence is as simple as an inability to perform the desired action, other times the consequences can be much more dire.

If I spot a rule that has a bunch of different parts, I look for ones that can be combined or revised or handled with a prerequisite. Off the top of my head, I wouldn't ask a player who wants to read a book for a roll to see how well the PC comprehends the information within it. Unless it was some kind of Lovecraftian book that imperiled the character's health or sanity, I wouldn't ask for a roll at all. When a PC fires a pistol, I don't have the player make separate rolls for target acquisition, sighting the pistol, and firing. All of those steps are covered in the attack roll; a failure might indicate the PC fails at any one of those steps along the way, and tracking which one is rarely useful.

At their heart, all the rules in an RPG are abstractions that allow the players to work together under the same set of assumptions. They tell us that PCs with equivalent stats or skills are on roughly equal footing in regards to what those stats cover (barring rules that introduce exceptions, of course). If two PCs with perfectly matching Strength stats and appropriate skills attempt the same action, they should reasonably expect to have the same odds of success or failure. If that's true, the level of abstraction that apply to those rules are simply discovering the point at which the players are comfortable with the existing complexity. I feel that our goal should be to get as close to oversimplification as we can, without crossing that line.

Here's a good example of what I mean. There are numerous items in my home game that provide bonuses to particular types of rolls. In early versions of the game, each item's rules were developed independently of the others, creating a list of numerical benefits from +1 to +10, all based on how "good" we felt that item was. This drove me absolutely batty. I could never remember what benefit a particular item gave on its related rolls and couldn't present situations and challenges appropriately. After some deliberation, I decided to scrap these scattershot benefits and start again.

My first instinct took me deep into the territory of oversimplification. Every item provided the same bonus, differing only on the type of action they benefitted. It simplified things, but homogenized them as well and took some of the vibrancy out of the player's options. Fortunately I discovered this during the revision phase and it never saw a moment of playtesting. After some work, I landed on three broad bands of quality: Simple, Advanced, and Expert. Simple items provided +1 to related rolls, Advanced +3, and Expert +6. That wasn't all, though.

Breaking items into those three bands only made things three times more complex than the mono-benefit I'd decided was too dull. Fortunately this is a roleplaying game and not a board game, so I was free to introduce a different kind of complexity to the items: narrative and conditional benefits. I drop descriptions of how each item functions in addition to the static benefit it provides, as well as figuring out ways for items to circumvent other rules to give a richer, more immersive experience to the players who chose those items.

As an off the cuff example, let's look at two rifle scopes under this system, I'm making up the narrative portion of the rules as I go, so they're probably not what I would end up with after some revision, but it will give you a decent idea.

Scope, Digital Magnification (Simple)
Cost: Money
Description: This scope uses digital magnification to zoom in on distant objects, greatly magnifying their perceived size. A simple digital magnification scope can increase the size of an object by XXX times, allowing the user to spot objects at a far greater distance than normal.
While using this scope, a character gains a +1 bonus to aimed shots and ignores the penalty for shooting at targets beyond a weapon's effective range.

—versus—
Scope, Thermal (Simple)
Cost: Money
Description: This scope provides minor magnification and can detect and translate infrared radiation, allowing the user to see the relative temperature difference between objects. Warmer objects, like body heat or the heat produced by a vehicle's engine are brighter and warmer-colored, while cooler objects like concrete are cooler-colored.
While using this scope, a character gains a +1 bonus to aimed shots and living characters do not gain concealment against him.

That hastily-written example should give you an idea of the level of complexity I shoot for when we start testing out a new item in my home game. Some things will be added to answer the questions players bring up ("How far is a greater distance?" or "How sensitive is the thermal scope to temperature variation" come to mind).

Those questions will add back in complexity until testing reveals that an item is trying to do too much. Some things will be removed as rules and folded into the general description of the item. Others will persist as rules. Eventually the item will find that sweet spot between being simple, with just enough complexity to make it interesting.


No comments: