Is math a flaw?

[kitsune9]

I've been working on a system for a few weeks now. At it's core, the system's challenge resolution mechanic is 'd100 roll high'. It's almost like d20 multiplied by 5, which means that mid to high levels frequently involves adding three-digit numbers.

Is this a flaw? Would you buy or play a game that expected you to add or subtract those numbers in your head? If you found yourself frequently reaching for a calculator [app], would you resent it?

I have a thing for crunch-heavy systems to where the end result is adding three digits numbers (i.e. Rolemaster is fun in my opinion). I think the turnoff for these systems is if you design where the math comes after you've had to add up a myriad of situational modifiers ("Okay, I add 39 for skill, +80 for the weapon bonus, -20 for range, -30 for difficulty, +5 for being on higher ground, -20 from my wounds, so my total bonus is....").

I think if I was designing where the math came in that high, I would eliminate as many situational modifiers as possible ("You have a +40 bonus to hit with your weapon. Roll.") or make them very easy to add up (like in multiples of 10 instead of multiples of 5).

 

[Charwoman Gene]

It's unfortunately a big flaw.

It's the carry that does it. Adding 2 numbers that are both more than one digit takes everyone a lot more effort for many people.

I'd say the way to retain the fine adjustment is to bake all adjustments into the target numbers.

 

[IronWolf]

I'd have no problem with the system but I do game with people that would not want to do that much math in their head.

Hey! I fear no math! Besides, I have a myriad of electronic devices to help me with the hard stuff!

 

[Recidivism]

I think you could possibly get away with it if you also include a free phone & tablet app with your game that handles all the calculations.

 

[Mishihari Lord]

Both here and on other rpg forums I've seen complaints that subtracting one digit numbers in task resolution was too hard/too complicated/too much work. I personally have no problem with your system, but I suspect that lots of people would.

 

[steenan]

A lot depends on how often you roll, how much rolling corresponds to a single meaningful decision taken by a player and an action taken by a character. If one rarely rolls, three-digit arithmetic is not a problem. If there are several rolls per action and several actions per discussion or combat, the little amounts of time required for calculations quickly add up.

 

[Janx]

Math is Hard!

Celebrim nailed it with his explanation of the many reasons.

1% granularity is probably not worth the pain of having to add up 34 + 87 to get a combat result.


the answer of 121 took me several seconds to figure out in my head (which has a headache). It did not feel like a fast operation. Not like dealing with numbers 1-20 and adding them together. In many ways, playing D&D for centuries pounds those combinations into your head so you don't actually add them, you simply know that 12 + 3 is 15. kind of like memorizing the multiplication tables.

 

[Celebrim]

Since we seem to have scared you away with our harsh critique, I'll try to make ammends by outlining a D% system as I would design it. It would move the computational costs of the combat system into the 'compile' time by precomputing a small table of success points.

Basic combat skill (ei, small melee, large melee, balistic missile, unarmed, firearms, thrown, etc.) would be indicated by a percentage chance to hit and would be resisted by an appropriate active or defense skill (ei, active dodge, active parry, passive deflect).

From this basic skill level, you would precompute a list of chances to succeed based on task difficulty. Easy tasks would succeed at your base skill level, say initially 60%. Average tasks would succeed at (base skill level - 5)*3/4. Hard tasks would succeed at (base skill level - 10) * 1/2. Very hard tasks would succeed at (base skill level - 20) * 1/3, and impossible tasks would succeed at (base skill level - 40) * 1/4. These are all calculator level calculations, but we can do all of them at compile time and produce an array written down on the character sheet that for example, might tell us the chance to hit a target with a bow or gun depending its range or cover. In the case of the '60%' chance we are using as an example, these would be something like: E60, A41, H25, VH13, I5.

To further add situational granularity, we would allow characters to designate a secondary skill that influenced the base skill whenever they had appropriate circumstances. The secondary skill might contribute 20% of its value as a modifier to the base skill. For example, a character might be an expert in tactics and would be able to apply his tactics skill as a secondary modifier whenever he held a tactical advantage of some sort - you hold higher ground, opponent is prone, opponent is on a slippery surface, whatever. Instead of worrying about listing each modifier depending on circumstances, we abstract out all the modifiers as a single circumstance modifier that depends on how skilled the character is in taking advantage of the situation. We could also use a different secondary skill, like say a martial artist that can apply his atheletics skill as a secondary modifier whenever he is in melee combat and his movement is not impaired. Or we could allow multiple secondary skills depending on how complicated we wanted to allow character sheets to be. In any event, assuming we had a 60 in tactics, we'd then write underneath our base combat skill something like 'Tactical advantage': E72, A50, H31, VH17, I8.

Obviously, we could invert all of this to 'roll high' by subtracting the results from 100.

If we had a system of 'Perks' similar to D20 feats, we could imagine all sorts of perks that would modify the system. Anything from, "Add 25% of your tactical secondary skill rather than the normal 20%", to "Add +2 to your chance of success in all difficulty categories when using a long bow.", or "Treat each difficulty category as being one less when using a ranged weapon."

Now the really big question you need to ask yourself at this point is, "Why would I want to do something like this?" That I really can't answer for you.

 

[darkwing]

The main problem I see with most RPGs is they're too focused on adding and subtracting numbers from some other numbers. If the game has more math than RISK you should probably go back to the drawing board. Unless you're designing a CPRG, in which case feel free to go crazy with the math but keep it in the background.

 

[Celebrim]

The main problem I see with most RPGs is they're too focused on adding and subtracting numbers from some other numbers. If the game has more math than RISK you should probably go back to the drawing board.

There are basically two mechanics upon which rest all of RPG diced based proposition resolution.

The first is as you put it "adding and subtracting numbers from some other numbers". The idea is that you have to roll above (or below) some target number. However, sometimes this is easier or harder than normal because of circumstances and you add or subtract from your roll.

Is <fortune> + <modifier> >= <target>? If so, say, "Yes."

There are variations on this theme. One common variation is that the target is also randomly determined by fortune. This leads to greater unpredictability at the cost of an extra dice throw. Another common variation is to standardize the modifier on the basis of subjective difficulty, so that for example an easy task requires beating a target of 10 while a hard task requires beating a target of 30 (equivalent to get a circumstantial -20 modifier on the task). Some games, like D20, tend to do both which gives you a lot of granularity at the cost of being fiddly. Another common variant is to throw more than one dice and then some up the results in order to obtain your fortune. More dice gives you a more predictable result by producing a bell curve, but has the cost of more difficult math, additional effort to read the results, and can break the game by being too predictable at high levels of character power.

Mechanical RPG design in my opinion is largely a matter of figuring out which tradeoffs among the many variants are best for the particular game you are trying to make. Do you want fast play or granularity? Do you want unpredictable gritty random death and injury, or for the protagonists to tower over their foes in a predictable fashion? Are you willing to tolerate are large amount of subjectivity, or do you want to encourage competitive play by making the system less open to interpretation?

The other mechanic is basically a coin flip. Flip X coins to obtain at least Y heads. You can vary this quite a bit too, but oddly this mechanic tends to end up being more complicated than simply adding and subtracting numbers from other numbers. For one thing, its not trivially obvious to most people what the odds of flipping at least 3 heads on eight coins is, especially if you've done anything wierd with the 'coins' so that 'heads' and 'tails' aren't the only outcomes. In my experience, they tend to have all the problems of all the variants on "adding add subtracting numbers from other numbers" combined. They are fiddly, require extra mental effort, have complicated math, are unpredictable and quickly break as the dice pools get large. I've never liked them much, but I'll tolerate any system if the game is good enough and ran well enough.