Reply to thread

Message: <blockquote data-quote="EzekielRaiden" data-source="post: 9502516" data-attributes="member: 6790260">To be "ad hoc" is to be without any structure, system, or consistency--it is things invented purely on the fly, usually makeshift solutions, "patches", etc. It may not be a generically bad word, but when used to refer to a designed system, I certainly think it is a criticism, not a neutral statement.Exception-based design works by setting a clear baseline, a system, and then only deviating from it when you need to, because no system is perfect. "Ad hoc" design is where you do whatever, without any system in the first place.Where is the tree structure oriented?When I say "top-down," I mean that 3e-like design wants everything to have a clear box, and no box should ever conflict with the category of boxes it's alongside, and no category should conflict with the other categories in its class, etc. To invent an example, without strict reference to actual 3.x rules, anything and everything that is a "creature" must have all the traits that every "creature" has. If you want something that is like a creature, but doesn't have all the same traits, it needs to be a completely distinct category in order to be valid. Any time you want to deviate, you must either invent a whole new category, possibly several layers up the tree. Hence my example of "undead" vs "deathless" before, or inventing whole new classes for the rather paltry reason of "stat swap and some ACFs".Bottom-up is the opposite. "Creature" is considered a starting point, not a classification. You build upon what "creature" means--possibly changing some things along the way--rather than being confined only to what "creature" means. Metaphorically, you can build up and out, without having to stay only above foundation blocks.See, this is where we differ. There is a system. The system is just not absolutely, 100% determinative. The rules recognize that no system ever can be perfectly determinative--you cannot have discrete, individual rules for every possible case. Hence, there is a default expectation, which can be relied upon in general, but which will not bar you from doing things differently if different is actually required. One emphatically should not deviate willy-nilly, but nor should one fear deviation either. The former would in fact be the anti-systematic, meaningless "do whatever" approach you described, while the latter would lock the system from ever adapting, adjusting, or responding when something doesn't work.No, it is not. The system is a baseline, but the content-creator (designer, DM, homebrewer, whatever) is expected to evaluate that system as it operates. That's where the relation lies: "I can see that these rules are too limiting, incapable of effectively achieving reasonable ends. Adjustment is required." That's not "ad hoc." It is the simple recognition that perfect systems don't exist, and thus systematic approaches to alteration are required.Alright. I don't think we have much to discuss on that front then. I think D&D has somewhere between 18 and 25 fundamental class concepts; anything more than 25 (and this is a specific list, not just any 25) and you're making too fine a point, splitting frog hair four ways. But there are clearly multiple archetypes missing from the 13 that 5e offers, archetypes that other related games (both 5e-descended and more widely D&D-descended) have quite successfully articulated. The "leader of warriors" aka "Warlord", the "swordmaster-spellcaster" aka "Swordmage", the "psychic adept" aka "Psion", and the "Dr. Jekyll-alike" aka "Alchemist", are all examples of archetypes poorly handled by the 5e rules. The fact that we got something like six different "weapon attacker but also spellcaster" subclasses should indicate how big a hole that particular one is, for instance. (I also think the Rogue actually makes for a piss-poor Assassin, but that's getting into the weeds.)I'm saying actual exception-based design requires it. Otherwise it isn't exception-based design, because a rule that is broken more often than it is obeyed isn't a rule, and if there is no rule, there can be no exceptions. That's what differentiates "exception-based" from "ad hoc." The former has rules, they just aren't absolutely ironclad; you work within them until you see a clear need to work beyond them, and then you only work beyond them inasmuch as you actually have to.Slavish adherence to existing design rules is obviously bad. So is constant violation thereof, meaning, there is no rule at all. Due deference, tempered by the understanding that some, uncommon/rare, exceptions will occur and should be addressed as such. Exceptions that prove the rules, one might say.</blockquote>

Verification