Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="Manbearcat" data-source="post: 5994389" data-attributes="member: 6696971">@<a href="http://www.enworld.org/forum/members/crazy-jerome.html" target="_blank">Crazy Jerome</a> has done a thorough job of answering your questions (and I'm in agreement with all of his answers) and @<a href="http://www.enworld.org/forum/members/balesir.html" target="_blank">Balesir</a> has done an excellent job with 6.  Therefore my efforts would be superfluous.  However, I think I can (hopefully) lend a hand in trying to clarify "Simulation" and "Process Simulation".Simulation:  The discipline of imitating a macro-system (typically real-world) over time.  This is done by way of developing a model of the system which will represent the key physical interactions and behaviors (* parameters) of the system you are imitating.  In order for the model to bear out fidelity to the system you are attempting to imitate, you must first constrain each of the parameters.  The more unconstrained the parameter (eg higher margin-of-error, high upper and lower bounds, more abstracted), the more latent entropy you load into the model when you run the simulation.  The more latent entropy you load into the model, the greater the chance of realized entropy to to manifest in any one run.  The more realized entropy manifesting in a model run, the greater the chance that the model run will not properly imitate the system, over time, that you are simulating.  Process-Simulation:  The discipline of imitating a micro-system (typically real-world) right now. These micro-phenomena are your * parameters in the Simulation of a macro-system.  The more unconstrained (by way of being abstracted or being unphysical) these parameters are, the worse the Simulation will perform in its effort to model the macro-system over time.I hope that helps.  I also hope that you can maybe understand mine (and others) issues with DnD from both a Simulation and Process-Simulation perspective.  1 - Within DnD's "implied setting", there are numerous "unphysical" mundane interactions that defy fundamental physical laws.  These are not small things and are "in your face" as you attempt to play overarching "Simulation" and as you try to resolve "Process Sim."2 - Embedded in DnD's mechanics, there are an enormous number of abstractions with hugely unconstrained upper and lower bounds.  These are used to micro-"paramaterize" the DnD model which is then used to Simulate the macro-world of "High Fantasy World Married to Well-Understood Physical Laws."  The amount of latent entropy loaded into the model run due to 1 and 2 is quite large.  As you perform "model runs" for the Simulation in your head, the upper and lower bounds are extremely wide.  Within the margin-of-error of multiple model runs you will find "Well Modeled High Fantasy World Married to Well-Understood Physical Laws."  However, the margin-of-error is so large that you could not hope to fairly say "this Simulation reliably reproduces/represents the macro-system we are attempting to imitate."This is if you are trying to Simulate "High Fantasy World Maried to Well-Understood Physical Laws."  If you are trying to Emulate (not simulate) "Heroic Action Adventure Per Cinema" then you can accept Outcome-Based-Simulation to parameterize the overarching macro-system which you are Emulating.  In this effort you are trading precision of model (Emulation rather than Simulation) and accepting Gamist conceits and Narrativist conventions to enhance your ability to capture "Genre Emulation."  When your "playstyle aim" is such, you can forgive "embedded abstractions" and "unphysical elements" and just focus on "being John McClaine (or whomever)" and creating a fun, tactical, strategic, genre-relevant story/game.If you wish, I can contrive a post whereby I define:Emulation:Outcome-Based Simulation:However, I hope the above paragraph is sufficient for you to extrapolate.</blockquote>

Verification