(Re-)Questioning Assumptions [pt. 1]

When designing something, you must listen to other people. Sometimes. Other times, you must ignore them. And other times, you have to do both at the same time.

The goal for Infinity was for the mechanics to be simple, direct, and obvious. And, back in the beginning, they were.

When I first posted the rules, people said that my 3-based Success mechanic was too complicated (as it was easier counting by 5 than counting by 3). I listened, and changed it to a 5-based. Unfortunately, that required changing a lot of other mechanics. These changes made the game less simple, indirect, and un-obvious. They added to the complexity budget.

The game, as it stands, has some features I think are really neat. Some I came up with, some suggested by others. But it’s too complicated. In order to streamline, I need to move back towards my original mechanics, which necessitates a return to 3-Success.

I’ll explain that model in part 2.

The Price of Magic

Magic is supposed to be evocative and wondrous, but often it’s as thrilling as using a paperclip.

Neat, clean “fire and forget” spells are b-o-r-i-n-g. They’re a tool, just like a flashlight, and about as involving.

In some systems spells have drawbacks — penalties attached to their use. But ad hoc, arbitrary consequences attached per-spell, with no consideration for cosmology or worldbuilding, are also boring. They are meaningless.

A great magic system has a cost, a price that must be paid, and it’s a price that ties into the cosmology of the setting. The setting is reflected in the magic, and by learning of the magic, you learn more about the setting.

One great example is Call of Cthulhu’s Insanity. Now, “Lose 1d4 SAN” isn’t interesting all by itself — that’s just a dry mechanical description. (But even that is more thrilling than some systems.)

But the consequences of actual insanity — becoming paranoid, depressive, manic, whatever — is interesting. The notion that magic warps your mind, makes you slightly insane at first, then more and more insane as you use it more, is compelling, especially in terms of role-playing a character. How do you play a man who is losing his mind? And the mind-warping power of magic ties into the nature of existence in CoC: human minds cannot grasp the truths of eality, and trying to do so drives you insane.

Magic then becomes not an add-on rules set, but an integral part of worldbuilding. Done properly, it enhances everything else in a setting. (As is the case with both Shadowrun and Earthdawn.)

Magic should always have a price (and not just because of game balance). Whether it’s a sacrifice involved in acquiring the power (losing an eye and hanging on a tree for ten days), learning the power (going insane), or utilizing it (blasting the vegetation around you to dust), there should be some cost involved.

Ideally, the price should be colorful, present some roleplaying opportunities and challenges, and be tied into the cosmology of the setting. This “price” is what makes magic involving.

Magic, how you use magic, and what magic you use should be choices with consequences. Choices are the core of roleplaying, and when magic is fraught with uncertainty, those choices are more meaningful.

The Importance of Naming Mechanics Properly

So, after a great deal of debating and hemming and hawing, I’ve decided to go ahead and rename Fatigue — I’m now calling it “Stress”.

Why? Names matter.

“Fatigue” is the word we use to mean we’re tired or exceedingly sleepy. And what happens when we’re tired? We go to sleep.

Ergo, gaining Fatigue = going Unconscious. Period. That’s what people will expect it to mean, based solely on the name itself.

But my mechanic doesn’t do that. (For good reasons, both mechanical and biological.) And even explaining why it doesn’t  — by including a sentence that says ” ‘Fatigue’ isn’t just fatigue, it’s also X, Y, and Z” — doesn’t counteract the expectation. A “Fatigue” mechanic that doesn’t lead to Unconsciousness will always feel wrong.

On the other hand, “Stress”, in the colloquial meaning, we associate with insomnia — compulsive wakefulness. Bad shit happens, you’re stressed, and you stay awake worrying about it.

Add to that the neurological reality of stress — your body releasing some very funky hormones — and how shock works, plus heat exhaustion and the other physiological realities the mechanic addresses, a “Stress” mechanic that doesn’t lead to Unconsciousness works just fine.

(More, since those other physiological problems are stressors that cause stress, in addition to their other effects, having “Stress” be the word to collectively describe all of them actually makes sense, medically speaking.)

Renaming “Fatigue” to “Stress” doesn’t change a single concrete aspect of the mechanic. But because “Fatigue” will always feel wrong, and “Stress” will feel right, the name must change.

Names matter. They are a game mechanic’s first impression — all later experiences are colored by the name. You never have a second chance to make a first impression, and a mis-named mechanic will always seem off, even if it works as a game mechanic.

Human Ingenuity and Design

Humans are endlessly inventive. They have an astounding ability to achieve the incredible by using resources in ways no one else ever imagined.

This manifests in bad ways, such as prison jailbreaks and computer hacking. It also manifests in amazing ways.

The Original Macintosh is a collection of articles discussing the lengthy (and painful) process of designing, engineering, and programming the original 128k Macintosh. Some of the stories are funny, some tragic, but most showcase a group of driven programmers and engineers working relentlessly on a project that would — literally — change the world.

For sheer ingenuity it’s hard to beat the story of the Thunderscan, which managed to turn a dot matrix printer into a document scanner. “Using resources in ways no one else ever imagined.” This is it.

How do you make a mouse work with a computer that lacks the hardware to communicate with a mouse? You cheat.

With 128k RAM, memory constraints are constant. Ruthless management of system resources was a must, and it required unusual solutions.

The above are just three of the stories in the collection. There are many more.

Some caveats: The stories aren’t always highly engaging, and they assume a level of technical knowledge not everyone possesses. Still, if you find “making of” documentaries fascinating, this site is an in-depth collection of “making of” stories about one of the landmarks in computing history.

[Note: For all the dirty, dirty Windows users out there, I know that computing and engineering talent appears in many places, not just Apple. Microsoft has many very talented programmers and engineers, and their stories are just as interesting and inspiring. No slight intended. You know, other than calling you “dirty, dirty Windows users”. :)]

Black Depths, pt 5: The Complexity Budget

There are now two main types of damage, Lethal and Non-Lethal. Lethal damage causes Fatigue and Wounds (both of which can kill). Non-Lethal damage impairs the target and can render them Unconscious.

All 3 effects interact in a simple, but interesting way. Enough Fatigue, and you become Impaired. If, while Impaired, you take a Non-Lethal Attack that also Impairs you, you become Incapacitated. And if you take enough Wounds to be Impaired again, you go Unconscious.

The three mechanics have been simplified from their original versions. I’m hoping that the three simplified mechanics can work together without becoming burdensome.

Complexity can be visualized as a “cost”: the more complex the rule set, the harder it is for people to learn and implement a rule. Each game has a complexity budget, and you have to choose carefully what you spend complexity on. Why, then, do I have three types of damage effects?

Wounds are killing damage, the primary effect of combat. A must.

Non-Lethal damage isn’t as obviously necessary, except for the ubiquitous role of knockout attacks in movies and hand-to-hand combat. Being able to conk someone unconscious is so cinematic, the mechanic had to be there.

Fatigue is the least obvious of the three, especially Fatigue that doesn’t lead to unconsciousness. The reason I have to include it, is that it models so many things, and can be used in so many other mechanics, that it immediately became an integral part of the system. Use evinces utility, and I’ve been using the hell out of Fatigue.

These three damage effects are all going to be present, in one form or another. I’ll strive to make them as simple and transparent as possible, but despite the complexity they all have to be there.

[Quick aside: It’s amusing to me that these three also mimic the damage types of Torg. That was, I assure you, entirely unintentional.]

Black Depths, pt. 4: Fatigue

Fatigue, as a mechanic, represents stress, shock, and fatigue (the physiological condition). As is accumulates, people become tired, exhausted, and can even die.

Points of Fatigue are cumulative: a character with 3 Fatigue who takes 1 point now has 4 Fatigue.

Fatigue is compared to a character’s Endurance. The higher a character’s Endurance, the more Fatigue they can take before suffering penalties.

  • A character can take Fatigue up to their Endurance without suffering any penalties.
  • If their Fatigue points are higher than their Endurance, they are Impaired.
  • If their Fatigue points ever exceed x3 Endurance, the character begins Dying.

Example: A character with an Endurance of 5 can take up to 5 Fatigue Points with no Penalties. If they take 6 or more, they become Impaired. If their Fatigue ever exceeds 15, they begin Dying.

A character with a 10 Endurance can take up to 10 points of Fatigue with no penalties. If they take 11 or more, they become Impaired. At 31, they begin Dying.

Dying?!

Yes. You can really die from exhaustion. Okay, not from the exhaustion itself. But extreme and prolonged levels of exhaustion puts stress on bodily organs, which can cause a heart attack (or other organ failure) leading to death. (The Japanese, I gather, call this “Karoshi”.)

Fatigue also models heat exhaustion and dehydration, which can be lethal, as well as sleep deprivation. In other words, dying is a realistic and important part of a Fatigue mechanic.