Game Design as Engineering, not Art

(from a discussion on RPG Haven)

Game design is engineering, not art.

I'm not putting a "higher" value on "art" here - that is, I don't think art is just the stuff you find in museums. I do put a value on any word. I'm a professional writer - I make a good living putting words together - and words have value. Anyway, art, any art, is an expression of the artist. The work completed is sufficient unto itself. If no one is there to hear it, that particular tree still can be heard falling, because the hearer - if there is one - doesn't matter. Games are not sufficient unto themselves. They are tools to give others the means to produce enjoyment. Treating games as art is wrong - not morally or ethically, but in the sense of it being bad for games and gaming.

I think that the reason why game design reminds you more of art than engineering is the subjective aesthetic component one brings to the game. There are a lot of valid styles of game, just as there are many valid styles of art. The discrimination - why one like this game or this piece of art instead of that - is subjective. In engineering, one can point to objective performance as criteria for discrimination.

The thing is, there are objective criteria for games too. The games must work, just as a bridge or a truck must work. The problem for judging games on objective performance is that the performance bar is very low. In other words it's easy to design a functional game. So we turn to secondary, aesthetic discrimination. Like a bridge, a game can aspire to beauty as well as functionality, and standards of beauty are notoriously subjective. But even a beautiful bridge is no good if it can't perform the fundamental job of a bridge, which is to carry traffic from point A to point B above difficulty C. An artwork in the shape of a bridge may have aesthetic appeal and merit, but it isn't a bridge. Art can only be judged by aesthetic criteria.

Thus the first and foremost duty of a game designer is to put together a working package of tools which enable others to produce whatever they wish to produce, be that art, fun, or anything in between. This is why I think it is much like software engineering. There is a high aesthetic - and therefore subjective - component in finding a program that does what you want the way you like it done. One person's bells and whistles are another person's lead weights, just as one person's intriguing fiddly bits are another person's absurd minutia. Yet software engineering, like game design, is an engineering discipline, not art.

-clash

Chargen and Character Advancement

Most gamers, when they ask what a system is like, mean "What's the task/conflict resolution system like?" To me, the resolution mechanics are peripheral. The most important part of any system to me is chargen and character advancement.

In most games, those are two completely different things, totally unrelated. You roll/pick your stas & skills, equip your character, and play. To me, they are inextricably linked. It all ties back to two games which I consider the most personally influential and also most innovative - remember yesterdays post? I mean innovative like that! - game designs ever; Traveller and King Arthur Pendragon.

Among other things, Traveller introduced the concept of Lifepath character generation. Your character took on a profession which taught certain skills. Each time period you spent in generation, you rolled what skill or bonus you received that time period. Character generation ended when you retired, after which advancement, if any, was up to the GM.

Also among other things, Pendragon introduced the concept of a yearly cycle. You went out and adventured each spring, and returned home in the fall to take care of the home front. Everything was year-based - you knew how old you were, how old your children were, and your wife. You advanced your character each year, becoming more skilled, more powerful, and more famous.

I loved this!

When I designed my first game, I combined the two. Now both chargen and advancement were year based. You could stop chargen at any point, play out a year or two, chargen another few years, and play five more. This sub-system pretty much defines my games. The entire meta-system framework revolves around it. I started with random chargen, then mixed in point-buy for stats and background, and then introduced template characters, but all go through that yearly cycle. Among other things it makes flashbacks a snap.

So, a development of existing tools - no innovation for me!

-clash

Babies & Bathwater: Tradition and Innovation in Game Design

I'm a traditional game designer. That means I'm skeptical of new things - it's my job to prevent the baby being tossed out with the bathwater, and I take it seriously. This doesn't mean I reject new things - not at all! It means I insist that new things be proved before using them. When I have to step oustside of the tried and true, I do - I created the air combat system of the In Harm's Way games ex-nihilo, because there was nothing out there that would work nearly as well.

I think innovation is often confused with novelty. Innovation, true innovation, fundamentally changes the way people do things. It requires follow-up - imitation and extension - to be correctly judged. By the imitation and extension we discover that yes, this different and novel thing has fundamentally changed the approach to design. It is no longer a novelty, but is an innovation.

My air combat system is a novelty. No one has ever copied it. No one has taken the idea and extended it. Until someone does, and it takes hold, it remains a novelty and not an innovation. I hope one day that someone will do this, but until then, it's no more innovative than using a roulette wheel or a jenga tower as a randomizer.

Creativity is another thing entirely. One can be very creative in assembling and extending bits and pieces used elsewhere. Forward to Adventure! is very creative, though there's not an ounce of innovation or novelty in it. I hope my designs are a quarter as creative. I'm not in a position to judge. I can judge FtA! because I only illustrated and published it. I had no hand in the design.

-clash

Self-balancing Systems

My one great love in game rules is a self-balancing system - one which lets you push it if you are willing to pay the price, but it pushes you right back. My favorite example of this is the magic system my son Klaxon designed for The Book of Jalan.

The system was a free form one, with magic skills that could be combined, along with regular skills, into a "weave" of great complexity, but that wasn't the cool part.

The caster's power and skill were treated separately. Power was inborn, but skill was learned. You could be amazingly powerful as a kid, yet you would have no control. I remember a game where the caster was able to teleport six people with his Apport skill, yet he could only Apport them a meter. That actually came in handy in an escape once...

That's cool, but that's not the self-balancing part.

To power their magic, casters burned their own stats. Each skill was associated with a physical stat - Telekinesis with Strength, Aport with Agility, etc. The more power you put into your weave, the more points it cost. Repeated casting of the same spell wore you down fast. Also the system's equivalent of HP was derived from the character's physical stats, and lowering your stat lowered your ability to take punishment. Some games, a caster had to be carried away from a scene because he was exhausted and unable to walk. One caster almost drowned in a rain because he had wiped himself out to the point where he couldn't move.

Magic wasn't permanent. In order to make an item magic, casters had to lock one of their points into the item. Thus magic items were rare, as caster seldom wanted to lock their power away out of use, and did not survive their maker. The magic dissolved when the caster died or when the caster released his power froim the item.

That's a self balancing system.

Oh, the game - I talk about it in the past tense, even though it's still on sale, as it just never sold much. It had problems, mainly the fact that the layout was perhaps my worst ever, but that magic system was very cool.

Klaxon is graduating from BC this year, and going on to get his masters in game design.

-clash

Death Spirals and Life Spirals, and the Importance of Being Stunned

Death Spiral is the internet RPG shorthand for any mechanic which uses life-status point (HP/Constitution/Life Points/etc.) thresholds to add penalties. The implication of the name is that once you start getting damaged, it becomes harder and harder to break out of the spiral, which ends in character death. At each threshold of the Death Spiral, the character's penalties for doing anything become more and more severe, to the point that any action becomes essentially futile. The goal then would, by implication, be to be the first to deal damage and lock your opponent into a death spiral while avoiding this yourself.

Contrast this to the Shop 'Til You Drop mechanic used in many RPGs. The character suffers no impairment no matter how low the life-status points drop until the character dies. This has no death spiral, but is essentially bizarrely unreal, unless Life-status points are thought of as not cuts and bruises, but abraded luck and accumulated fatigue. This goes against the convention of calling a success in combat a "hit" - a hit should mean you hit the opponent. Anything else is counter-intuitive. Perhaps using a different word - "success" or "threat" or something like that - would make it more acceptable as a model. With this change in approach, the Shop 'Til You Drop model becomes much a more reasonable abstraction.

There's also a variant on this - Shop 'Til You Fall Over. Sometimes a small negative life-status threshold is added below the zero threshold - if you hit this point, you are unconscious, with various penalties - possibly bleeding out, possibly comatose, etc.

Another mechanic used in RPGs is Buy Now, Pay Later, where the character suffers no impairment from wounds until combat is over, whereupon the bill becomes due. This is an interesting compromise between the Death Spiral and Shop 'Til You Drop. The penalties of a Death Spiral still acrue, but payment is postponed until pressing business is finished and the adrenaline wears away.

My games use another variant of the Death Spiral, which I call a Life Spiral. In this variant, your different thresholds of Life-status points trip differing conditions, not further penalties. In my games, the first threshold incurs a condition - Hindered - in which a small penalty is assessed to all actions. The second threshold incurs a different condition - Stunned or Unconcious - in which the character must make an appropriate skill or stat check in order to continue fighting. Otherwise, the character becomes disoriented and is out of action until roused by another. the third threshold - Seriously Wounded or Critical - incurs another condition in which the character falls over, cannot be roused, and begins slipping away unless tended to by another. The second threshold is a warning. You can continue, but things are getting dangerous. The third threshold is a limit. You cannot continue any further, and you may lose it all. These separate conditions serve to keep characters alive at the expense of dropping them out of combat.

Why is this a Life Spiral? Here's something anyone who ever ran an RPG knows - The Party Will Never Surrender! The only way to defeat a party is to kill them all. Consequently, the corollary to the party never surrendering is that Defeat == Death. The GM plays the opposition the way the party plays itself - the only surrender is death. Thing is, people survive losing combats all the time in real life. One side is almost never wiped out.

This brings me to The Importance of Being Stunned. Stunned characters are not responsible for surrendering. They can live without taint of cowardice or whatever it is that motivates the "never give up, never surrender!" zeitgeist which imbues PC parties. They can be captured, and they can maybe eventually escape and still win in the end. Defeat becomes temporary, not final. Since they can be captured, there's a reason for not wiping out the enemy when they are helpless - if you get a rep for killing prisoners, the enemy will do the same. If you want to live through a defeat to ultimately triumph, treat your prisoners decently.

-clash

Random Damage as Hit Location

Here's an abstraction I love. Random Damage as hit location. The higher the damage, the more vital the area hit. The lower the damage, the more peripheral the location. This works especially well when skill figures into damage.

More later!

-clash

Abstract Tactics

That post title... that's like Military Intelligence or Jumbo Shrimp, right? An Oxymoron? Ummmm.... no. I'm really going to talk about abstract tactics today. I'll wait while the room empties...

OK. Everyone out who's going to leave? Good. That leaves the sleeping wino in the corner and that confused looking foreign tourist. Lets begin.

First the definition of tactics, from general RPG usage;

1. The use of miniatures to show exact position in a conflict.

2. Fiddly maneuvers which require knowledge of exact position to work. See miniatures.

Doesn't leave much room for "Abstractness", does it?

Until very recently, with the common use of GPS tranceivers, no one knew the exact position of anyone in an actual battle. In a general sense, that group was over there, and that other group was somewhere over there, but exact position? No. Clausewitz wrote: "The great uncertainty of all data in war is a peculiar difficulty, because all action must, to a certain extent, be planned in a mere twilight, which in addition not infrequently — like the effect of a fog or moonshine — gives to things exaggerated dimensions and unnatural appearance."

So... No one can use tactics in a real military battle? Of course they can!

Now the definition of tactics from Dictionary.com

1.	(usually used with a singular verb) the art or science of disposing military or naval forces for battle and maneuvering them in battle.

2.	(used with a plural verb) the maneuvers themselves.

3.	(used with a singular verb) any mode of procedure for gaining advantage or success.

I particularly want to focus on definition 3, although all three definitions are perfectly valid. Tactics are any mode of procedure for gaining advantage or success. Nothing about exact position, nothing about clear knowledge of the battle.

Player: "I'll delay my move in order to circle around for a better shot." i.e. maneuver for enfilade.
GM: "OK, you move down to last in initiative, but you'll get +X when you go."

Player: "Joe and I will keep their heads down with cover fire while you guys rush in, then you cover us." i.e. fire and maneuver aka leapfrogging.
GM: "Cool. Let's see how good you pull it off. I'll use your degree of success as a minus for them."

Player: "Rats! They're moving before we're ready! I'll rush my shot to get ahead of them, and maybe blunt their attack." i.e. getting inside of the enemy's decision loop - maneuver for disruption.
GM: "OK, take a -X, but you'll go before them."

These are abstract tactics, using GM rulings in place of rules. No miniatures are needed, and the participants don't have a definite idea of their opponents' disposition, but they are real tactics.

As designers, we can create rules for abstract tactics, taking the load off GMs by making ad-hoc rulings less frequent or unnecessary. By assuming a combat round of flowing maneuver rather than a static slugfest, and making rules to enable this, combat can be exciting without minis and grids.

Here's some techniques I use for abstract tactics:

1. Make combat rounds longer - I use one minute rounds to have time for maneuver.
2. Assume a lot goes on that's not detailed. Most shots fired in combat have no chance of hitting, In swordfights most swings are blocked and aren't ever going to connect. In a long round, I assume bullets are flying everywhere, sword blows are parried like lighting, and there's no need to roll because they are never going to hit anything. Players only roll when there is a decent chance that their shot will hit - i.e. their initiative.
3. Allow free maneuver - in a long round, you can move a long way. Only roll for skill checks when something difficult is attempted. If you're going to use gymnastics to vault an opponent to get behind him, you roll. Circling to the flank unopposed won't - it just takes time.
4. Use initiative as a tool. I allow trading inititative for bonuses or minuses - rushing a shot gains a minus. taking longer for maneuvering gains a plus.
5. Make cover count. I use abstract modifiers for cover - that cover might be worth a -25% penalty, or -2 dice, or whatever is appropriate - so I don't have to know the terrain, and neither do my players.
6. Make firing for supression worth doing. Using your initiative to provide cover for your buddies should gain you tangible benefits. I base those benefits on the degree of success the supression has.

Now what works in your games can be very different, but these techniques work fine in mine. Combat zips along, and it's still fun and flexible.

-clash

Frontloading and Backloading

All games systems are abstractions, like maps. They reduce an intricate, exceedingly complex and chaotic world to simple, easily handled abstractions. The degree of abstraction varies from system to system, but compared to the initial abstraction of any game from what that game represents, that range is exceedingly narrow. Even so, people have differing tolerances within that narrow band.

Today I'm babbling about two opposed techniques for dealing with abstraction - Frontloading and Backloading. Statistically, they are equivalent, but perceptually, they are very different. The difference lies in where certain operations occur in the game.

Frontloading - This is the practice of putting certain statistical abstractions into the down-time or non-play phase as opposed to in-play. An example of frontloading is armor making a target more difficult to hit.

Backloading - This is the practice of putting certain statistical abstractions into the in-play phase as opposed to down-time. An example of backloading is armor absorbing or reducing damage.

Statistically, these examples are pretty much the same. Over repeated instances, the average damage sustained by the target with either method, all other things being equal, should be very similar; with the similarity increasing with more instances, and thus a better data set. Pereptually, as any gamer will shout passionately, they are totally different!

What armor does is reduce damage to the target. That is so obvious it almost goes without saying. Therefore backloading is the right answer! Correct? Well, it's the obvious answer. Backloading increases handling time in-play. Each time damage is sustained, it must be reduced before applying it to the target. By frontloading this reduction, we can decrease handling time, making for faster combat.

Frontloading damage reduction directly is really awkward, due to the variety of weapon/armor interactions, and the random nature of damage. A more elegant solution is to change the chance to hit in the first place. "Heresy!" you say. "Armor doesn't make you harder to hit! it makes damage less lethal!" True, but we are abstracting here. By making armor harder to hit, we reduce damage indirectly over time. The average amount of damage sustained by the target can be reduced because less hits occur on the average per round, because even with the same amount of damage per-hit, by lowering the average amount of hits, you lower the damage sustained over time. This, however, is not intuitive to the gamer. We have, in effect, redefined "Hit" from "anything which touches the target" to "Anything which touches the target and does damage."

So in general, frontloading decreases handling in-play but increases perceived level of abstraction. backloading decreases perceived level of abstraction but increases handling in-play. The choice is up to you, but both are valid choices.

-clash

System Structure

This is my first blog post, and as I swore repeatedly that I would never have a blog, it's pretty humiliating. Whatever. This blog isn't about me, it's about games.

Systems have akways fascinated me. I came into RPGs from wargames in 1978, where kit-bashing and rolling your own were common activities. I carried that over into roleplaying. I have little use for innovation in gaming. Innovation, in my opinion, should only be used when tried and true methods are not working properly. That said, it's due to innovation that there are any tried and true methods.I admit that. My position generally is let someone else do the innovating. Innovation generally invokes failure. Messy, catastrophic failure. I like to avoid that if possible.

Now innovation does not equate to creativity. I have lots of use for creativity! Applying tried and true methods creatively is what I strive for. To me, designing RPGs is not an art, but a craft - first of all is usefulness. Anything else is secondary. I'm trying to build a nice chest of drawers here, not sculpt a stunning piece of art. Unfortunately, like Herodotus, I tend to digress. Let's get back on track.

A game system is an assembly of rules and supporting structures which enable a game to be played. I know of four structural models for creating systems:

Accretive - This is the way the first RPGs were created. Rules are added ad hoc to the existing rules as problems are encountered. Each problem has a separate but equal solution, and exceptions are handled via judgement calls. Rules inter-relate in strange and unpredictable ways. There is a lot of flavor inherent to this model - quirky, messy, and interesting.

Disappearing - This model emphasizes one central mechanic which is applied throughout. Problems encountered are resolved by application of this mechanic, with exceptions resolved by non-mechanical means via a combination of consensus and judgement calls. This model yields games which are simple to learn and easy to internalize, so that the rules tend to become background noise.

Thematic - This model emphasises a set of related co-dependent mechanics which are generally applied by the players directly rather than through the medium of the characters. Problems encountered are resolved by applying these mechanics to change the nature of the problem on a metagame level until the problem essentially resolves itself, reducing or eliminating the need for exception handling. This model works best when applied to sharply circumscribed initial value sets, due to less effort being needed to shape the problems encountered so as to fit the ruleset.

Framework - This model is a set of abstract interfaces, to which modular sub-systems can be attached if they have matching interfaces. Sub-systems return a value which can be handled by the framework. Problems are resolved by application of a sub-system, with exceptions handled by other sub-systems added as needed. This model necessitates a high degree of abstraction, due to the need to standardize interfaces, but is extremely flexible - both in application and in design.

All these structural models have advantages and disadvantages which are inherent to the nature of their structures. None are inherently bad or good, as their value is entirely in their application. Structures may be appropriate or inappropriate depending on what the designer wants to do. Structure strongly influences game flavor, and appreciation of game flavor is extremely subjective.

More later!

-clash