Combat System Design

Posted by Thorin Tabor on April 14, 2016, 2:45 p.m.

I’ve been thinking quite a bit recently about RPG combat system design. After all, combat systems are a major emphasis in many (if not most ) RPGs.

Combat system design is a fun/time optimization problem.

These days I think about combat system design as a fun/time optimization problem. That is, ideally you want to maximize the amount of fun you get out of the combat system per unit of time spent. Obviously, how much fun you get out of something is quite subjective, and how much time you want the combat system to take up is going to vary with the design goals of the game, but I still think this is a useful optimization metric to keep in mind when considering potential rules for a combat system. Here are a few ways this can be applied:

• If a rule in combat takes time to resolve, but doesn’t add to the system’s fun in some way, it’s probably a bad rule. Example: If scoring a critical hit means rolling on a critical hit table, but most of the results are some variation of “add a few bonus points to damage,” it might be better skip the table entirely and go right to adding a few points to damage. Alternatively, the table might be made interesting enough to justify the time it adds to combat.
• If combat isn’t an emphasis in your game, it’s okay if the combat system isn’t all that exciting, so long as it’s super-quick to resolve. Example: If I’m running a game based after telenovelas, it’s okay not to have an in-depth system for combat maneuvers, ambushes, suppression fire, etc. So if two rival suitors pull guns on each other after a shocking realization, it’s fine if the combat system is just “make an opposed guns roll.” The combat itself doesn’t have to be all that interesting - just quick - so that the game moves on to the interesting parts.
• Even if combat is a major part of the game, it’s good to have a way for uninteresting combats to resolve quickly. Example: If a two-bit thug points a gun at Batman, this isn’t an interesting fight, even if combat is a major focus in supers games. The GM shouldn’t have to break out minis, initiative rules, counting hexes/squares, etc. Batman should just knock the gun away and take the thug out! A good GM will recognize this and run the situation accordingly, but it’s amazing the number of games that recognize this situation in their rules as written.

Another important realization about combat systems is to recognize that they are basically a just mechanism to resolve a particular type of scene in the game - specifically, combat scenes. Ideally, every action made in combat should contribute to progressing the resolution of the scene, or to making the resolution interesting in some way.

A Combat system is a mechanism to resolve combat scenes. Every action should move the scene towards resolution.

This is an important realization because in many traditional combat systems, a large number of actions don’t significantly contribute to the scene’s resolution. The quintessential example of this is attacking and missing in combat. When this happens no real progress has been made by either side to resolve the situation, the stakes have not been raised and usually the outcome of that attack isn’t particularly interesting.

In our Saga Machine games, this is the primary reason that, defensive reactions aside, the math is heavily stacked in favor of attacks hitting. Attacks that connect progress the game state by reducing the defender’s health, and bring the scene closer to resolving. Furthermore, most of the time that attacks miss, it’s because the defender took a defensive reaction. Since those always have a cost in AP/prana, the game state is progressed in a different way, with the defender having fewer AP/prana resources.

A combat system is a cycle, within which are smaller cycles. Each cycle has its own resources and its own pacing.

That leads me to the final, insight that I want to bring up in this post: The vast majority of combat systems consist of some sort of cycle within cycles. These are repeated over and over again until the scene resolves. In fact, roleplaying game sessions themselves are a sort of cycle within which the the smaller combat system cycles are placed.

The most obvious example of this is the traditional combat round: everyone gets a turn, takes action(s) and then that process repeats. Each round is one cycle. Within that, each turn is its own mini-cycle. In Against the Dark Yogi, for example, that would be: take an action, resolve it, repeat until out of prana or until an action requiring a flip is played.

Each kind of cycle has its own pacing and its own resources. For example, in many combat systems, an important resource for combat overall is HP. As the combat progresses, HP is lost, moving the game state forward towards the resolution of the scene. Within a combat round, an important resource is actions. Each character gets some number of actions and then uses those to affect the state of the game.

Ideally, every cycle should offer the opportunity to do something fun that progresses the game state. For example, on her turn, a player wants to be able to do something interesting that helps out her side in the combat. One reason why stun/shaken mechanics are disliked in some parts of the RPG community is because they frequently are implemented in a way that denies players the ability to do this. Similarly, healing mechanics can be controversial because they can be seen as reversing the progress of the game state, giving the sense that state is just “treading water” rather than bringing about a resolution one way or the other.

To sum up my post: Visualize combat systems as this interlocking set of cycles. Each cycle you want to squeeze out as much fun as you can in a timely manner. And every time you do this, you should be moving the game forward, towards the resolution of the combat scene.

---

Share Post

---