When does combat resolution become too slow?

[John Uckele]

The answer to the question "How long is too long for combat resolution?" Would be T where T > 0.

You shouldn't be content if your combat resolution drops below a certain point. If it's fun, and making it faster would make it less fun, keep it as long as it is. Otherwise, faster resolution is better, so strive for it.

[Jack Aidley]

Dauntless,

And I believe this to be a false dichotomy.  People tend to get the notion in their head that once a system becomes more detailed, the more rigid and hence less flexible it becomes.

That wasn't what I meant at all, Shreyas's description is much closer to my thoughts on the matter. It isn't a matter of fudging or not. Fact is, any roleplaying game that sets out to be realistic will always fall short of it's target because that would require nothing short of a full physical simulation - a proposition that is clearly absurd.

Every rule, therefore, is an abstraction and the more rules you have the more abstractions you have. The more abstractions you have the more likely it is that one or more of them will produce a situation that hits the 'not realistic' button with one or more of your players.

Seems to me, realism is a myth anyone - what we're really talking about verisimilitude, or the appearance of realism. In a fast resolution combat system there are fewer points where that appearance needs to be maintained, and thus, again, less chance of hitting one or more players 'not realistic' button. Ultimately however, once ones realises that it's actually the appearance of realism that you're going for one must also realise that this is always going to be a subjective opinion and, thus, a matter of taste rather fact.

And so, ultimately, we're back to my first statement "There is no relation between speed of resolution and realism of results". Which I should, perhaps, have left at that.

[contracycle]

Well, this can be more simply put -- more rules means more places for your rules to be wrong.  This is absolutely true, but it is also an empty argument in my opinion.  Actually, I consider it to be a rules-lite fallacy -- that doing nothing is better than having mistakes.  The faulty logic puts more burden of responsibility on the players/GM, then when things go wrong it's their fault rather than the designer's.

Hmm, I'm not so sure.  Any given rule might be wrong, but the more rules you have the more likely it is that an unexpected combination of rules will be badly wrong.  This is how many of the Murphy's instances arise, they are applications of obscure rules to unusual circumstances.

[Dauntless]

Jack-
A model is by its very definition an abstraction of a system in order to make it easier for us to understand or implement.  When as a designer or scientist you say that you are going to model something realistically, you are not trying to make it exactly follow physical reality.  Instead, you take the most essential and crucial qualities of what you are trying to solve and create a model out of this, not to get exact numbers, but to help our understanding or to get decent approximations.  No simulation will ever be completely realistic.

However, as the quantity of factors of we consider for the model increases, and as we get a better understanding of how those factors interrelate to one another, the closer our model's predicted value approaches the theoretical (or observed) value we get in reality.  This is what we mean by a "realistic" approach to a game system.  It's values tend to more closely approach values that you would get in real life.  

As a debate to your argument, I correlated the notion that speed is tied with two factors:  quantity of operands (the data the resolution process must work with) and calculation time.  The operands are the factors that are somehow involved in the computing of a resolution.  At this point, some may be thinking that I am thinking on a purely mathematical and formal viewpoint.  However, the operands that I am thinking of are important no matter what heuristic we are using...whether it be the rigid and precise algorithm of a flowchart where you have to look up all the factors in a table, or whether we're simply having to think about the variables in our head that influence what the "difficulty number" of a task is.  Now, the actual heuristic we use is important in the calculation time.  Calculation time is based on what methodology you use once you've determined all the operands (all the factors that contribute to deciding the probability of an outcome).  This is where traditionally, the "realistic" games lag considerably behind more generic and abstract systems because the heuristics they use are much more mathematical or require mroe "hoops" to jump through.  It is in the methodology we use that the most time can be saved.  But the number of operands is a constant.

So I've answered both the functional definitions of speed and realism.  Speed of resolution of a task is not much different than calculating the speed of a mathematical or programming algorithm.   Again, algorithm connotes a purely mathematical or computer definition, but in truth the definition of an algorithm is simply this: a series of steps taken to provide a solution.  Each of those steps requires inputs of data and/or a calculation/decision to be made.  My argument was that speed and realism are intertwined because in order to get results which are clsoer to real(observed) or theoretical values, we must include more operands (data inputs).  Furthermore, whether you use the "fudge" heuristic or the rigorous and precise method of going through all the formulae and die mechanics, the number of choices (operands) is still a prerequisite to more closely approximate reality.  In other words, your calculation methodology may change, but if you limit choice, then you limit precision.  It's like saying that you can get just an accurate a measurement of a quarter if you only have a ruler marked in feet as if you had a ruler also marked with inches.  

Ergo, the greater number of options, inputs or operands we have, the better our approximation will be.  Concurrently, the greater the number of inputs, operands and options we have, the greater time our calculations will take no matter what heuristic we use to solve the problem.  Hence, speed and realism are inseperable.

[Dauntless]

Where I'm concerned about speed issues is in drawing a fine line between playability versus lots of tactical detail.  As I tried to point out earlier, there is a correlation between lots of choices and speed of resolution.

I like the idea of having lots of choices as inputs, but this greatly increases not just decision making time, but also causes an increase in calculation time because of the interdepencies of these inputs.  For example, choosing to exert myself to increase damage may have consequences if I'm injured or are already fatigued.  First comes the time in deciding whether I want to exert, and secondly comes the calcuation cost of figuring out the interdependencies of this with other variables.

But I really think I have a higher priority on the greater number of inputs and choices.  The reason is that I want the players to understand that these choices are relevant and have an impact on the outcome's probability.  Sometimes, players aren't even aware oc the choices available, or how those variables can influence the outcome.

The obvious question may be to ask "when does a resolution system becomes unplayable due to time factors?".  Perhaps the question should be asked, "even if the resolution takes a long time, if the resolution process itself is interesting, should it matter?".

[Jack Aidley]

Dauntless,

Yes, the whole speed vs. realism has been rather a sidetrack. Sorry about that.

One thing I tried in one of my many homebrewed systems was having 'action cards' for combat. Since each card had it's own rules the process time wasn't too high since you neither had to remember or look up anything. While the cards also allowed inexperienced players a clear list of what their characters could do.

Would it be possible for you to adopt a similar system?

The obvious question may be to ask "when does a resolution system becomes unplayable due to time factors?".  Perhaps the question should be asked, "even if the resolution takes a long time, if the resolution process itself is interesting, should it matter?".

That very much depends on what you want out of the game, doesn't it? If you want to spend your time in the sessions dealing with combats then, no, it doesn't matter. If you want to concentrate on other parts of the game then it is a problem.

[Mike Holmes]

I think that part of the problem is, once again, that term "realism." We've had several threads going over this, and there are at least three commonly used meanings for the term. I'll break down the two being used here:

1. Input Realism - where the model is more "accurate" because it considers more factors. That is, it's giving a more fecund representation of reality because it's considering more of the input that would exist.

2. Output Realism - where the model is more accurate because the output is more faithful to what really happens.

These correspond to the two basic forms of simulation (which I get from Ralph Mazza). Obviously, Dauntless is talking about the first type, while others are talking about the second. As long as we don't realize this difference, we'll keep talking past each other.

Because for certain players, more mechanical input detail is, in fact, important to play. This is hard for those who like less input detail, because they note that it actually decreases the output realism on occassion (not always), and they don't understand the fun that's gained from that sort of detail. This is a very simple mode question when looked at on that level.

So Dauntless's question is valid, if an ancient one. It's the "realism v. playability" debate yet again. To which the only valid reply that I've ever heard has already been given. Basically, it's not trading these off that's in question - that is, there's no horizon at which too much realism leads to unplayability. It's a question of producing as much realism while not making the game a chore. This is not the same thing. The first assumes that there's a line along which you travel, and at some point along it you pass into the unplayable territory. Think instead of it as a two dimensional space with each of these being an axis. What you're trying to get to is the "Completly Realistic/No Difficulty to Play" corner of the space. Any tradeoffs that do exist move things back along the axis not chosen, but often the solution is to find another method that does not require a tradeoff -or at least a lesser one.

Yes, this is hard to do, but how good a game is in this context depends completely on how well you push for that corner. Not how close you get to the unplayable line. I can give examples of this, if people like...

As mentioned before in the thread, it's about producing an output that reflects the input in the most interesting way possible, and doing so regularly. What I've termed on occasion, Fecundity of Critical Feedback. To a large extent, the benefit of any system can be gagued by how well the output is recieved, and how well it spurs further play. Basically, how good a feedback loop is created.

Now, how to do this? Again, that's like asking what makes something taste good, or what makes one painter better than another. If we knew, we'd be doing it in spades. That is, this is precisely the skill, as Shreyas notes, that all designers need to develop.

Is there a way to enumerate this skill? Well, that's hard to say. Sure you can do Human Factors analysis on the algorithms, and determine the effort required. That's pretty easy to analyze. But the problem is that the quality of the output is so subjective. One player might like to see factor X looked at, another factor Y. In fact, this is what makes complex designs problematic (as Shreyas, again, notes), you don't really know what people want to look at in terms of these details.

Further, there are an infinite number of factors that one could look at with any interaction. For guns, for example, does your system include any analysis for the angle of incidence of the entry? Or is that abstracted into the "to hit" roll? Because it's absolutely pertinent to the discussion of armor penetration - you see it all the time in WWII simulations in discussing sloped armor on tanks. Turns out that it's rather important to the functioning of body armor, too, depending on what it's made of. Does the system include factoring for the psychological factor of wounding expectation? That is, do people fall down when shot because they think that's what they should do (given that it's the only reason that people who are shot fall over for, short of the very rare instant kill)?

Do you model the effects of hypertension on bloodloss? That is, do you consider how much salt someone had to eat before being cut open?

When it all comes down to it, what we really want isn't so much a simulation of everything that can happen in terms of inputs, that's impossible, but just what's interesting to model overall. And, again, what that might be can vary tremendously.

That doesn't make it impossible to make a fun game of this ilk, but it does make it, to a large extent, an act of intuition to determine what's going to be fun. Meaning that asking about what makes sense here is going to get you the output expectations of the players in question. Hence why those who focus on Output Realism give the answers they do here - no amount of quality of input in terms of detail will improve output for them, in fact it sometimes detracts. The only thing that will satisfy them in terms of input is to have control over the important parts of the character's destiny to make the output fun.

For other people, they're going to answer that bullet calibre is most important. For others, the question is what choices do I make for the character in terms of combat maneuvers to forming winning strategies.

The best advice I have (and I ain't saying it's too helpful), is to find that output that you personally find most fascinating, find ways of producing it well, and then work on the elegance of the game, making it easier and easier to get the desired outcome. There's no garuntee that other players will find interesting the same things that you do, but that's the problem faced by all designers at the most basic level. Going with what you like, however, means that there's a chance that somebody else will like it, too. If you change what the game looks at to satisfy some theoretical audience expectation that you don't have, you very much risk losing everybody.

Mike

[Dauntless]

Mike-
You hit the nail on the head.  

If you measure realism by the output, you have two things to consider; its accuracy and its precision.  Accuracy is how close the measured or derived value is from the true value.  Precision is consistency in your measurements or derivations.  For example, if you step on a scale 3 times in 10 minutes and it gives you scores of 160, 150, 170, then the average is 160.  If 160 truly is your weight, then the scale is accurate.  However, it's not exactly precise.  An accurate and precise scale might give you scores of 160.5, 160, 159.5 which also average out to 160 but the values are more consistent.  In other words, given the same set of inputs (in this scenario, your true body weight, and time) and same initial conditions, the expected value should be the same (over a large sample).

Generally, both accuracy and precision are required for positive feedback to verify the "validity" of the rules.  However, sometimes it is possible for a resolution system to be inaccurate but precise, which misleads people into thinking the results are accurate because of the consistency.  It is also possible for a system to be accurate as an average, but have poor precision.  Systems like these have very large standard deviations, but the median result happens to coincide with the average.  These games may feel realistic, because on average, you get the true expected outcome.  However, these games are also (in)famous for the whiff factor or its opposite (that I call the hooaah factor).  Some people like for the game to have the potential for catastrophic failures or triumphs over impossible odds no matter how realistic they may be.  So again, you have to make a design decision whether that's what you'd like or not.

As you mentioned with the graph example, with playability as one axis, and realism as the other....ideally we'd like to create a game which has our game at the corner which has high playability and high realism.  I personally think that they are inverse relationships (to a greater or lesser degree).  Hence, you sacrifice some playability to make things more realistic, or some realism to make it more playable.  Notice that I said realism...but you can substitute accuracy or precision and retain the same meaning.  However, it's not a perfect inverse relationship, and I think there is a point where if I sacrifice 5points of realism, I might gain 6 or 7 woth of playability (and vice versa).  Finding this tradeoff, and determining where on the curve you want to be are of the utmost importance to a game designer.

[Mike Holmes]

Shades of "Absence of Malice" there, Dauntless (see the last line of the movie, amongst other things).

I'm a fan of the distinction you're making (I'm a statistician after all), but this is ancillary to the point I was making. If it was paraphrasing me, then I haven't communicated well. If it was just additional info, I agree in general.

Just remember that what's precise on the input end depends on what you're trying to get on the output end. That is, there's no input that's a priori more important to have than another. The only question is which brings out the sought for output format.

IOW, work backwards from what you seek always, not from input forward. I think that's a common error.

Mike

[M. J. Young]

I like the idea of having lots of choices as inputs, but this greatly increases not just decision making time, but also causes an increase in calculation time because of the interdepencies of these inputs.

In Multiverser, there may be infinite choices as inputs; anything the player can think for the character to attempt to do to improve his tactical position can be factored in.

Most players don't do too many things. Why not?

For one thing, there is a sense that the default roll covers ordinary chance of success; to do better than that, you have to do something special. There is generally a cost to doing something special. If you aim carefully, you risk being shot before you shoot, for example. There is also a cost in terms of flow of play--if everything you do will mean it will take a little longer to resolve the situation, you'll select those things which benefit you commensurate with their cost in time.

Thus you might consider following that model, providing the opportunity for the players to choose whatever tactically beneficial options they wish, while covering all others as the default choices in the default rolls.

--M. J. Young

[Dauntless]

Mike Holmes-
Actually, all the stuff after the first line was additional commentary by me, and didn't mean to refer back to your post :)

Matter of fact, I was thinking of starting another post about this subject matter...how we can talk about the differences between what exactly modeling realism is from a simulationist (and I don't mean this necessarily in the GNS definition of the word) standpoint, and between the tradeoffs we make for playability.  The point I tried to make about accuracy and precision dealt with one of the ways we determine how close we are to the actual results, and your topic about dealing with looking at inputs to a function vs. the output (the probability) is yet another factor.

[Dauntless]

M.J.-
On further reflection, I think I should have worded my question something like this: "When does the tradeoff between accurate simulation and playability sacrifice too much to be considered accurate, but too little to be considered playable?"

For example, let's say I come up with a system that allows you to be within +/- 15% of theoretical or observed world values that takes 30 seconds to resolve.  Now let's say that I've come up with a different solution that takes 2 minutes to resolve the issue with a +/-5% deviation from the real.  Which is "better" given that the aim of my game is to create a world that seems very plausible and real...to make the playes think, "this could really happen to me"?

One might think the above question is ancillary to this one...."does it matter what the real world values are if it seems real enough" (if the credibility of the results is 90% of the time granted by the players).  However, I think such a question should be asked in my game design only for those things that we really have no "Real" world basis to go on.  For example, magic use, psionics or other things better left to the imagination.  Other cases this question might be valid are in highly chaotic, unpredictable or fuzzy systems (persuasion rolls, getting hit by a piece of shrapnel, the weather in Florida...).  In these situations, because we have no benchmarks to guide our accuracy, we have to rely on what "feels" right.  Nothing wrong with that in my book, though it seems to be a source of dispute for people who try to disparage complex rules systems in favor of lite rules systems on the basis of this argument (that not everything can be statistically verified and hence no mechanic can absolutely be verified as being accurate).

Getting to your point, when we abstract many choices into one large choice then we lose some amount of detail and control over the inputs.  Abstracting the choices does however make things much quicker because we now have less detail to worry about.  So the question becomes, how often are the inputs which have been abstracted out influence the outcome to a significant degree?  If the things we have abstracted out are sometimes very important, then our results get skewed out of reality.  But if this happens extremely infrequently, then the savings we get in time might be worth it.  So choosing inputs that abstract the aspects of a system that a) have little impact on accuracy and b) have aspects that rarely greatly affect probabilities is a good way to reduce time calculation.

For example, one of the questions I asked early on in my system was how to resolve the issue of what Strength really was.  Most systems lump many qualities of strength together...how much you can carry, how much you can lift, how fast you can move, and how much damage you do.  But if you really observe the human body, there are several variables that make up what we consider "strength" as a whole.  I divided strength into two categories, Power and Force.  Power is essentially the maximal amount of Force you can generate divided by time.  It is in essence neuro-muscular speed.  Gymnasts and martial artists must have high values here.  Force however is how much work we can do in an indeterminate amount of time (generally limited by our endurance).  Bodybuilders and powerlifters have high scores here.  But note that a gymnast or martial artists might be able to do more damage with a punch or kick than a bodybuilder that weighs almost twice as much.

Because I reasoned that needing to know the difference between these values would be very common, I decided that it was worth the extra level of detail and time required to split strength into these values.  There may be cases however where the differences between the different aspects of a skill, trait, or resolution are so minute that it rarely matters and it is safe to abstract them out.  I think finding these are a hallmark of good design.

[Dauntless]

Mike Holmes-
I do disagree on the comment that you should always work from the results backwards...and not the input forwards.

When you work from the output backwards, you are doing descriptive design.  You take the final state (the output) and try to find the essential input values that will work towards producing the output you want.  Working forwards from the input values and the initial conditions (the intial state), you are doing procedural design.  You create an algorithm and simply run the inputs through the algorithm (which is really just a type of function that maps given inputs and states into an output state).  Admittedly, it is much much more difficult to work this way because you're not looking for a desired outcome from a given set of inputs.  You just simply create an algorithm which matches the model you've created of your system, and see what happens with the given inputs.

For the majority of cases it is desirable to do descriptive design because it is more intuitive and easier to balance.  However, when we have a well known problem with the majority of the inputs known, then we can work in a procedural manner.

I'm also not sure all inputs are equally important a priori.  In fact, one of the reasons I want to have a lot of tactical choice is because I think players don't realize through logic and insight how important certain choices are.  Now if you meant that to mean that we can only determine their importance to the resolution process by mental faculty (a priori) and not necessarily through empirical observation...then I agree with you wholeheartedly.

EDIT-
I thought I'd give an example of a descriptive solution vs. a procedural solution.  The Hero system uses a descriptive solution in order to create anything in the game.  From characters, to vehicles to guns, it asks the player to think about what the object does, then you have inputs which you tie together to create the desired object (the final state).  In Greg Porter's Guns! Guns! Guns! supplement that creates guns, it uses a procedural system wherein you engineer element by element the constituent parts of a weapon system and create the final object.  For example, you start by designing the bullet (it's caliber, l:w ratio, density) and then how much charge it carries.  From there you determine that from the given charge, the receiver has to be such and such a mass for the given action type, and to be able to withstand the sublimation of the charge.  It's a much much more detailed system that is also much more integrated.  Now, procedural systems don't disallow the end-user to think; "hmmm, I want my gun to do this much damage and be accurate at long ranges".  You still have a desired output for the end user.  The difference lies in how the algorithm to transform the inputs to the outputs was achieved (and the algorithm implementation can often be encapsulated in such a way as to make it hidden from the end-user).

[Vaxalon]

"does it matter what the real world values are if it seems real enough"

This, to me, is the critical question.  "Realism" is impossible.  Not only is it impossible to achieve, it's impossible to experience.  What you experience is versimilitude and if you have that, you have everything.

[Precious Villain]

Hey Dauntless,

You claim to be ignorant of the whole gamist/narrativist/simulationist debate, so I'll suggest taking a look at "Simulationism: the Right to Dream" at http://www.indie-rpgs.com/articles/15/

I get the feeling that you're aiming at (jargon alert) a very high points of contact simulationist design that may well be "purist for system."  In that case, you can actually spend as much time as you want on combat resolution (or any other kind of resolution) because in fact part of the point of play is to input these steps.

This second bit is somewhat off topic, but it doesn't seem to have occurred to anyone either, so here goes:

One danger in producing a highly detailed combat resolution system is that the players will analyze that system, determine the optimal action for any given moment, and stick to that action over and over and over again.  F'r example: if firing maximum setting pulsed phaser bursts yields the best combination of damage, speed and accuracy then players will use only maximum setting pulsed phaser bursts.  There is some danger that you will build a system that is capable of emulating a staggeringly wide array of techniques, maneuvers and actions but that 90% of it will not be used because the players have found the *best* techniques.  Anyway, sorry for going off topic . . . :)