Class Design and Tech Debt

Hello paid subscribers, and welcome to my series of articles on class design in 5e. I'm designing the psion as an example in this series, a character who uses psionic power to achieve amazing feats of... well... we actually can't say for sure yet. Figuring out just what the psion does is part of the process. We do have a vague idea of what a psionic character looks like, but we'll need to sharpen that definition before we can start doing specific game design.

In this installment, I'm going to talk about the nature of 5e character classes. The classes you see are just one path to design. What if there were others?

Tech Debt

While 5e enjoys a huge audience today, like all new games it started with an audience of none and grew from there. When the game was in design, we had to make a number of decisions about how to structure the classes. That structure held up in playtest, but it was bound by a number of design constraints that we don't need to follow (unless we want to).

I think of those constraints as tech debt. Past decisions in building a system might be driven by short deadlines, tight budgets, or compatibility concerns. Class design in 5e suffers from a few constraints that are of dubious utility to contemporary design.

Subclasses

A subclass is one way to allow variation within a class, but it's not the only way. We could create menus with options at every level. Subclasses were designed to make it easy for beginners to make characters. The first few levels have limited or no choices. Your subclass is your biggest choice, both to keep classes simple and to let the design support concepts like cleric domains and the schools of magic. Those elements were critical to the core classes, but we might not need them for new ones.

Multiclassing

This constraint is a huge headache. Multiclassing is to blame for a variety of challenges in class design. Every feature needs to function with every other feature across every class. If a class feature has weird verbiage and strange corner cases that limit its utility, you can blame multiclassing. The game's legacy, specifically 3e, made this feature a clear requirement for 5e, even if it throw a wrench into class design.

I think there are better ways to support multiclassing rather than hobbling every class we design to work with it. We'll explore some of those options as I design this class.

An Alternate Path

Given that both subclasses and multiclassing are optional features, I'm going to focus on only on what makes the psion distinct and which mechanics it needs to stand out. If you liked psionics in 3e or 4e, you can think of one option that stands out immediately: psi points.

What's the Point?!?

Point-based casting systems in 5e are tricky, but I think the psion is worth the lift. Points give us an immediately unique element compared to other classes. They also give us a lot of flexibility in making psionics feel like the heart of the class.

Personally, I like the idea of the psion adjusting their focus, carefully measuring the energy they burn, and acting with more precision than other characters. That fits the flavor of a psion in my mind.

The challenge with points comes down to two elements:

• A points system can become fiddly, especially if characters end up with lots of points.
• A points system can allow a character to use their top tier spells more often than a comparable, slot-based caster. In effect, points allow you to mash lower level spells together to produce higher level effects. Slot-based casters can't do that.

So, how do we get around this? Let's consider a few ground rules:

• I'd like the math to work such that an X-level spell costs X points to cast. That means the total number of points should be a reasonable number that looks more like a character's hit points than the US national debt. It also means we can use existing spells to flesh out our power list.
• I want to limit how often a psion can use their highest level ability. A character who can spam their strongest spell will likely overshadow a slot-based caster regardless of what other design tricks we pull.

If we can hit those two notes, then I think our system can work smoothly with the existing character classes. Despite their tech debt, we need to play well with them.

So, we have a name for our class and a commitment to try some new things with class structure. We want psi points and have some concepts for what we need to do to make them work with the existing classes.

What features or elements do you want the psion to have? Do my goals make sense? Let me know in the comments.