I used a term I like (as far as I know I coined it myself, but I'm sure it's been used before by others that I'm unaware of. Sun...New.. Etc.) in another thread.

Bloody Stupid Johnson asked some questions and I felt it was far enough afield from the original thread to make a new one.

Quote from: Bloody Stupid Johnson;642342Its not exactly something I'd thought about in those terms but I wonder what other examples are out there (of systems that fail this) and how they fail?

BTW: this seems relevant so bringing up for discussion...

http://www.enworld.org/forum/showthread.php?226856-Simulationists-Black-Boxes-and-4e

If I'm understanding correctly the 'black box approach' described here as a feature of 4E D&D design is more or less the opposite to simulation of process, used largely for simplicity. Or gameability as with D&D hit points - though perhaps it could still be said to be a simplicity issue since a more complex system could give similar results with largely fixed hit points, i.e. where combat skill adds to damage only against weaker opponents.

No, not really a good match but they are closely related. Let me try to explain the differences (although I do like the Black box vs. process-response for what it is). I'll make the attempt in two parts.


First- Black Box vs. Simulation of Outcome
For example Warrior B fights Warrior A is perhaps one of the most basic inputs in RPG. They are equal in ability so we flip a coin to determine who wins (that's the black box) and a winner is determined.

That whole process is Simulation of Outcome, while Black Box is the method used in the middle. The Black Box is a simplification, one so great that the entire process-response (using the link's definition) is completely invisible to us and is an example of extreme Abstraction.

It is not however a failure of Simulation of Process. Why? Because the process is hidden in the Black Box and we don't even know what it is

All we can do is judge how valid the Outcome was given the input(s). That's very important and worth doing of course.


Process-Response vs. Simulation of Process

Process Response is cause and effect. In D&D we can map each step of combat resolution, flow charting it out in detail. The result is a proper Process-Response when applied only to itself. What it's not is a model of actual combat. Armor doesnt' really make one harder to hit, a person's body is not abalative, damage that isn't damage in the real world isn't damage. And so on.

Thus it's a failure of Simulation of Process, as is any game mechanic that says X causes Y when in fact it's causing something else completely.

Basically the way to look at this is to imagine that you know nothing of the reality of what's being simulated for a moment, and then look at the game system breaking it down to Process Response and the key features thereof. Than compare that result to reality. Is the system at any point basically lying about how something happened? It can leave stuff out, it can simplify and still meet a Simualtion of Process standard- but it can't lie and do so.

BTW, A system can succeed at Simulation of Outcome, and fail at Simulation of Process.


Clearer?

Very few people will ever completely agree on Simulation of Process.

It's nifty that you found a value on how you determine whether a game meets your criteria, but that is all it ever will be, your system.

OK this is more complicated than I'd thought Excellent.

I get the distinction I think - that in the black box you can't see any of the steps, whereas in the failed simulation of process the steps themselves are wrong.

I can see possible similarities in that for say D&D there are assumed to be abstractions that are a bit like how the 'box' is an abstraction but that cover only some of the steps, rather than all of them. (the problem with the D&D approach being that the abstractions sometimes hold to a point - assuming that a skilled character gets a cut on the arm rather than being run through - and sometimes don't i.e. when they try to get that healed) ?

The 'black box' has its own problems of course - in the coin-flip deathmatch we don't know how long the fight takes, there's no chance of a draw, and we can't determine if weapons are broken or the victor has any damage. But yes I can see that they're different things now...

Quote from: Sommerjon;642365Very few people will ever completely agree on Simulation of Process.

Why wouldn't they agree?

Quote from: Sommerjon;642365It's nifty that you found a value on how you determine whether a game meets your criteria, but that is all it ever will be, your system.

I don't believe this is subjective at all.  My terminology for the distinction is Representational Mechanics vs. Non-Representational Mechanics.  This is distinct from the issue of disassociated mechanics

The combat mechanics in D&D simulate specific elements of combat using non-representational mechanics.  That is, the mechanics take certain inputs (combatant skill level, armor, weapon, etc.) and produce an final outcome that simulates the effect those inputs have on who wins or loses but does so in a way that doesn't reflect or represent how those inputs really influence the outcome.  So long as you have two combatants slugging it out in a fairly straightforward way, the ultimate outcomes will be what you might expect (the more experienced combatant will win more often) but their non-representational nature creates collateral problems outside of that specific situation, when the interaction between the inputs and intermediate mechanics leave the narrow range of where they work and even within that range, the terminology is muddled and confuses people because they don't represent what's happening in the game (e.g., "hits" and "hit points" that don't represent actual physical damage, "damage" rolls that don't represent actual physical damage, "healing" spells that don't actually heal physical damage, etc.).  

This is why hit points and AC have been the most complained about elements of D&D since the very beginning and why most other game systems not deliberately aping D&D (i.e., trying to simulate D&D rather than reality) handle damage and armor differently.  I understand the apologies and excuses that people make for them but the abstraction is a mess that perpetually creates all sorts of problems for anyone trying to use them outside of the box, which happens even using them for the normal type of situation they were designed to be used in.

Examples of the problems caused by the non-representational nature of HP and AC in D&D abound.  For example, how does one factor armor into the damage a person takes from falling into a pit full of spikes and why do they have more defense against those spikes (in the form of a higher number of hit points), since AC is used to determine an all-or-nothing damage roll in combat and the increased hit points are supposed to represent combat experience to avoid being hit?  D&D 3.5 has three different AC numbers -- regular AC, flat-footed AC, and touch AC to split out the protective vs. dodging elements of AC in cases where they wouldn't logically apply.  Why does an experienced fighter with more HP require more more healing to heal damage that isn't physical damage and represents a smaller loss, as a percentage of his HP, than a low level companion?  

The excuses for what HP and AC "simulate" just doesn't hold up outside of who people whacking each other with weapons in an abstract battle space until one falls down.

If D&D had mechanics that simulated process, AC would be Defense and *that* would increase as characters increased in level (Character Classes are the third big mechanical problem that draws a lot of complaints in D&D, but it's a different problem not necessarily related to Simulation of Process), making them harder to hit.  Armor would subtract from damage, as it does in just about every other game that's not drying to ape D&D.  Hit Points would be a fixed number influenced by the characters physique.  The odds related to hitting and doing damage would, of course, also have to be changed from the D&D default but that's the general gist of how to Simulate the Process of the sort of combat found in D&D.  

Why would someone want to do that?  Because then those elements work even when removed from the narrow realm of combat because they work the way they really work.  Armor can subtract from the damage inflicted by falling into a pit of spikes the same way it defends against a sword blow.  Since experience characters have about the same number of hit points as a novice, healing any actual damage they take will be about the same.  Touching someone in combat will be determined by their Defense and their defense can be reduced predictably if the character is surprised or even unconscious, leaving armor to provide passive defense, if necessary.

Seriously, none of that is subjective and none of it should be controversial, and attempts to justify those quirks as any sort of simulation ring about as true as a Trekkie trying to rationalize away inconsistencies in Star Trek's canon that are clearly the side-effect of bad writing, not some intentional feature of the setting.

Yes, you can argue that those problems are worth it because it allows for faster combat than a simulation of process.  While I'm skeptical of that excuse, all that's really saying is that people think the trade-off is worth it, not that the problems don't exist.  And, yes, you can patch your way around those problems with things like 3 different AC numbers, saving throws, special instant kill rules, etc., but that just makes things more complicated.

Why does any of this matter?  Because rules that don't simulate process break when used outside of the narrow context they were designed to do and the effort required to fudge and patch around that problem is greater than simply designing more robust and representative rules in the first place.  It's neither robust nor efficient and judging by the nearly perpetual complaints about HP and AC that have followed D&D, it's also not a whole lot of fun for a lot of people.

As food for thought, I'll leave this point with the article Keeping It Simple: Efficiency in Game Design by James Ernest of Cheapass Games, which I think illustrates the problem really well.

And that, I think, ultimately leads us back to Brian's problem which is that since the early days of the hobby, it seems that very few game designers are actually designing robust rules that actually work as intended without serious fudging and patching.  I saw this on the old Fudge mailing list, where people would complain about things like the death spiral caused by the default damage rules (that apply negative modifiers for wounded characters) yet never thought to drop them or modify them (my solution -- apply them only after a significant break in combat, which can even be justified as simulation).

In the other thread, people asked Brian about whether his solution involved putting the PCs up against weaker foes.  Any game that applies the same rules to PC and NPC and treats them the same must do so unless the goal of the game is to avoid combat or tolerate a lot of PC deaths, and even D&D has long assumed that most of the opponents that the PCs fight will be roughly 25% as powerful as the PC.  Video games do the same thing.  Simple odds make it clear that if the PCs are pitted against enemies that are exactly as powerful and competent as they are, then the PCs should be losing about 50% of their battles, yet I don't think anyone runs their games that way in practice.  So one of two things happens.  Either the PCs get mostly pitted against weaker enemies (with the occasionally large climactic battle against an enemy roughly as powerful as the PCs -- a "boss" in video game terminology), the PCs get to play by different rules than the NPCs (which may be as simple as a script immunity point mechanic), or the GM does a lot of fudging to support the delusion that the PCs are fighting battles they have a 50% chance of losing but they don't actually lose 50% of the time.

The alternative of representational mechanics that simulate process works.  Make it very hard for mooks to hit experienced heroes.  Hero does it.  Brian's game (I have a copy and have read or skimmed much of it -- I think it's well written and has very thorough design notes) does it.  I'm sure other games do it.  I've even done it with Fudge.  

My group ran a D&D-like fantasy game using Fudge without escalating hit points and it worked just fine as expected.  It worked (with minimal fuding and almost no use of fudge points) because it produced the sort of results tat we expected and wanted.  The simultaneous combat system we were using and the way rolls and roll comparisons work meant that a character even one level better than another had a significantly better chance of winning and several levels made it very unlikely that the lower-leveled character would do any damage.  

To make this work, you need a bell curve, multiple rolls, or a percentile system that can handle 1% or even sub-1% odds such that the odds of a mook taking down an experience PC are vey low.  That means that, no, it doesn't work that well if you are rolling a d20 and a 5% chance is the smallest percentage you can get above 0%.  This was why Lee Valentine referred to d20 rolls and the d20 system as having "whimsy" (Lee, like Brian, actually worked through the odds with the goal of producing plausible results) and this was the sort of thing that fed tons of material to the old Murphy's Rules comic in The Space Gamer.

Reality, and any system that seeks to produce realistic results (even with fantastic elements) needs to be able to produce very low or very high odds.  Consider that landing a fighter jet on an aircraft carrier may be the most difficult landing any pilot will ever need to master, yet the US Navy does not lose 5% of the fighters each time they attempt a carrier landing and loses well below 1%.  Brain surgeons don't lose 5% of their patients unless they are suffering from trauma that makes their survival suspect in the first place.  Trained Trapeze artists don't fail 5% of their acrobatics.  And so on.  

I know this runs counter to conventional wisdom on role-playing message boards that making rules that are almost certain to succeed or fail is a waste of time, but I don't think that's true.  Most of the drama in real life happens in those narrow odds ranges, be it the high school basketball player who wins the game by wildly hurling the ball down the court and into the basket or professional race car driver that gets into an accident and wrecks his car.  Removing that from role-playing games and replacing it with whimsy produces a whimsy result, where players react to inevitable failures or random successes that they can neither plan for nor control.  Add on top of that GMs who require lots of rolls without understanding the impact they'll have on the results and you wind up with games carried along more by GM fiat than having the rules work as desired.

And I think one of the reasons why people react so badly to Brian's admittedly strict set of criteria for a good system is that people are so used to bad systems, they find it difficult to imagine being able to follow the rules and be happy with the results.  The problem is not that Brian's ideals are utterly unachievable but that people are so used to playing crappy and mathematically unsound systems that they believe fudging results and making excuses for the rules is necessary, when it really isn't if more people would simply determine the results they want their system to produce and they design the system to produce those results.

Quote from: Bloody Stupid Johnson;642378I get the distinction I think - that in the black box you can't see any of the steps, whereas in the failed simulation of process the steps themselves are wrong.

Unless the mechanics and relationship between the inputs is truly opaque to the players and GM, and I'm skeptical of that being the case for any tabletop RPG (but possible for computer games).  In order to process the various inputs that go into a result through the mechanics, the player or GM is going to have to be exposed to the mechanics used to convert those inputs into a result.  I can't imagine resolving combat without knowing how weapon choice, armor, skill level, and so on mathematically influenced the result, and that will either be a representative simulation of process, or it won't.

The only possible way it can work without a computer is illustrated by the coin toss example, which is to eliminate the inputs entirely so that they play no role in the result (which is what some very rules-light games do) or by bypassing mechanics entirely in favor of subjective judgment by the players.

More generally, could a "black box" be a computer program which does all the calculations?

Good to see you about, Mr Morrow.

On the black boxes: I'm not quite sure that a black box would have to ignore inputs, strictly. In the coin-toss example there's a 50/50 fail rate, but its there as an extreme example...if we did add adjustments...say making it a d20 roll and adding +2 for Warrior A having a +2 sword...wouldn't that still be a black box? We still don't have any details of what's going on specifically in the combat then, but have adjusted the inputs and then the odds.

I may be mistaken, but if that's the case then almost any simple roll in an RPG such as a skill check could be viewed as a black box, which could be replaced with something more complex; e.g. forging a sword is just a Craft (Weaponsmithing) roll, but you could replace it with a detailed process where you roll for available iron quality, check to see how long you pumped the bellows, make a Strength check to hammer the steel, then a d% roll to see if the blade breaks in quenching (or something like that anyway, I'm not a weaponsmith).

On simulation of process: thanks, the cheapass game link is good. Efficiency or elegance is something I think rules should strive for, your post above and that give a good description of how good process design aids with that.

Quote from: John Morrow;642385I can't imagine resolving combat without knowing how weapon choice, armor, skill level, and so on mathematically influenced the result, and that will either be a representative simulation of process, or it won't.

Thanks for stopping by John, and great post. I couple of nits...

The example above has a common expression in RPGs- the dice pool and relate mechanics. Imagine that a single dice pool roll is used to determine final outcome.

The inputs are whatever caused the test and the number of dice to be used (and their sources), the block box is both the undiscovered math as well was the simulated process (and the details of the process) the method has concealed, and the output is the result.

Why did I say "undiscovered math'? Yes it is *possible* to determine the effect of the inputs using math, but it's often beyond the ability of the common player and takes enough effort that even those rather good at math don't take the effort. The final result from the common player point of view is more dice equal better but nothing else.

But really what I was using the term Black Box for wasn't the game mechanic itselt, but the process of what it was representing. The very abstraction used is intended to conceal that.

...oh the other nit.

I still think Age of Heroes is poorly written. I had reason to review section 12.2 today and it is twisted in knots, had to rewrite a whole page worth to make it more understandable.

Quote from: John Morrow;642384Why wouldn't they agree?



<...snip...>

 The problem is not that Brian's ideals are utterly unachievable but that people are so used to playing crappy and mathematically unsound systems that they believe fudging results and making excuses for the rules is necessary, when it really isn't if more people would simply determine the results they want their system to produce and they design the system to produce those results.

Makes absolute sense to me.
My heartbreaker has defense that increases with level and AC that absorbs damage.
It does have HP as an ablative scrapes and bruises mechanic but they increase 1 HP per level (for a warrior less for everyone else) and there is an underlying wound mechanic.

I play I have found a couple of issues. Where I found the warriors defense got very good very fast but the cost is reduced armour and less HP so ...

In any case I also agree with the skill issue. A skill of a certain level can routinely complete tasks of that level of difficulty, its only when you apply pressure that failures on routine tasks start to occur.
I think I highlighted once how the skill of tennis players is very close but the number 1 seed will beat the number 20 seed 9 times out of 10 (or more). So the best sort of skill check woudl be one where the static score was much larger than the random score. So tennis skill was rated 1-100 and when you had a match you take your skill and add 1d10 to get your performance. So top seed at 99 skill versus excellent tennis player at 94 skill will beat him 85% of the time. where as most skill systems make the skill 50% of the result (typicall skill 1-10 + 1d10 for example)

I'm curious - would you classify D&D style turn based initiative (where each PC gets to take an action in order) to be a Simulation of Process failure in combat, given the way it produces "I attack you and then you attack me" actions? I ask just because its an approach I find myself increasingly uncomfortable with, but all the games I've played in recent years have used the thing. My main annoyance with it is the fact that it creates a system where each combat round is not six seconds long (or whatever) as advertised, but is in fact six times the number of combatants long.

I actually think the old AD&D 2e system of "declare actions and then act in speed order" was far superior, really.

While musing on this thread earlier today as I was walking the dog I made reasonable progress on a hack of Savage Worlds to use simultaneous melee combat, but I suspect in the end it would break too many of the Edges to be a viable option.

Quote from: Grymbok;642650I'm curious - would you classify D&D style turn based initiative (where each PC gets to take an action in order) to be a Simulation of Process failure in combat, given the way it produces "I attack you and then you attack me" actions?

Excellent question, and not a easy one.

A related one is a character's location on the map and their facing.

Both are without a doubt simplifications and abstractions, a snap shot representing a moment somewhere in the turn's time scale where that reality exists, but we don't know which exact moment it was.

This is true even of a simultaneous turn sequence btw for it ignores (at least to some degree) the ability of someone to react to committed actions of others while in mid-action themselves.

But is it a failure in Simulation of Process?

I'd say no, for cause and effect remain intact, only the order of  events is brought into question. Phrased in a different way, the events of the process remain consistent, but their place in the round's time scale has been concealed by the abstraction.

This is complex to wrap one's head around.

Time for an example:

In Age of Heroes and its turn sequence we know that Character A gets to attack first, and if he fails character B gets to attack next. Let's say A misses, and B takes off A's head in reply.

The cause and effect is clear, for *some* reason A failed and for *some* reason B killed him.

The abstraction of the dice prevent us from knowing the actual causes for the reasons above. The abstraction of the turn sequence prevents us from knowing the actual order.

So it's very possible that in truth, B went first and killed A before he even got his swing going. Or maybe A did swing and miss, and while recoving from the swing B then killed him. Maybe A dropped his weapon, bent over and lost his head to B. We flatly don't know.

And not knowing, we can't tell if the system lied. Thus we can't know if it failed Simulation of Process, hence we assume it did not.


Now can I defend that viewpoint?

I honestly don't know. I think it's possible to make the case that due to limits of scale and complexity that all systems are failures with respect to Simulation of Process. That the only difference is if the failures come in small slices (like the turn sequence) or large ones (like the entire combat).

So you've made me ponder this more.

Quote from: Grymbok;642650I'm curious - would you classify D&D style turn based initiative...

Alright, I've ponder this some more.

And I'm going with my second option. It's not enough to be unable to prove that the system lied, it's enough to know that it may well have. Thus I'd have to label that style of initiative as a failure of Simulation of Process.

Quote from: gleichman;642680Alright, I've ponder this some more.

And I'm going with my second option. It's not enough to be unable to prove that the system lied, it's enough to know that it may well have. Thus I'd have to label that style of initiative as a failure of Simulation of Process.

I am liking this thread.

You mention position in relation to time having a similar "snapshot" nature to the turns in a given round. Would you say there are (either necessary or common) failures of process simulation in turn-based representations of maneuvers on a map?

Example: There's a system without AoOs, ZoCs, or similar. Person A moves past person B. They begin and end their movement out of melee range, but A passes through an area B could hit. However, B can't hit A on his turn, because A is now out of range.

Or, more simply, it may be weird to operate on the assumption that a person faces the same direction for x seconds in combat.

I may have phrased my question badly or misunderstood your intent, so feel free to ask or correct before addressing the question.

Quote from: beejazz;642687You mention position in relation to time having a similar "snapshot" nature to the turns in a given round. Would you say there are (either necessary or common) failures of process simulation in turn-based representations of maneuvers on a map?

It's sort at the same level as the turn sequence problem. The mechanics if taken completely at their word say you've locked your facing in one direction when that isn't really the truth.

This is something of a white lie, a simplification that by itself doesn't cause much if any harm to the total Simulation of Process. The lack of harm is why I overlooked it until pointed in its direction by Grymbok.

Quote from: beejazz;642687Example: There's a system without AoOs, ZoCs, or similar.

This on the other hand causes greater harm, the reason for such mechanics is to deal with the weakness of the original Map and Turn Sequence Abstractions. If they're removed and not replaced what was a small harm becomes a major one.

Stated an another way, the Turn Sequence and Map may place things out sequence or direction- but the lack of AoOs and ZoC removes events along with their causes and effects (and still places things out of sequence and direction).


I think the minor breaks with Simulation of Process are almost unavoidable on the table top.

As I understand it: Initiative systems vary between very exact, blow by blow, modelling and being more abstract, with the combat really being a number of blows, and the 'initiative roll' then being a roll for a possible important blow, rather than for one sword swing (theoretically, the D&D approach).
So...I had trouble following the example for awhile since I had never literally considered 'turn order' to be an abstraction, exactly, so much as its a 'simulated'  moment in time, preceded and followed by a sea of unsimulated time.
Stuff like free attacks for moving through zones of control, or attacks each segment during surprise, would also be moments of simulated time (when another opportunity definitely arises).

That idea does break down a bit when you consider movement of course - stuff like 3E D&D wizards 5' stepping back away from a guy hacking at them, giving them time to cast a spell before he's legally allowed to move next segment.

Quote from: Grymbok;642650I actually think the old AD&D 2e system of "declare actions and then act in speed order" was far superior, really.

The 'declare actions first' part of it is fine. 2E initiative has some inconsistencies in that the round is theoretically a minute long, but with speed factor of weapons slowing an attack to much later in the round - which would be much more consistent with a round representing a single blow.

Quote from: gleichman;642665In Age of Heroes and its turn sequence we know that Character A gets to attack first, and if he fails character B gets to attack next. Let's say A misses, and B takes off A's head in reply.

The cause and effect is clear, for *some* reason A failed and for *some* reason B killed him.

The abstraction of the dice prevent us from knowing the actual causes for the reasons above. The abstraction of the turn sequence prevents us from knowing the actual order.

So it's very possible that in truth, B went first and killed A before he even got his swing going. Or maybe A did swing and miss, and while recovering from the swing B then killed him. Maybe A dropped his weapon, bent over and lost his head to B. We flatly don't know.

One thing that puzzles me - how is the first option (B going first and killing A before he got his swing going) a plausible explanation - wouldn't that be modelled by A winning initiative and hitting, a different set of rolls?