Reply to thread

Message: <blockquote data-quote="GSHamster" data-source="post: 6179357" data-attributes="member: 20187">The current design of classes and subclasses in D&D Next is very similar to some concepts in computer science. This is a look at that design using the terminology of computer science. As well, I hope to show that--if the analogy holds--this current design will have issues later on.Goal of SubclassesWhat WotC is aiming for with this design is the concept of polymorphism. Polymorphism is the ability for data of one type to be substituted for data of another type safely. Essentially, if a rule calls for a character of type Mage, you can give the rule a character of type Wizard, or type Warlock, or type Sorceror, and the rule will still work.The advantage of polymorphism is that it allows future products to work together, even though they don't know about each other. For example, let's say class Fighter is defined in the Player's Handbook. A year later, Supplement A comes out with subclass Knight, and Supplement B comes out with a combat stunt system for Fighters. Thanks to polymorphism, if things are done correctly, Knights will be able to use the stunt system without issues, even if the two Supplements don't know about each other. Instead, they interact with each other through the definition of Fighter.ImplementationThe mechanism WotC is using is called inheritance. Some mechanics are defined in the base class, and the subclass "inherits" those mechanics. For example, let's say Sneak Attack is defined in the base Rogue class as "deal 1d6 extra damage if you are flanking". All Rogue subclasses will gain that ability by default. The subclasses can change Sneak Attack, but there is a default mechanic in place.Subclasses can add new abilities, but rules that reference the Rogue cannot reference those new abilities, because those abilities are not part of the Rogue.IssuesInheritance is not the only mechanism that can be used to implement polymorphism. A second method is called interface composition. In this method, the top classes (called interfaces) are purely descriptive. All mechanics are contained within the subclass. For example, the Rogue interface would have an ability called Sneak Attack. However, each subclass would have to define Sneak Attack individually. They may all define it the same way, or some may change the ability up.Now, it may seem like interface composition is less powerful than inheritance. But interface composition has some subtle advantages. First, sometimes mechanics can conflict, or rules that rely on the default implementation cease to work with a subclass that changes it up. For example, let's say the default Sneak Attack works in melee combat. Then an Archer subclass comes out that redefines Sneak Attack to work at range. If a third book comes out which assumes Sneak Attack is in melee, it can conflict with the Archer variant. These sort of small conflicts and assumptions end up being fairly common if the inheritance hierarchy gets very big. A purely descriptive interface tends to avoid these issues because all you have to rely on is the description and not the default implementation.The second advantage is that it is a lot easier to make a subclass that can substitute for multiple classes. For example, let's say you want to make an Arcane Trickster, a mage/rogue hybrid. What base class do you start with? If it's a Mage, then rules that reference Rogues don't work. And vice versa. Mechanics like Base Attack Bonus can conflict, because both Mage and Rogue define the same mechanic differently.Whereas in interface composition it would look something like this:Mage - casts Arcane spellsRogue - has Sneak AttackArcane Trickster is both Mage and Rogue - defines its own BAB progression - casts Arcane spells - has Sneak AttackIt can easily substitute for both classes, and will work correctly with rules that reference Mages or Rogues.The software development world is moving to the view that interface composition has more advantages than inheritance. It is considered to be more flexible. Each subclass is fully defined on its own, and does not reference back to a base class. In fact, Google's latest language, Go, does not have inheritance at all, relying fully on interface composition to provide polymorphism.ConclusionIt should be noted that in my day job as a software developer, I am in the interface composition camp. I used to be a proponent of inheritance, but in practice inheritance has ended up causing me more headaches than it solved.In my opinion, the same issues that plague inheritance in object-oriented programming will end up affecting class design in D&D Next. The base class mechanics will prove to be too rigid, and the promise of polymorphism will prove to be harder to achieve as more and more rules come out that rely on the base assumptions of the default class.I expect that it will take an edition's worth of subclasses to fully see the issues. Perhaps in 6E we will be ready to move to purely descriptive base classes without mechanics.A Note on PsionistsIn my opinion, the issue with Psionists and Mages can be very clearly seen in a purely descriptive system. A description of Mage might be something like:Mage - casts arcane spells - can wear robes - has a familiarA Psionist is going to violate that very first line in the description. Therefore a Psionist cannot be a Mage.Where WotC is going wrong is that they want the Psionist to use some of mechanics defined in the base Mage class, and to be treated like a Mage by future rules. But in a system where there are no mechanics defined in the base Mage class, this is more obviously wrong.Or the fix, that psionics is now a type of arcane magic, must be stated more bluntly.</blockquote>

Verification