Saturday, July 25, 2009

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.



  1. I think you are right in some ways about frontloading and backloading, I just don't like your armor example.

    For decades, I've run systems where wearign armor makes you easier to hit, just harder to damage.

    So I feel like in your terminology and example, I thought that either was a simplification. Both covered a more realistic situation without getting to out of the playability range.


  2. Hi LV!

    I agree. This was addressed in my first paragraph. Compared to the initial abstraction of making something real into a game, the differences in amount of abstraction are infinitesimal. Nevertheless, people readily perceive tiny differences in this narrow band.


  3. There are additional degrees of backloading in the example you cite. Hit location is one of them. If there is no armour on the location being struck then there is no chance of damage being prevented, however less armour almost always means greater mobility which might mean that the defender might have a better chance of evading the attack in the first place.

    I think the validity of the choice depends on how many interactions the designer wants the players to have control over. If the game is about Film Noir gumshoes throwing punches, shooting revolvers and romancing dames then portraying detailed rules differentiating metal armour from leather isn't something that is needed, therefore abstracting that interaction is more valid than where the PC's are constantly hunting for an additional edge over some very competitive rivals in a game of courtly intrigue.

    Very good post though. I'm not familiar with your work, do you design both game systems and settings? Or do you lean to one over another?

  4. The example of armour is a very valid one.
    Armour and its effect on the gaming system is a long running example of the methold the game uses.
    In a realistic system armour should reduce the extend of the damage taken but in a simplistic system its easiest use is to reduce the chances of being hit (this can be seen as better armour stops more attacks then weaker ones).
    So the effect of armour is in part more to do with the system being used to either model its real life effect or to assist the games running speed, its one of those choices that has been around since day one and will still be around as long as games are made.
    For example d6 StarWars doesnt need a detailed system but say Twilight 2000 does, its the theme and feeling of the game that decides on the methold used.

  5. Hi Helmsman! Welcome to the blog!

    I agree with your observations about hit location (another frontload-backload choice, which maybe I'll cover later) and mobility. I deliberately simplified the example to highlight the basic differences in how it was handled.

    IMO, degree of player control is the biggest gain for backloading, and it should have been mentioned. I think I got all wrapped up in the degree of abstraction question and neglected to show how this was a gain for players.

    As for my work, my game company is Flying Mice Games - - and I design both settings and systems. I've been publishing since 2001, and gaming since 1978.


  6. Hi Roger!

    Exactly. It's a choice that makes a big difference in feel, and the designer should make that choice based on what he is trying to achieve.


  7. Clash,

    Who ever said this game designing was easy ;)

    A lot of the choices that turn into gaming rules are made at the very start of the design planning stages, this is the same for setting based or open gaming systems.
    In the end if the system makes the game works and plays well then thats a result for the designer(s).


  8. It may not be easy, but it can be a lot of fun! ;D

    However the game works, so long as it does work, it's all cool. I just like to lay these things out.


  9. Have to disagree with the specific example, Clash.

    Average isn't all. Variance is also very important. All else being equal, the difference between a D&D-style AC system and an armor-absorbs system is substantial, even if both produce the same mean damage over any given time interval.

    The general principle applies, though, and I think you're basically referring to design for cause vs. design for effect, as they say in wargame circles.

  10. Yeah, who ever said this was easy?

    I tend to do both in most situations, I am realizing. I tend to frontload in that there are stats for a great many situations, but the 'resolutions' still require a die roll.
    Armor protection, for example, is a range. And to tie Elliot in, all of the probablity curves of weapon damage vs armor protection took months to work out.

    But there are gamers who don't have the patience, as you said. I'm lucky to have all the players I do.

  11. Interesting thoughts. I have always preferred the "armour stops damage" approach though that led to some frustration in play. "I hit!" "Nothing happens."

    This is making me rethink GAMERS, and not a moment too soon as I've started a campaign :D

  12. Hi guys! Welcome to my blog!


    Yes, the interaction of things - the valence - is very different, and the more specific, the larger the potential difference. My point was not that they are the same, but they are both valid. There are reasons one would choose one over another, and depending on those reasons frontload or backlosd - designing for cause and designing for effect, as you said.


    Most designers frontload some things and backload others. This is a tool designers can use to excellent effect to change the feel of the games they write, and by using it in specific areas, tailor the game to the specific feel they want.


    Either way you go, there will be abstraction. The question is "where do you put that abstraction?" Each method can work well in different situations. Yes, damage reduction can result in a hit with no damage, but it can also work as a fiddly bit players can tweak.

    I'm really enjoying this blog thing so far! :D


  13. First, welcome to the narcissistic world of blogging! :)

    Second, a really, nice post. If I can devolve into biography, I think a lot fo us who lived through the realism-obsessed 80's have come around to seeing the value of what you are calling front-loading. What struck me was when I realzied that a lot of indie game design about "conflict resolution" rather than "task resolution" was all there in utero in D&D combat.

  14. Hi Matthew!

    Thanks for the welcome. :D

    To paraphrase The Bard, there is little new under the sun. As Bill Corrie points out on Hinterblog, refinement is more necessary to progress than innovation. Innovation without refinement dies on the vine.


  15. It's true that whatever you do there'll be abstraction, but it's also true that some abstractions lead to others.

    For example, if you say that armour reduces the chance to do an effective hit, it generally stops there. But if you say that armour reduces damage, then people start saying, "well what if you hit an unarmoured bit?" and then we get hit locations, and then we get a random hit location table with a malus to hit, and so on.

    So that while all are abstract, some abstractions lead to more because they're abstractions pretending to be reality.

  16. Hi Kiashu!

    While I agree that some abstractions imply more, they only lead to more if you as designer choose to go that way. You have the choice of whether to put a further alaboration into the rules, put it in as an option, or not put it in at all. If the group using your game want to go further, they can use your optional method or make/kitbash their own.

    Once that game leaves our hands, what is done with it is up tho the groups. We designers need to allow for that - plan for it really. Just let it go, and let the group take it from there if they want.

    Anyway, you've inspired me for todays little post!


  17. "Armor protection, for example, is a range. And to tie Elliot in, all of the probablity curves of weapon damage vs armor protection took months to work out."

    Sounds cool. I really appreciate systems which do more with less--in this case, it sounds like you may have used the dice distributions to simulate what in other games is often done with charts (e.g. Rolemaster, Harnmaster), special rules (GURPS pointed/edged/blunt differentiation), or hit locations.

  18. Nice summary of frontloading and backloading. But, yeah, I think your example side-trekked into other areas.

    Besides the variance issue, I think a more significant issue with armor is that most games separate “hitting” and “damage”.

    I’ve been much happier with the results of the few systems I’ve played in which the two were unified. The damage taken was directly related to how hard it was to score a hit. Then the issue of whether armor affects the “hitting” or the “damage” becomes moot since they are the same thing.

    Unfortunately, unifying the two can actually make play more complex rather than simpler. Especially for people like me who are slow doing mental arithmetic.

  19. Some of my task resolution sub-systems use unified chance and quality mechanics. Two of the three TR sub-systems I included in Commonwealth Space are unified - StarPool and Star20. StarPerc has separate chance and quality rolls. There are things I like about this concept, obviously. :D