System Design: Analyzing time cost of resolution mechanics

[PhoenixPhyre]

I've been thinking about how long the fundamental operations of any non-freeform RPG system take. Not in real time (because that varies wildly by table), but in terms of the elementary operations that make up all resolution mechanics. Dice rolls (or other randomizers), arithmetic, comparisons, branching, and table look-ups.

Here's what I've come up with in terms of the elementary operations. The numbers in parentheses are an estimate of the cost of that operation in arbitrary units.

• Roll N dice (1): Roll(N). Rolling N dice is no slower than rolling 1 die (for reasonable N). Rolls that can't be done at the same time must be counted separately.
• Adding/subtract two numbers (1): Add/Subtract. Adding N numbers takes N-1 additions.
• Divide two numbers (1 for halving, but higher as the denominator increases): Divide
• Multiply two numbers (1, 2 for higher multipliers under 10): Multiply
• Compare two numbers (1): Compare
• Non-numeric conditional branch (5?): IF
• Table lookup (10): Lookup

A 5e D&D attack roll, saving throw, or non-opposed ability check (without advantage or disadvantage) has the following cost:
Roll(1) + Add + Compare(to TN) = 3.

With advantage or disadvantage, the cost increases by an additional Compare step:
Roll(2) + Compare(take highest) + Add + Compare(to TN) = 4.

A standard damage roll (N is the number of damage dice): R(N)+ (N-1) x Add + (Add OR Subtract)(from HP) + Compare (damage to max health/0) = 2 + N

On the other hand, a wild magic surge has a huge cost, which grows if you roll the result that requires you to roll 2 more surges, ignoring that result:
* If the spell that triggers the surge doesn't deal damage, then the cost is: [Save] + Roll(1) + Compare + Roll(%) + Lookup = 19 total.
* If it deals damage, add 2 + N to that, for a new total of 21 + N.
* If you have to reroll, the total cost is [Wild Surge] + 2 x Roll(%) + 2 x Compare + 2 x IF(ignoring repeated rerolls) + 2 x Lookup = 53 + [2 + N]

At low/medium levels, a standard PC turn is usually something like 2 x [Attack/Save] + [Damage], for a total cost/turn of 9 + the number of damage dice rolled.

A 3d6-based system (replacing 1d20 with 3d6) would end up at 4 for a basic check: Roll(3) + 2 x Add + C.

Adding in degrees of success/failure increases the cost of a check by an extra comparison for each extra fixed degree of success or failure possible beyond success/failure (botch/succeed with consequences/succeed/great success) would add 2 comparisons.

My preference is for the time cost of a mechanic to scale inversely with the frequency of that mechanic. Things you do a lot should be very fast, things that you do infrequently can take longer.

Is this a sensible framework? Are there other fundamental operations? How do other systems stack up for their basic operations?

[NichG]

I think subtraction is generally slowly than addition (at about 2 to 1), and multiplication/division by almost any factor is also slower than addition (at about 3 to 1) and gets bad very fast for nontrivial factors.

Two other time costs I'd try to consider. When I was playing 7th Sea, one of the most time-consuming things about the rounds mechanic there was the amount of recording that had to be done to track things. The cycle of 'everyone roll initiative and give me your numbers' is a serial process that scales linearly with the number of players even in something like D&D, because it often has to pass through the bottleneck of a DM or record keeper. In 7th Sea, you almost had to do something like building a hash table dynamically to track initiative because different characters had multiple actions at different points during a round, so the start of round was often the slowest part. So something like table insert = 5 maybe?

Another source of time cost is if there's an embedded decision that requires one or more players to actually think. For example, in something like D&D where there are Immediate Actions, there's an extra time amount associated with giving people a chance to consider their options. In something like M:tG where counter sequences are a big part of the game, this would be a bigger time cost. Not sure how to count it though.

[PhoenixPhyre]

I think subtraction is generally slowly than addition (at about 2 to 1), and multiplication/division by almost any factor is also slower than addition (at about 3 to 1) and gets bad very fast for nontrivial factors.

Two other time costs I'd try to consider. When I was playing 7th Sea, one of the most time-consuming things about the rounds mechanic there was the amount of recording that had to be done to track things. The cycle of 'everyone roll initiative and give me your numbers' is a serial process that scales linearly with the number of players even in something like D&D, because it often has to pass through the bottleneck of a DM or record keeper. In 7th Sea, you almost had to do something like building a hash table dynamically to track initiative because different characters had multiple actions at different points during a round, so the start of round was often the slowest part. So something like table insert = 5 maybe?

Another source of time cost is if there's an embedded decision that requires one or more players to actually think. For example, in something like D&D where there are Immediate Actions, there's an extra time amount associated with giving people a chance to consider their options. In something like M:tG where counter sequences are a big part of the game, this would be a bigger time cost. Not sure how to count it though.

Agreed on all counts. The first issue (longer costs for the various arithmetic operations) was something I left out for simplicity, but it's a big factor. It's why I prefer to add damage (instead of subtracting from HP)--an addition and a comparison is faster than a subtraction. Multiplying by 2 or dividing by 2 is usually pretty fast, but anything else gets nasty (and has worst-case behavior for prime-ish numbers).

The time costs for recording and decision points are boiled into the non-numeric conditionals--it's where I was putting all the "this happens if X, but not if Y" that 3e D&D is so known for. The weight is strongly variable though. Anything that requires a separate logic chain, or worse a weighing of risks and benefits is worse than a table lookup most of the time. At least the table has fixed entries.

The more I look at this, the more I like 5e D&D's decision to do away with most situational/conditional bonuses/maluses except for additional dice. Adding additional dice basically costs nothing (one extra addition per die). Tracking situational modifiers is ugly from a time-cost perspective. Static modifiers that only change on level-up can be precomputed and cached, situational ones can't be.

[Vitruviansquid]

This framework seems very sensible to me.

Something I'd add is that adding a some factors for time cost into any resolution mechanic increases the time cost exponentially. Situational modifiers are really good at slowing the game down when you have more than a few of them in a roll.

[Quertus]

Almost everything I wanted to add was converted under decision points.

However, there is also issues of data tracking, data transmission, and hidden information. For example, it's faster for me to add 10d6 for a fireball than to say that I dealt 13 silver bludgeoning, plus 6 fire, plus 2 electric, plus 17 sneak attack.

[PhoenixPhyre]

This framework seems very sensible to me.

Something I'd add is that adding a some factors for time cost into any resolution mechanic increases the time cost exponentially. Situational modifiers are really good at slowing the game down when you have more than a few of them in a roll.

So moving those to being a multiplicative factor instead of an additive one? Possibly on some part of the expression:

Roll(N) + N x Add + IF x IF x ( M x Add + I x Subtract )

for something where you have a constant part (roll damage, add it up) but one part that depends (on say charging): If you charged and power attacked, add M numbers, but you have a penalty from some spell, so subtract I other numbers. Yeah, that sounds right, although it's probably be better to reduce the weight of the IF term. I'd ballpark it to a doubling--every independent situational term roughly doubles the time for that part of the mechanic.

Almost everything I wanted to add was converted under decision points.

However, there is also issues of data tracking, data transmission, and hidden information. For example, it's faster for me to add 10d6 for a fireball than to say that I dealt 13 silver bludgeoning, plus 6 fire, plus 2 electric, plus 17 sneak attack.

Especially when the target has resistance to one, vulnerability to another, and is immune to a third. I've seen that with a rogue I play with--

He has sneak attack, a sword that deals extra force damage, and he gets temporary hit points for the damage dealt by the weapon (not the sneak attack). This means he has to use different colored dice for each part of it. And once he stacked a 8d6 poison on top of that...now if it crits...

[Tanarii]

IMX rolling N dice often takes players longer than rolling 1 dice, or N-1 dice. Because they have to hunt through their huge pile of dice in front of them looking for N dice before they can roll them. Sometimes having to check sides to make sure it really is a d8 instead of a d10.

Also is does adding dice include the time it takes to read N die faces? Or does that count as rolling the dice time?

And what about marbled dice or other dice that make it hard to read the die result? Does that come under rolling dice, or manipulating the values?

[PhoenixPhyre]

IMX rolling N dice often takes players longer than rolling 1 dice, or N-1 dice. Because they have to hunt through their huge pile of dice in front of them looking for N dice before they can roll them. Sometimes having to check sides to make sure it really is a d8 instead of a d10.

I've seen that, especially with new players. It's certainly (IMX) less than linear scaling, maybe cost of 1 + log(N)? The dominating factor is if you have enough dice to roll the whole bit at once. Rolling 6d6 using a single d6 has a cost of 6, not 1 because it's a serial step, not a parallel step. I bet in a dice-pool game (Shadowrun stereotypically uses lots of dice, doesn't it?) the scaling would matter.

Basically, the parallelization of dice rolling makes it quicker than linear, assuming you have enough dice. Only having one of each kind sucks, especially for a rogue (or wizard, but rogues do SA more than wizards do fireball).

Also is does adding dice include the time it takes to read N die faces? Or does that count as rolling the dice time?

And what about marbled dice or other dice that make it hard to read the die result? Does that come under rolling dice, or manipulating the values?

That's a good question. I'd mentally lumped it in with the addition step (just like finding the cached number on a character sheet).

Those hard-to-read die are more a "please don't" time cost for me--I strongly discourage and dislike heavily patterned (or transparent) dice for that reason.

[Tanarii]

I've seen that, especially with new players. It's certainly (IMX) less than linear scaling, maybe cost of 1 + log(N)? The dominating factor is if you have enough dice to roll the whole bit at once. Rolling 6d6 using a single d6 has a cost of 6, not 1 because it's a serial step, not a parallel step. I bet in a dice-pool game (Shadowrun stereotypically uses lots of dice, doesn't it?) the scaling would matter.

Basically, the parallelization of dice rolling makes it quicker than linear, assuming you have enough dice. Only having one of each kind sucks, especially for a rogue (or wizard, but rogues do SA more than wizards do fireball).

Oh yeah, agree that finding 6d8 (if you have them) and rolling once is generally going to be faster than rolling d8 six times. Even for a player that struggles to tell their d8s apart from their d10s. (I have quite a few players with that problem, for some reason.)

That's a good question. I'd mentally lumped it in with the addition step (just like finding the cached number on a character sheet).

Those hard-to-read die are more a "please don't" time cost for me--I strongly discourage and dislike heavily patterned (or transparent) dice for that reason.

yeah, the real question is: is reading the die value part of rolling the dice, or doing things with the values? I'd knee jerk to include it as rolling the dice personally. But I agree it's often part of mentally manipulating the values (adding certainly) as you read them. But in the case of exploding dice (roll new die on max value) it'd probably be better counted as time spent rolling dice.

Which reminds me to add exploding dice to your list. Also, not sure if "compare" covers dice pools where you're going for N successes (often 4+ on d6), where N is the target Objective Difficulty (Obj).

[PhoenixPhyre]

yeah, the real question is: is reading the die value part of rolling the dice, or doing things with the values? I'd knee jerk to include it as rolling the dice personally. But I agree it's often part of mentally manipulating the values (adding certainly) as you read them. But in the case of exploding dice (roll new die on max value) it'd probably be better counted as time spent rolling dice.

Which reminds me to add exploding dice to your list. Also, not sure if "compare" covers dice pools where you're going for N successes (often 4+ on d6), where N is the target Objective Difficulty (Obj).

I could go with either. Probably better to lump it in with the roll, but ...

I thought about exploding dice--I'd probably model it as Roll(N) + N x Compare + IF x (Roll(M) + M x Compare + IF ...). That gets bad fast. You're looking at exponential scaling there if there's a decent chance of explosion. Shades of the d2 crusader...

Compares are all numerical comparisons (do something if result > target)--I find those much faster than more situational/fact-dependent conditional expressions.

Dice pools I'm not as familiar with, but is it like:
* Roll M dice
* FOR (d in dice):
** IF d.value > threshold THEN count += 1
* IF count >= TN THEN success ELSE failure

If so, that'd be Roll(M) + (M+1) x Compare + L x Add. The M+1 accounts for the comparison of the total to the TN. Certainly more costly than a D&D-style attack roll (without conditionals), but less than table-based look-ups.

I saw a proposal where for every hit you'd have multiple table look-ups and 3-4 saving throws. On top of 3e's standard situational modifiers...ouch.

[Telok]

Two distinctions that I would make under the comparisons are about simple/common tables versus rare/complex tables and comparisons that require information exchange.

A 6 to 10 entry single-result lookup table that uses the game's standard die roll and can easily be included in a character sheet is relatively fast. Hit locations often fall into this caregory, roll one die and scan a 8 line table. A 20+ entry table with multiple rolls, rerolls, or additional actions and look-ups, that is not often used and does not use the standard dice mechanic for the game will be much slower. The D&D wild surge table that uses d%, has rerolls, and may require looking up spells is this sort of table.

I often find information exchange about dice rolls to take much more time than the rolls themselves. Having to ask about different ACs, be reminded of or be granted additional modifiers during the rolling, having to ask about or specify assorted immunities or conditions, all take more time than even a slightly more complicated rolling system.

[Tanarii]

Dice pools I'm not as familiar with, but is it like:
* Roll M dice
* FOR (d in dice):
** IF d.value > threshold THEN count += 1
* IF count >= TN THEN success ELSE failure

If so, that'd be Roll(M) + (M+1) x Compare + L x Add. The M+1 accounts for the comparison of the total to the TN. Certainly more costly than a D&D-style attack roll (without conditionals), but less than table-based look-ups.

Im not following your math (because I'm lazy), but dice pools are often one of:
- Separate dice into success dice vs non-success dice (compares), then count success dice, then compare to success number, then determine margin of success or failure
- glance at dice and brain processes number of successes without needing to separate dice or actually count, then compare as above.

The first one would be the one I'd base the math formula on.

But the second is to illustrate how the brain can save time by batch processing. Batch processing can even save time just in the separating of dice in the first, the compares being quicker for 10d6 at once then separating into two groups (1-3; 4-6) vs the total compare time if you rolled 10 individual d6s then put it in the appropriate group as you rolled each one.

[PhoenixPhyre]

Two distinctions that I would make under the comparisons are about simple/common tables versus rare/complex tables and comparisons that require information exchange.

A 6 to 10 entry single-result lookup table that uses the game's standard die roll and can easily be included in a character sheet is relatively fast. Hit locations often fall into this caregory, roll one die and scan a 8 line table. A 20+ entry table with multiple rolls, rerolls, or additional actions and look-ups, that is not often used and does not use the standard dice mechanic for the game will be much slower. The D&D wild surge table that uses d%, has rerolls, and may require looking up spells is this sort of table.

I often find information exchange about dice rolls to take much more time than the rolls themselves. Having to ask about different ACs, be reminded of or be granted additional modifiers during the rolling, having to ask about or specify assorted immunities or conditions, all take more time than even a slightly more complicated rolling system.

But even then, you're doing a table lookup that takes orders of magnitude more time than a numeric comparison. Especially if you have one die to see if you hit, then another to decide where, and a third to decide if you penetrated armor, and...

And the second paragraph is exactly the conditional modifiers that bloat table time. When I'm rolling attack rolls in 5e, most of the time it's clear without adding the modifier whether it hits or misses. And even when I'm not sure, communicating it is simply "The goblin hits AC 12". If I had to remember that he is using Power Attack but has this feat and that circumstance, and the moon is in Libra, and...then it gets painful.

Im not following your math (because I'm lazy), but dice pools are often one of:
- Separate dice into success dice vs non-success dice (compares), then count success dice, then compare to success number, then determine margin of success or failure
- glance at dice and brain processes number of successes without needing to separate dice or actually count, then compare as above.

The first one would be the one I'd base the math formula on.

But the second is to illustrate how the brain can save time by batch processing. Batch processing can even save time just in the separating of dice in the first, the compares being quicker for 10d6 at once then separating into two groups (1-3; 4-6) vs the total compare time if you rolled 10 individual d6s then put it in the appropriate group as you rolled each one.

Whether you're batching or not, you're still examining each die to decide if it is a success or not. That's one Compare for each die. In computer terms, you're still iterating over the array of dice, so that's O(N) at best. I'd bet that in practice, an accomplished table can do dice pools very fast. But a similar table could do 1d20 + MOD even faster.

[Jormengand]

IMX rolling N dice often takes players longer than rolling 1 dice, or N-1 dice. Because they have to hunt through their huge pile of dice in front of them looking for N dice before they can roll them. Sometimes having to check sides to make sure it really is a d8 instead of a d10.

This stops being the case for any reasonable N in systems where all the dice are the same, though...

I don't think that any numerical assignment of how fast a resolution mechanic should be in theory is ever going to work, honestly. There are too many variables - even just in this example of "Rolling multiple dice" - for you to assign decent values to them all.

[PhoenixPhyre]

This stops being the case for any reasonable N in systems where all the dice are the same, though...

I don't think that any numerical assignment of how fast a resolution mechanic should be in theory is ever going to work, honestly. There are too many variables - even just in this example of "Rolling multiple dice" - for you to assign decent values to them all.

This is following in the footsteps of "Big O" analysis in computer science. That is, we're not really concerned with exact timings. Just in scaling and separating "slow" operations from "fast" operations.

Basically, there are the following types of operations:

Fast constant time operations: Rolling groups of similar dice, adding two small numbers (it doesn't matter what those numbers are as long as they're 2-digit or lower), numeric comparisons
Slow constant time operations: Simple (non-nested) tables, division of two small numbers
Linear-time operations: Adding N dice. Nested tables. Practical exploding dice, multiplying small numbers
Exponential-time operations: non-numeric conditionals, option trees. Wacky exploding dice.

The time for resolving the mechanic is dominated by the slowest term; for low numbers of dice, fast > linear ~ slow >> exponential.

As for "working", that depends. I think this is useful as a reminder for those deciding between different resolution mechanics--common mechanics should be fast. If your proposed mechanic has a high time cost, what benefit does it bring to compensate?

[Jormengand]

This is following in the footsteps of "Big O" analysis in computer science.

I get that and I know how Big O works. But I don't know that you can even emulate Big O notation in this way. XdY resolutions can vary in time required by orders of magnitude by altering things that aren't X or Y Rolling 5d6 can take ages if you're playing in a system where rolling fistfuls of dice is an uncommon enough occurrence that you have to take a while to search for five standard dice, and can be very fast if you're playing in, say, SIFRP where everything is an Xd6 roll. The difference in that one factor - which doesn't even have an obvious numerical value - will almost always change the time required far more than any reasonable change in X or Y.

Essentially, "Eyeball it" will always give a better answer than trying to work things out pseudo-mathematically.

As for "working", that depends. I think this is useful as a reminder for those deciding between different resolution mechanics--common mechanics should be fast. If your proposed mechanic has a high time cost, what benefit does it bring to compensate?

But... we should be able to do that without having this pointless and, honestly, near-pseudoscientific metric that emulates Big O notation without really having much to do with it - Big O is a metric for how much the time taken increases with the number of things you're trying to process ("O²" meaning "As the number of things in the list is multiplied by X, the time it takes to process the list is multiplied by X²"), so if this were really to do with Big O, it would measure how the time taken changes compared to the number of actions you're trying to resolve. Not only does this not have anything to do with Big O Notation, it's also so wildly inaccurate and requires way too many variables to function sensibly. Really, rather than all this fake maths, you could just say "Playtest anything that intuitively seems like it might take a while" and get a better result.

[NichG]

Well, even if the numbers are wrong, having a particular structure in mind for breaking down the timing of different resolution systems could make playtesting more sample efficient. That is to say, rather than having to independently playtest each system from scratch, you could do one experiment to establish e.g. 'how long does subtraction actually take?' with all of the contextual factors being incorporated into the variance of that measurement. That could help iterate faster when designing things.

This is probably not something that an individual GM would have the resources to make much use of, but it might be interesting to e.g. aggregate data from GitP groups playing different systems and then establish roughly what the time factors are for addition, subtraction, etc.

Anyhow, this kind of quantification feels like it's for fine-tuning rather than justifying one system against a wildly different other system, or doing very coarse ballpark stuff where intuition would be enough to basically figure which will be slower. This is more like, if you were designing something like 2ed vs 3ed and you had to figure out if e.g. 'roll plus negative modifiers below your stat' or 'roll against a flat DC from a table plus positive modifiers' is faster. So like 10-20% improvement level of optimizations.

[PhoenixPhyre]

Well, even if the numbers are wrong, having a particular structure in mind for breaking down the timing of different resolution systems could make playtesting more sample efficient. That is to say, rather than having to independently playtest each system from scratch, you could do one experiment to establish e.g. 'how long does subtraction actually take?' with all of the contextual factors being incorporated into the variance of that measurement. That could help iterate faster when designing things.

This is probably not something that an individual GM would have the resources to make much use of, but it might be interesting to e.g. aggregate data from GitP groups playing different systems and then establish roughly what the time factors are for addition, subtraction, etc.

Anyhow, this kind of quantification feels like it's for fine-tuning rather than justifying one system against a wildly different other system, or doing very coarse ballpark stuff where intuition would be enough to basically figure which will be slower. This is more like, if you were designing something like 2ed vs 3ed and you had to figure out if e.g. 'roll plus negative modifiers below your stat' or 'roll against a flat DC from a table plus positive modifiers' is faster. So like 10-20% improvement level of optimizations.

Even if you don't actually use numbers, the idea of breaking down the actual mechanics into their elementary components seems to make a lot of sense (and was the original concept here). If you can find two mechanics that, despite how different they look, break down into similar steps, they should resolve similarly, all else being equal. The numbers are just rough relative rankings--the values aren't really that important as long as the relative scale is right. All else being equal, an experienced group with a simple mechanic will spend less time per resolution than an equivalent group with a more complicated mechanic. Relative ranking is what's important, to me at least.

I do think that it's good to consider the effect of a mechanic on the learning curve. A simpler (fewer moving part) mechanic should be simpler to learn and come up to speed on, while a more complicated one has more nuance to exploit once you know how it works. In game design, just like in everything else, there are trade-offs.

[FreddyNoNose]

I've been thinking about how long the fundamental operations of any non-freeform RPG system take. Not in real time (because that varies wildly by table), but in terms of the elementary operations that make up all resolution mechanics. Dice rolls (or other randomizers), arithmetic, comparisons, branching, and table look-ups.

Here's what I've come up with in terms of the elementary operations. The numbers in parentheses are an estimate of the cost of that operation in arbitrary units.

• Roll N dice (1): Roll(N). Rolling N dice is no slower than rolling 1 die (for reasonable N). Rolls that can't be done at the same time must be counted separately.
• Adding/subtract two numbers (1): Add/Subtract. Adding N numbers takes N-1 additions.
• Divide two numbers (1 for halving, but higher as the denominator increases): Divide
• Multiply two numbers (1, 2 for higher multipliers under 10): Multiply
• Compare two numbers (1): Compare
• Non-numeric conditional branch (5?): IF
• Table lookup (10): Lookup

A 5e D&D attack roll, saving throw, or non-opposed ability check (without advantage or disadvantage) has the following cost:
Roll(1) + Add + Compare(to TN) = 3.

With advantage or disadvantage, the cost increases by an additional Compare step:
Roll(2) + Compare(take highest) + Add + Compare(to TN) = 4.

A standard damage roll (N is the number of damage dice): R(N)+ (N-1) x Add + (Add OR Subtract)(from HP) + Compare (damage to max health/0) = 2 + N

On the other hand, a wild magic surge has a huge cost, which grows if you roll the result that requires you to roll 2 more surges, ignoring that result:
* If the spell that triggers the surge doesn't deal damage, then the cost is: [Save] + Roll(1) + Compare + Roll(%) + Lookup = 19 total.
* If it deals damage, add 2 + N to that, for a new total of 21 + N.
* If you have to reroll, the total cost is [Wild Surge] + 2 x Roll(%) + 2 x Compare + 2 x IF(ignoring repeated rerolls) + 2 x Lookup = 53 + [2 + N]

At low/medium levels, a standard PC turn is usually something like 2 x [Attack/Save] + [Damage], for a total cost/turn of 9 + the number of damage dice rolled.

A 3d6-based system (replacing 1d20 with 3d6) would end up at 4 for a basic check: Roll(3) + 2 x Add + C.

Adding in degrees of success/failure increases the cost of a check by an extra comparison for each extra fixed degree of success or failure possible beyond success/failure (botch/succeed with consequences/succeed/great success) would add 2 comparisons.

My preference is for the time cost of a mechanic to scale inversely with the frequency of that mechanic. Things you do a lot should be very fast, things that you do infrequently can take longer.

Is this a sensible framework? Are there other fundamental operations? How do other systems stack up for their basic operations?

IMO, watching other people run games, the thing slowing down combat is the players. Not saying it couldn't be something else. If the GM is new and doesn't know the tables that will take time. But combat should be quick from the dice aspect of it. ToHit is trivial, addition/subtraction is trivial.

If you want to speed up some there are a few things you can do.

1) Time limit on player decision to take action. They shouldn't have to think each melee round about the nth degree of everything. If they say they want to observe or figure something out before taking an action, than that observation/figuring is their turn and the action can take place the next. If they can't come up with what they are going to do, then their player is standing their wondering what to do. It isn't as if they aren't paying attention to what is happened during dice resolution or during other players turns.

2) Damage roll. Use what Len Lakofka did: no damage rolls, just use the average damage. Long sword 1d12 vs large will always be 6.5 dmg. That 6 dice fireball will always be 21 points of damage before S.T.

3) Roll more than one die at a time: example roll 3d20: Green d20 tohit, Blue d20 for crit backup roll, Red d20 for Crit resolution. If you don't want to spend time on crit resolution just give full damage instead of half on crit. Example: Long sword 1d12 vs large will always be 12 dmg on crit.