Something I’ve been thinking about lately is how the various operations in a game system generate extra math, so that I can try to figure out what would be the best methods to keep extra math down (best core mechanics), and build a more elegant system therefore. So how to use math to fight math.

What I mean by ‘operations’ is hard to explain but I mean stuff like:

*generating stats in the first place – whether by point buy or by random roll. This function might also be re-used in e.g. power score generation.

*recalculating stats, and then any modifiers from stats i.e. your Strength is 15 which gives you a +2 modifier, you’re fatigued and lose 4 Strength, yourmodifier is now +0. Aberrant very easily calculates changes i.e. rolling Strength+ Mega Strength dice separately means that a power that turns off mega-strength is easy to calculate, but any roll involves lots of dice.

*the core game system handling time (i.e. compare rolling under your stat, vs. rolling d20+bonuses, to rolling several dice and scoring ‘hits’). More dice or more calculations/larger numbers slow this down.  Particularly a problem on multiple rolls i.e. 10 archers shoot at a PC.

*generating an ‘effect’ output from the core system. So while the ‘roll dice and count successes’ is probably more complicated than d20+modifier, the number of successes is directly useful for damage, soaking, etc., while the d20+mods system means you then have to compare total to target number, subtract, and probably divide by 5 etc. However, not every roll strictly requires an ‘effect’.

*generating ability damage i.e. whether the system has big enough numbers that you can use CON as HP, or need two separate values for CON and hit points.


There are a couple of other more esoteric operations as well, perhaps:

*handling a “zero” intuitively. Many games will adjudicate that a character reduced to 0 Strength is unable to move or 0 Con is dead, reduce a character’s Dex to 0 if they’re sleeping, etc.  Game mechanics might give a zero a modifier still (doesn’t automatically fail without extra rules).

*skill-stat crossmatching i.e. choosing to use Strength for one athletics check and Dex for another.

*mult-stat checks i.e. letting multiple stats modify a single roll. In some systems this is done to better simulate a task where multiple stats seem relevant, in others its a reward (paladins adding +Cha bonus to rolls as well as another bonus).

*universal scale/reapplicability –  systems might have powers that follow the same scale as stats, opening up simple options for power use like e.g. Telekinesis works as a Strength score, etc. Marvel Super Heroes has everything on the same scale, from object Material Strength to Popularity.

*diminishing returns. May be good as keeps bonuses under control e.g. the belt of giant strength adds 7 to the weak PCs strength but only 3 to the stronger PC.

Below that, I’ve tried to look at what the ‘drivers’ are underlying these things:



Note that by ‘amorphousness’, for want of a better word I mean that a single stat is used for rolling results. For instance in Marvel Super Heroes a character might have a Strength of Remarkable, but the system doesn’t easily handle large extra modifiers from skill etc. without breaking so the raw stat is used on checks. Likewise in Savage Worlds, a character has a stat or skill of d6, or d8, but the system can’t easily handle a [Strength+Athletics] roll the way e.g. Storyteller or even 3E D&D could.


Then comparing the drivers, looks like some of these things – directly oppose other things (the drivers that make one operation easier directly make another operation harder i.e. a large scale makes ability damage more workable, but means modifiers are necessary (making stat recalculation more difficult).
That's shown with a line in the diagram.


So questions:
*am I missing any basic operations from my haphazard list there?
*How to figure out which operations are most important, to figure out what should be priorized if they oppose ?

I'm not entirely sure what you're getting at here but for myself this kind of thing usually gets divided into two drags/immersion breakers, namely overhead and accounting.

Accounting is by far the slowest and most awkward part for most players, that is doing calculations based on dice rolls and noting down results, especially if those results have a significant ongoing effect on future dice rolls - ie a death spiral.

You want to front load the accounting as much as possible, so in character creation it's a lot more acceptable than in every single combat roll.

Overhead is having to look things up, especially if the results are likely to have an effect on future rolls. Less stressful than accounting but no less time consuming - however this can be mitigated by putting common tables and results on a cheat sheet, and noting key elements down on character sheets, ie a THAC0 table.

Overhead is generally preferable to accounting in common actions for this reason.

Using those two metrics alone the smoothest game would therefore be one where nothing on the character sheet ever changes, but that of course wouldn't be a game at all, so the trick is to find the balance you're comfortable with.

Again I'm not sure if that's what you're looking for but I think we're in the same ball park. It's easier to look things up and cheat sheet them, than calculate them on the fly.

Eep, if you can't follow this I'm in trouble.

Looking back at it I'm not 100% happy since I've invented two spurious words to try to describe what I'm talking about, and I've probably not spelled out my assumptions or whatnot enough, but writing out what I had there even was fairly exhausting.

To backtrack a bit and try and explain - I'm trying to figure out what sort of core mechanic & stat scale does everything important with the least amount of calculations. Each core mechanic should have a set of operations that it performs slightly more easily, but with a trade-off in some operations that become more difficult.

Each operation is a sort of function that might be used as the basis for a number of game rules - stat changes for instance might be involved in rules for handling fatigue, being polymorphed into a chicken, being enlarged magically, Rage, or even for taking damage (for games where CON = hit points), being petrified (DEX damage?), etc.

'Effect Conversion' (bad name, sorry) could be involved in calculating damage, spell effects, how well any roll whether diplomacy or climbing or whatever succeeds.

(and so on for other operations).

Your distinction between 'Accounting' and 'Overhead' is a good one... For my purposes here I'd have to consider whether a a system is making life more difficult once-off (in char gen) vs. over and over again ? E.g. how in dice pool systems you don't need to work out a modifier if your stat changes (=ease of stat recalculation), but you always need to roll lots of dice (=more core system handle time).

Okay, so you're developing an algorithm to track the amount of mathematics involved in various game events, putting the amount of mathematics for each event on a scale from 'not much' to 'too much', and using that to reduce the overall amount of mathematics by swapping out high maths for low maths when possible, or desireable? And then tracking all of the relationships between operations that depend on these calculations?

If I have that right it's worth considering that time taken can often be a factor as well as brain strain. Rolling buckets of dice and counting the ones past a certain number doesn't involve much brain strain, but it can over the course of several sessions become very tedious and consume more time than players are willing to accept.

So I guess, if I have it right, the question to ask is whether the goal is to reduce mathematics for its own sake or to produce a faster moving game, or what.

Interesting, and very close to what I mean when I talk about "discrete operations" in a game system though that goes beyond math to all individual steps in the process.  So while each modifier added would be a step, so would a table look up or a page flip for a special case rule.

Quote from: Bloody Stupid Johnson;640808Something I’ve been thinking about lately is how the various operations in a game system generate extra math, so that I can try to figure out what would be the best methods to keep extra math down (best core mechanics), and build a more elegant system therefore. So how to use math to fight math.

I generally like your threads as you're one of the few people here (I might go so far as to say the only other person here) that actually care about game mechanics. But I fear you've gone south with this one mistaking a means for a goal.

If one wishes to reduce math in a game to lowest possbile level, just have no rules at all. No rules, no math. You're done, and the goal of this thread is achieved.

What's that you say? You have other goals that such an approach fails at? How odd. Perhaps you should have started with those goals instead- and then worked out a system to meet them. After that, determined if the resulting math can be simpified.

It's the approach I took with Age of Heroes, which in complete truth has as little math as possible in order to reach the goals I set for it. It so happened that those goals were demanding, and thus the math in the game (while very easy for some people) is far more than basically anyone on this board is willing to even consider.

And that points out another flaw in what you're doing. People have different levels of acceptance of math in gaming, and for some there might not be enough for a given system to make the it interesting. A goal of reducing it to the lowest possible level might well be counter-productive in ways you haven't thought of.

I favor game systems that frontload needed calculations at character creation but have a simple action resolution during play.
The level of complexity should be only what is needed to make the game work. Reduce recordkeeping during play to the minimum possible.

I lack the math skills to create an algorithim.



Can't please everyone because some people enjoy or require crunch, and others do not.

Quote from: Bill;640936I favor game systems that frontload needed calculations at character creation but have a simple action resolution during play.

It's a matter of taste if one favor that approach or not.

But I'd like to point out that it comes at a cost. Longer character generation and thus a higher cost to enter the game.

It also typically results very uninteresting and boring resolution. So boring in fact that typically I see people in that camp saying in the same breath that they want to spend as little time as possible dealing with the resolution. In real terms, they want to go see Die Hard, but cut all the actions scenes down to 30 seconds total in the move and focus on finding fire hoses and the yippie kay yay parts

Quote from: Bill;640936The level of complexity should be only what is needed to make the game work. Reduce recordkeeping during play to the minimum possible.
...

Can't please everyone because some people enjoy or require crunch, and others do not.

The second part of that is key, and can easily override the first statement. And just because you don't have it in the rules doesn't mean that the players won't find it on their own.


One of the interesting things about the 'Let's play D&D' threads a while back to me (besides the fact they were mind-numblingly boring, but that wasn't interesting and it was expected) was where they were spending all their time.

Having selected a mapless version of the rules with no minis (and thus boring combat), they spent post after post buying gear- i.e. record keeping. This to give them assets (whose use was typically not covered by the rules) that could later be use to convince the GM that they had the tools to achieve whatever goal might come up.

Having removed much of the game system's record keeping and system overhead- they just replaced it with another type. Buying and inventory and debating the fine details of travel.

It was amusing. The game should have been renamed Accountants and Trivialities. Imagine the Lord of the Rings movie with endless scenes of buying stuff as well as those showing walking...

Quote from: gleichman;640944In real terms, they want to go see Die Hard, but cut all the actions scenes down to 30 seconds total in the move and focus on finding fire hoses and the yippie kay yay parts

A tv show which is very much like this, is "Person of Interest".  (Especially season 1).

Quote from: gleichman;640919I generally like your threads as you're one of the few people here (I might go so far as to say the only other person here) that actually care about game mechanics. But I fear you've gone south with this one mistaking a means for a goal.

If one wishes to reduce math in a game to lowest possbile level, just have no rules at all. No rules, no math. You're done, and the goal of this thread is achieved.

What's that you say? You have other goals that such an approach fails at? How odd. Perhaps you should have started with those goals instead- and then worked out a system to meet them. After that, determined if the resulting math can be simpified.

It's the approach I took with Age of Heroes, which in complete truth has as little math as possible in order to reach the goals I set for it. It so happened that those goals were demanding, and thus the math in the game (while very easy for some people) is far more than basically anyone on this board is willing to even consider.

And that points out another flaw in what you're doing. People have different levels of acceptance of math in gaming, and for some there might not be enough for a given system to make the it interesting. A goal of reducing it to the lowest possible level might well be counter-productive in ways you haven't thought of.

Thanks Gleichman. Likewise, I always look forward to your threads.
 I think I've misconveyed what I was aiming to do - I'm not trying to get rid of all math, so much as try to determine the approaches that are most efficient. The idea being that by making individual steps easier, the whole can then be made more complicated without being unwieldy.  
 Its again probably not clear, but I'm not just trying to minimize math but also trying to think about the number of accessory rules, needed to get a system to do what it wants to. Also trying to figure out which things are virtually impossible (makes sure I'm not trying to build a perpetual motion machine).
You're quite right the above doesn't consider other things besides just complexity here. I'm not sure how to, at this stage.  OK, it does read a bit insanely but I realize that in trying to build a model it is JUST a model, and that the conclusions aren't necessarily more than a guideline. Mostly I'm hoping that people may have some interesting ideas  here (e.g. your point made me wonder if there are rules that are simple, that however bloat inordinately when extra calculations are required).  
Getting a mathematical model say is more or less impossible since all of the individual factors are slippery and subjective....and hence final results would be completely undependable...which I realize.  I'm finding the process of building it somewhat informative though.

Quote from: Bloody Stupid Johnson;641028I think I've misconveyed what I was aiming to do - I'm not trying to get rid of all math, so much as try to determine the approaches that are most efficient.

Right here is where things get tricky. Efficient towards what end? Speed? Player enjoyment? Realism? You need to define your goals a bit better.

Quote from: David Johansen;640904Interesting, and very close to what I mean when I talk about "discrete operations" in a game system though that goes beyond math to all individual steps in the process.  So while each modifier added would be a step, so would a table look up or a page flip for a special case rule.

I think that's similar to what I'm talking about. I would include those things, except that what I've called an operation here is a generic component used to build up a rule or part of a rule, likely repeated throughout the system. Depending on the game it might be a simple calculation, or a table lookup, or perhaps a dice roll, or have a few steps. Then the same operation is likely to be used again elsewhere in something else (a "function call" a programmer might say). Not quite so fine a scale as "discrete operations". I'm definitely open to a better word (function? subrule?).

Quote from: The Traveller;641031Right here is where things get tricky. Efficient towards what end? Speed? Player enjoyment? Realism? You need to define your goals a bit better.

Er, I've always been bad at that. I have my own set of preferences in terms of speed, realism, etc. that I tend to design to as I go, whether or not I can articulate them. All those things sound good.

Edit: I guess 'efficiency' would let me have more things at once that are somewhat at odds. Not hard to design a super-fast system that doesn't have realism or player enjoyment.

Quote from: Bloody Stupid Johnson;641028I think I've misconveyed what I was aiming to do - I'm not trying to get rid of all math, so much as try to determine the approaches that are most efficient. The idea being that by making individual steps easier, the whole can then be made more complicated without being unwieldy.

Yeah, I think we're looking at this from such different points of view that it's going to be hard to understand.

Trying the switch gears on my end, are you perhaps looking for a toolbox with weighted complexity that you can then draw upon to a new game design?

Quote from: Bloody Stupid Johnson;641033Er, I've always been bad at that. I have my own set of preferences in terms of speed, realism, etc. that I tend to design to as I go, whether or not I can articulate them. All those things sound good.

All those sound good, but don't hold much meaning without details behind.

I was going to launch into an example of how I end up working through them, but I think it would just derail this thread (and I'm not yet really certain what the goal of the thread is in the first place).