Jumping into the new:
Action points, Version 1
In the last episode, I detailed some of my early endeavors at gaming more varied action times. Enough of that. Here’s another general method: action points.
I can’t point to any single system as an example; I’ve seen many variations in home-brew games or as options for existing systems. One reader (see comments in first article) points to an AD&D version from an old Dragon magazine.
The idea is simple: give each character some number of “action points” (APs) based on whatever measure(s) of speediness the game employs. Every action costs some number of APs. The character with the highest AP total goes first, reducing his APs by the cost of the chosen action. Then the character with the next highest AP total takes an action, and so on, until all characters have spent their APs. That’s the end of the round; everyone’s APs refresh at the start of the next round.
The method will let a fighter with unusually high APs fit in one or several actions at the start of the round, before his APsdrop to the range of other fighters’ APs; after that, all fighters will interleave actions one-for-one (or as appropriate for the cost of their chosen actions) until the end of the round.
Or you could work this slight variation: Fighters start at a count of 0, and add their chosen actions’ AP costs, building up to each fighter’s maximum APs. That variation will have fighters interleaving actions from the start of the round, with the unusually fast fighter tacking on one or several extra actions at the end of the round.
Either way, there’s (at least) one minor downside to the system: There’s no easy way to map APs to real time. If two fighters each have 10 APs in a one-second round, it’s easy to declare an action point as representing 1/10 of a second; a 5-AP action takes half a second. Makes sense, right? But toss in a fighter with 20 APs, and what happens? The first fighters’ 5-AP actions now take only a quarter second? Who knows.
Action points, Version 2
A bigger variation is this: Fighters all have the same number of APs, but the AP cost for an action varies by some factor(s), such as each fighter’s speediness. That’s essentially the HERO method. Its vocabulary and description differ, but you could say that each HERO fighter has 12 APs per round, and spends (12/Speed) APs for each action (i.e., each turn, as I believe the HERO terminology puts it). A fighter with Speed 2 effectively spends 6 APs per action (completing two actions during the round); a fighter with Speed 6 effectively spends 2 APs per action (completing six actions per round).
Under this version of action points, tracking rounds is not necessary. A fighter’s turn takes as long as it takes; when he’s done, he starts another turn. A game may track rounds for other bookkeeping or simulation purposes, as HERO does, but basic turn order would function fine even if HERO ignored the round barrier, and just continued to tick off phases past 12, on to phase 13 and onward.
Note that the HERO system is very limited in what it accomplishes. While it varies action times for character speediness, it doesn’t allow for other factors to vary the action time, such as a heavy sword blow taking a little (or a lot) longer than a quick knife thrust. Even HERO‘s unique timing system is fairly static in what it allows.
Action points, other versions
You could create an AP system that combined both of the above Versions: an AP total that varies by character, together with an AP cost per action that varies by character and/or by action. There’s no point, though; the doubled workload adds nothing, and still leaves you with AP totals that don’t map to real time.
In the other direction, you could create an AP system that gives each character an equal number of APs, and an unvarying AP cost per action. In fact, typical games already work that way. You could see GURPS, for example, as awarding each combatant one AP per turn, with one second of action costing one AP, for any and all combatants. Or, as almost any rules-hacking GURPS GM has no doubt noted, you could say that each GURPS turn awards two APs per second, with an attack costing one AP, and the normal complement of defenses costing one AP. An AOA is the result of spending both APs on attack; an AOD is spending both APs on defense.
There’s a quirk to that GURPS two-AP model: a character spends both APs at once, as in a double-attack AOA, before the next character spends his two. The exception: waiting-type actions do take place later, after foes announce actions. That’s not only for the official Wait action; if you think about it, the everyday GURPS Active Defense is really a type of Wait action. With many such waits jumbling the occurrence of actions, some interesting interleaving takes place in GURPS combat.
But that’s all heading off on a tangent of GURPS rumination. They key issue here is this: An AP system with fixed AP per character and a fixed AP cost per action isn’t much of an AP system at all (and so it’s no surprise that games like GURPS don’t describe themselves using AP mechanics). And such a system still doesn’t make any detailed allowance for variance in time required for an action, which kicks us right outside the purpose of this article: to ask how a game could implement such variety. So let’s drop the tangent and head back inside.
Building on the above
So, can you build realistic timing on action points? Here again is the “real life” model:
1) There are no turns or rounds.
2) Attacks may vary in how long they take to “set up”.
3) Attacks may vary in how long they take to deliver.
4) There’s nothing to prevent two fighters from launching truly simultaneous attacks.
Looking at those in reverse order: Any AP model makes some provision for item 4, if desired: all that’s required is that when APs dictate simultaneous actions, you let them occur simultaneously rather than using some method to “break the tie”. Whether the rules allow for that depends on whether the author writes it in. Simple enough, so let’s move on.
Item 3 is the meat of the issue. The Version 2 AP system up above works well here (everyone has the same number of APs; the AP cost of an action varies by character and/or by the action). The Version 1 AP system (the AP cost of an action is the same for everyone, but characters vary in how many APs they have), meanwhile, isn’t a good choice, as it blurs any consideration of how long an action takes.
Item 2 in the real-life model is easy enough for any system to handle, where “long actions” such as loading a bow are concerned. But as a component of a “normal” melee attack, “setup” goes hand in hand with Item 3; its implementation is just a question of whether the system wants to consider attack setup and delivery separately, or combine them into one simpler action. Either way can work fine. There’s not much more to say here.
That leaves item 1, dropping the use of turns or rounds. The Version 1 AP system is no good for that; it explicitly requires the round/turn “barrier” as the point at which everyone’s APs refresh. Version 2 is a better starting point: it doesn’t require rounds (though doesn’t forbid them as a bookkeeping measure), and explicitly connects APs to actual time.
So, the conclusion: If you want to build a realistic system on APs, hew to Version 2. A rough outline: Set an AP cost for each action, varying with individual characters’ speediness and with the action itself, as appropriate. Each AP spent maps somehow to real time (whether a second, or tenth of a second, etc.). Play order should be obvious. An example: Starting at the same time, Fighter A makes an AP 3 action, while B makes an AP 5 action. Fighter A hits (or otherwise completes his action) “on 3”, then begins another action – say, a slower AP 7 action. Then B hits “on 5”, and begins another action – say, another AP 5. This time, they’ll both hit “on 10”; either use some method to resolve the tie, or allow simultaneous action if you prefer. And on it goes.
If you like, mark off a “round” every 10 APs or 20 APs (whatever you choose to use). That still leaves the combat action itself essentially round-less; the rounds are only there for purposes of bookkeeping (such as tracking fatigue and wound effects), and, of course, for mapping combat action to real time.
There, a simple skeleton. But it still needs to be completed, and tested for playworthiness.
My latest conceit
So here’s what I’ve been working on. It’s a model for the “Project T” rules project I’ve said little about – and sorry, it’s yet too early to spill many beans.
The combat timing portion is under construction and not yet properly tested. I’m pretty much following the AP system outlined immediately above, though dropping actual mention of “action points”. Time itself is all that’s counted: Fighter A’s action requires such-and-such length of time, while B’s requires its own length, and time flows naturally from there. If elapsed time has two actions happen simultaneously, then they happen simultaneously. Instead of rounds, turns, action points, and so on, action timing and pacing would work in a way that can best be described with “it happens when it happens; it takes as long as it takes”. No rounds, no turns, no phases, and no “favored” time scales: while human-centered combat will occur at a certain expected pace, super-slow beings or Matrix-style speedsters are equally covered, with no change in the system.
That should all raise big “unplayable” warnings in your mind: Simultaneously tracking, say, Fighter A’s 0.8-second action with B’s 1.25-second action and C’s 4.5-second action? “Okay, B, you go… let’s see, 1.25 minus 0.8… uh, 0.45 seconds after A…then you both still have 3.25 seconds before C completes his action…” That sounds mad. And it would be mad, if not for a simple trick up the sleeve that should address the problem.
But it’s all a bunch of woulds and shoulds at this point. I haven’t finished the basics and put them to the test. And when I do, it may all work niftily, or may be unplayably ugly. I’m going to cut off the discussion here, and report again later on actual field tests.
Why the interest in action time in the first place? Because it’s fairly untouched territory in game design. Published and home-brewed games have probed magic systems, skill models, wounding simulations, firearm workings, and a hundred other topics in every way imaginable. But action timing and pacing, the most dynamic aspects of combat, invariably fall under a handful of variants, all of them pretty static and limited in the variation they allow.
From that initial post I wrote years ago:
The ideal system would interest itself in relative differences, equally allowing for battles between psi warriors (typical attack times: 1/10 second, 1/15 for the fast ones) or between the living mountains of Ryol III (typical attack times: 3 Earth years for a “punch”, 2 for a “jab”, 1.5 for a “fast” mountain’s jab, etc.).
Add to that the normal, slight – but decisively vital – differences among “human-speed” attacks, and it’d be fascinating to see a system that flexibly handles variations in time, both large and small. My musing and experiments are game-system R&D for its own sake, and there’s no telling where that’ll lead. The most likely destination, I think, will be the realization that game systems stick with their static models for a good reason: the alternatives are unplayable. But I’d rather test that assumption and possibly fail, than take it as a given.
(And as should be obvious, my development work is taking place at a very slow pace of action. I’ll be happy to push ahead and report back here – as soon as I can find the time.)
The following are two tangents from the topic at hand, but related to combat timing. Both are GURPS rules items I haven’t cared for; I’d like to handle them differently in my home-brew efforts.
Tangent 1: Lulls
Breaks, pauses, and circling in combat. I have only questions here, not answers.
The current Martial Arts for 3e has a rule (p. 62) for injecting random lulls into combat to reflect the pauses and breaks that take place, with two effects: a) simulating fighters’ sparring, catching their breath, preparing to engage, etc.; and b) slowing down the default non-stop game combat pace to something more realistic.
That’s fine; there’s really nothing wrong with the idea. My only (minor) complaint is the artificial feel. It’s an action tossed in by the GM with no real game effect on combatants, and it’s arbitrarily used in some fights but not others. Injecting lulls into all combats would remove that arbitrariness, but that’s not satisfying; some fights should not have lulls. A fighter hacking through foes to reach the damsel about to fall off the ledge, or the student sparring with a wooden dummy, or the hungry zombie closing in, won’t stop to dance about and think. Automatic lulls would be wrong there.
Real fighters choose when and if to break apart, circle each other, and so on. The question that’s unanswered is why game characters would ever choose to do so. Default attacks come with no game cost, and there’s almost never a reason for a player to give one up. (GURPS 4e‘s new Evaluate maneuver does nicely provide a reason, though only for a few seconds’ pause at most.)
I don’t think there’s any complexity in the real-life reasons. Fighters break off for any number of mental reasons including planning/preparation, watching the other guy, or working up nerve. Purely mental factors like that are hard to game, though, without potentially complex rules and a reduction in player control over the PC’s mind.
Another very real factor is taking rests to cut fatigue, which will build up quickly after even a few seconds of all-out activity. That factor can be modeled realistically, but only through nasty per-turn bookkeeping.
In the end I have no complaint, whether the lull rules are used or not. I’m only wondering whether readers have insights into what goes in in real-life lulls, breaks, and “circling”, which – and this is the biggie – could actually be translated well into game rules.
Tangent 2: Chambara
The old “chambara” rules in GURPS Martial Arts awarded free extra attacks for high level with certain skills. That’s perfect if it’s the effect you want. I myself like to marvel at swordmasters’ lightning-fast multiple blows as much as the next geek, but I’ve always disliked the chambara mechanism.
As touched upon earlier, if an attack has no cost, there’s no incentive not to use it; there was no incentive for a swordsman with three attacks to make one well-placed blow instead of three flashy ones. That’s not a problem for everyone, but I prefer the trade-off model, and long argued that extra blows should come with a TH or other penalty.
Some pro-chambara players argued strongly that Skill 18 should automatically represent far greater speed than Skill 12. My take was this: Skill 18 should represent a TH roll of 18 at the default attack pace. A faster pace should be possible, but at a TH penalty; the fast-slashing Skill 18 fighter working at the limit of his speed should be as (in)accurate as the slower Skill 12 fighter also (presumably) working at the limit of his speed. By awarding Skill 18 both a high TH and no-cost multiple attacks, the game was “double counting” the benefits of skill and DX (when DX was arguably too powerful to begin with).
So I’m glad to see 4e follow the model I prefer through the Rapid Strikes mechanism (and a similar mechanism for multiple Parries), even under 4e‘s (thankfully) higher cost of DX. On top of a TH penalty for Rapid Strikes, I think a damage penalty makes sense as well, but I’m fine with the Rapid Strikes rule as is.
No complaints or real insights here. But if you’re an armchair designer pondering rapid attack rules for a home-brew game, I hope the above rambling is of small interest.