Game design musing: It’s about time (Part II)

More on the subject of attack time and pacing in RPG combat systems, focusing on a couple of old home-brew efforts.

Continued from Part I:

On to another round of writing. I planned to wrap this up, but it looks like there’s going to be a Part III as well. (One note: With occasional digression, I’m discussing melee, not ranged, combat.)

Recap

Looking at how a few game systems (including some I haven’t mentioned) handle action time and pacing in their combat systems, the below seem par for the course:

  • Combat actions take place in turns, with a default of one attack per turn.
  • Under turns, there’s typically no mechanism for two fighters to attack each other at exactly the same time; the attack will go to whichever character is “on his turn” or otherwise “has initiative”.
  • “Long actions” are easily handled as actions that require multiple turns.
  • Despite the above, “long action” attacks are rare or nonexistent; games typically don’t require attacks, even those from big “slow” weapons, to span multiple turns. (Readying actions may be required, such as nocking an arrow or readying a heavy weapon in GURPS, but the subsequent attack itself is no slower than usual.)
  • Systems may distinguish between small, fast weapons and big, slow ones in initiative rules. But they typically don’t distinguish between length of attack time itself for the two: a knife and a two-handed sword have the same default once-per-turn attack speed.
  • Systems typically do allow for more than one attack per turn – “multiple attacks” – whether from system-specific factors (such as attacks per character level) or mundane factors (such as use of two hands).
  • While attacks at default pace (or, where available in a system, slower-than-default pace) interleave as turns pass, multiple attacks happen “all at once”: a character takes all his multiple attacks before the next character takes all her multiple attacks. Games don’t want to break down turns into interleaving sub-turns, so they abstract faster-than-default paces of attack.
  • Under multiple attacks per turn, games still make no distinction among length of attack times; barring any readying requirements, a two-handed sword typically has the same ability to make multiple attacks per turn as does a knife.

As mentioned before, the HERO system is a little harder to place. It does vary turn length and thus attack time, though it does so by character (not by attack or weapon); it interleaves those variable-time turns in a rigid but sensible way. With that difference in mind, all of the above still hold true for HERO.

“And… your point would be?”

None of the above is good or bad. Most players have no argument with favorite games’ handling of time, and for good reason: they work and they’re fun. My goal is nothing more than dry observations on how things work, from the dilettante designer perspective.

What’s the point of that? Satisfying my (and your?) curiosity over whether a system could handle things differently – yes, more “realistically” – while remaining playable.

What would be the design specs for such a system? Consider “real” combat timing:

1) There are no turns or rounds.
2) Attacks may vary in how long they take to “set up”. (Come on, lift that polearm!)
3) Attacks may vary in how long they take to deliver.
4) There’s nothing to prevent two fighters from launching truly simultaneous attacks.

Hmm, that sounds downright real! Can it be made playable? Maybe not. Let’s see.

One old effort: attack time dice

Long ago, I devised a variable action time system which I played several times with a group. It was either for one of my original efforts, or was tacked on to our AD&D campaign (sorry, my wetware drive seems to have been rubbed with a big wetware magnet). Each attack had an “attack time” in dice, such as 2d4 or 2d6, just like a damage score, and it all worked something like this: Take the inherent attack speed for the weapon (possibly taken straight from AD&D‘s Speed Factor) and add that to Dexterity. (ST may have factored in as well; it certainly should have.) Checking the total against a table, you get the attack time dice.

That’s a one-time calculation for a given attack, and is inherently not worse than calculating and jotting down the damage for the attack. So far no problem. And in play, the results were kind of nifty: You rolled the attack time dice when launching the attack, and that’s how many seconds the attack took to complete. Different characters’ attacks were able to overlap and interweave in any crazy way. And via that simple method, the system hit all four of the design specs above in one swoop. (More or less, that is; spec 2 was subsumed into 3, with no distinction between melee readying time and attack time itself.)

The obvious downside, besides the extra rolls for attack time, was tracking passage of time. It wasn’t enough to track the passing of turns or rounds; we had to keep a timeline with seconds on the X axis, characters on the Y, marking each character’s next upcoming attack time as it was rolled. You can easily picture it: “Okay, on second 20, Fred’s attack comes up… <roll dice, resolve attack>… Okay, Fred, you want to swing the axe again? Roll your attack time. <Fred rolls 8 on 2d6>… Okay, you’ll attack next on second 28, but before that, the dragon counterattacks on second 24, and Hank fires his arrow on second 25… “

(Tangent: Yes, game masters say “okay” more than any other word.)

That may or may not sound bad to you. But it’s still too pretty a picture. A round-less system like that raises lots of new issues, which I don’t recall we worked out to satisfaction. For example, if your next attack is going to take place 5 seconds later, can I just use my intervening action to hightail it far away from you? It makes sense, but details have to be worked out so faster attackers can’t strike at slower attackers with impunity, sprinting to the other side of the room before the poor schlep can bring down the halberd. My apologies again for the memory loss, but not only do I recall little detail about the system, I don’t clearly recall its fate. I think it succumbed to a natural end-of-campaign death before further fleshing-out. The games and gamers changed after that, and it was dropped.

Hypothetical random attack times for GURPS

Here’s a really quick, untested thought on reconstructing such a system for GURPS. Attack times of 2d4 or so seconds were fine for my old game – and that was a downright frenetic pace of action in the days when AD&D had fighters attacking once per minute. But one attack per second is the norm for GURPS, and no one would want to see that suddenly slowed to once every 5 or so seconds. If we were to introduce randomly-rolled attack times into GURPS, it would have to be some minor variance around a sprightly speed of 1 or 2 seconds per attack.

Perhaps something like this: Each attack has some Speed Factor computed from ST and the weapon’s Min ST, as well as length and unbalance in some fashion. For a typical user, final Speed Factor would be around 0 for reasonably light weapons. It would be positive for fists and smallswords, and negative for heavy, long, and/or unbalanced weapons.

Add Speed Factor to weapon skill (so skill becomes a factor as well). This total determines attack time: say, 12 or more would be a 1-second attack speed; 8 to 11, a speed of 1-2 seconds; 4 to 7, a speed of 1-3 seconds; and so on, making up numbers out of thin air. Jot this attack time down for future use, like any other weapon stat.

Or for greater fineness: At the start of each fighter’s attack, roll vs his weapon skill + Speed Factor. For every X points (say, 4 points) of failure, the attack will require an extra turn to complete; imagine a sloowww attack. Otherwise, the attack takes place at default speed – but for every full X points of success, the attacker is eligible to make one additional attack using regular Rapid Strike rules, if he wishes to do so.

The result: A knife wielder would likely attack once per turn, and would often have the option of making Rapid Strikes as well. A longsword user would also likely attack once per turn, but would have fewer opportunities to use Rapid Strikes. Meanwhile, a two-handed sword wielder might find herself dealing either one-turn attacks or two-turn attacks, depending on how the attack time dice fall – and even on the good rolls, likely wouldn’t gain the option of Rapid Strikes.

A nice feature of this hypothetical system is allowance for fine adjustments to Speed Factor, such as a small +1 for a well-maintained gun’s firing smoothness, or a modest -2 for a sword swing vs a thrust. That’s great for detailing differences that are meaningful, yet not so huge as to automatically knock attack speed back another second. Another nice feature is skill playing a factor in attack pace, which in turn could generate realistic rates of fire for guns. By treating RoF with automatic pistols in the same manner as Rapid Strike eligibility above, only skillful users will squeeze off the full 3 shots per turn.

It’s all very interesting, but I’m not rushing to try it. As with my old game, it requires an extra roll preceding every attack, as well as extra bookkeeping for all attacks that come at a two-turn or slower pace. Those are sure to go over poorly with harried GMs. In addition, it’d take plenty of additional work to shoehorn the system into GURPS. How exactly do you set Speed Factor? Should the rolled attack speed for a polearm subsume its Ready requirement, or should that remain a separate factor? Should a two-turn or slower attack be easier to Dodge? What happens to a fighter who defends in the middle of his two-turn or slower attack? How does speed and pace of parries fit into it all? Those and many more hard questions await.

A more abstract effort: GLAIVE

GLAIVE is my system for building weapons from scratch in GURPS.

Hidden inside of its weapon design rules is a new (and as far as I’ve seen so far, unique) system for shaking up weapons’ attack frequencies, injecting variety via an abstract mechanism. In a nutshell:

Each weapon designed has a Recovery stat, computed from weight, length, and balance. Divide Recovery by user ST; the rounded-down result, which is 0 or higher, is Ready Penalty.

If Ready Penalty is higher than 4, you need to perform a Ready action before use. Ready Penalty higher than 8 would mean two Ready actions. (Each Ready action reduces the current Ready Penalty by 4, so two Ready actions bring that 8 down to 0.)  

Nothing too special so far; the above just delivers GURPS‘ well-known Ready requirement for heavy weapons, in a formulaic way. What’s different is this: Fast weapons (or partially-readied slower weapons) with Ready Penalty between 1 and 4 also call for a Ready action before use. It’s not required for them, but they can be considered not fully ready, and thus any use takes a (non-cumulative) skill penalty equal to Ready Penalty.

Here’s an example: A heavy axe with Ready Penalty 4 cannot be used immediately; it must be readied. A Ready action brings that 4 down to 0; the axe can now be used without penalty. A light axe with Ready Penalty 2 can be used immediately, though at a -2 skill penalty. A proper Ready action in advance would remove the penalty. Finally, there’s a long, heavy axe with Ready Penalty 6. This clearly can’t be used immediately. A Ready action reduces the penalty, but only by 4, leaving Ready Penalty 2. The long, heavy axe is now as ready to use as is the light axe, halfway between unready and fully ready. The user will need to choose between taking combat action now at a -2 penalty, or taking another Ready action to fully remove the penalty.         

For weapons with Ready Penalty under 4, this scheme clearly doesn’t slow down attack frequency automatically. A longsword with Ready Penalty 3 can still attack and parry every turn, just like a fist with Ready Penalty 0. But the skill penalty abstractly suggests that the sword wielder is having a hard time “keeping up” with that pace. At times, when the opening presents itself or he needs every point of TH available for a difficult shot, the sword wielder will take a Ready action to eliminate his next action’s -3 skill penalty. And over the course of many turns, that may result in the sword displaying an attack frequency of, say, 4 attacks for the fist’s 5, or 8 for the fist’s 9, or any other interesting ratio.

Naturally, that’s not as realistic as setting the sword’s attack time itself to some automatic multiple n of the fist’s attack time. But that level of detail isn’t possible without jettisoning the GURPS turn structure entirely. As a method that shakes up attack frequencies over many turns, and with some degree of fineness to boot, all while respecting GURPS‘ rigid turn structure, I think GLAIVE’s Ready Penalty method is a good system. 

On the inevitable downside, the method does add a bookkeeping requirement (i.e., noting whether or not the wielder took a Ready as his last action) for most weapons, whereas GURPS currently requires that bookkeeping only for certain heavier weapons. It’s one of my creations I haven’t received much feedback on, even from folks who are otherwise fans of GLAIVE, so I don’t know whether it’s been well received by readers. (Which I should take to mean “no”. : )

On the positive side, the GLAIVE weapon rules, including the above attack speed rules, should be portable to many other systems. There’s a reader-contributed d20 version already; a HERO version would be equally feasible, I think.

Next up

Boy, speaking of sloowww action… I’ve got some really, really exciting (rolls eyes) text on “action point” systems lined up, but it still needs polish before I want to post it. I’ll post the above now before it gets even staler.

Until next time! I love to hear those comments and thoughts, especially on your own efforts in the field.

2 Comments

  • Polydamas

    Roundless combat does seem like one of those things which would work very nicely on a computer. It’s an interesting idea, and you have several intriguing suggestions here, but I’m not sure if anyone has invented rules to make tabletop combat playable with a quanta under 1s or so without adding significant complexity. There are issues with movement and reaction time, for example, which you don’t really have time to discuss here. (Even if we convert Move 5 yards/s to Move 1 yd/0.2 s, tracking acceleration becomes an issue). Still, there ought to be good alternatives to the traditional round, and you have laid out several possibilities.

    You might want to have a look at Kenzerco’s new Western gunfight rules, Aces and Eights. I’ve never used them, but apparently they use ’roundless’ combat with a quanta of 0.1 s or so. There are some other interesting novelties in how they handle combat, although I’d have to try it to be convinced it is all playable.

    • tbone

      Yep, a computer can handle fancy time measurements – or just about any number-crunchy system – just fine. Making a tabletop RPG version is the real challenge.

      “Quanta under 1s” – good wording, I’ll have to borrow that. As far as I know, no one has made a tabletop version that’s simple to play. As you point out, when you get to quanta that small, even reaction time itself becomes a big factor. (Which – if it were made playable – would be a big and interesting factor.)

      Re Aces and Eights: Interesting. From the little info online and a few play aid downloads, it looks like an AP system, with actions costing a set number of “counts” (=0.1 sec each, I gather). There’s also a Speed stat, though it’s not clear w/out the rulebook how that comes into play – namely, whether it somehow modifies the “count” cost for actions, or whether it doesn’t, and every gunfighter takes the same time to perform any given action.

      Either way, by measuring action times in these tiny “counts”, the game is able to differentiate between, to name one visible example, the time to acquire a target in a near arc, vs time to acquire one in a far arc. Could be interesting to play.

Leave a Reply to Polydamas Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.