Reply to thread

Message: <blockquote data-quote="Crazy Jerome" data-source="post: 5457740" data-attributes="member: 54877">It's because most of the conversation in this topic is (quite justly) responding to particular points, but only a holistic (or at least comprehensive) survey of all the factors is going to lead to any real understanding across some of the barriers evident in the dicussion thus far. Problem is, there probably isn't any one person capable of rendering that holistic survey. For example, I know full well that some bit of the disconnect on simulation is disparate preferences, facility, etc. with details versus abstraction. A great many of those "creative ways" with 3.5 is very effectively leveraging those details to avoid unbalancing. I've done a bit of that myself. But when I do, I instinctively start to classify and abstract the problem sets, and then deal with them at that level. Which is all that 4E is really doing here, albeit with extreme prejudice. I know this is what is happening because I work with highly abstract software development, mainly for users and managers that are very detailed people. So I have to deal with bridging this different mindset every day. The symptoms are unmistakable. <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":)" title="Smile    :)"  data-smilie="1"data-shortname=":)" /> But don't mistake me for saying that the preceding paragraph fully explains anything. Some of those "creative ways" have nothing to do with concrete details at all. Some of the people who mainly like the details nontheless highly abstract what they do with the details--they just use radically different abstractions than the 4E design team. Yet different again, some people thrive on details but deal with it via organziation versus abstraction (see Ptolus for the pinnacle of this effort--so well organized that even a guy like me that prefers abstraction can deal with the sheer mass of detail present.) And none of that is even touching the causal-based mechanical simulation versus effects-based simulation preferences (which are often strongly held). Or throw in how the 4E "exception-based" design is a reasonably good idea that nonethless manages to make some critical mistakes in implementation (not uncommon in first tries at such designs). All of those distinctions go a long way towards explaining why I find 4E far more satisfactory for world building, the way I want to do world building. But anyone that would easily understand that is already predisposed to find 4E useful, too. It's tempting to say that 3E has a bunch of "useless details" and 4E has a few "useful" tools. And that's correct on one level, but rather crude and misleading (not to mention unfair) on another. Yet I guarantee that there is at least someone reading this for whom the distinctions raised above might as well be picking out the catering menu for your own wake. Less really, because the distinctions don't even register as hypothetical. That whole discussion is off in some quadrant that doesn't even come up for them. And their focus is probably on some other area that I didn't even mention. <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":)" title="Smile    :)"  data-smilie="1"data-shortname=":)" /></blockquote>

Verification