Leveling & Advancement
A character's growth lives in one field — level — and every other scaling number is derived from it rather than stored separately. That single choice drives how you build, test, and extend this system.
The design intent
The Character schema deliberately keeps level as a plain 1–20 integer and pushes everything else into computed fields:
- Proficiency bonus =
1 + ceil(level / 4).
- Max hit points, spell slots, caster level, pact slots, and which class/subclass features render all derive from class + level.
- The character creation flow treats level as the master input ("every later rule that says at the chosen level uses this value").
This is the core convention of the pack: you store the inputs, the sheet computes the outputs. If you keep to it, leveling up a character is always "edit level, re-save, apply the hand-written choices" — there is no chain of dependent numbers to maintain by hand.
What "advancement" means to a builder
The Level Advancement glossary entry splits a level-up into two kinds of change. Keep that split crisp when you extend things:
- Derived values — recompute automatically from
level (and class), so nothing about them lives in the data file. Never add a stored proficiencyBonus, spellSlots, or stored-per-level feature block to a character; that reintroduces the drift the schema eliminates.
- Player choices — ASI bumps (which land in the
base* ability scores and as a feat), new prepared spells/cantrips, Fighting Style and Epic Boon feats, subclass at 3rd. These are editable fields because they are decisions, not arithmetic.
The three docs work together: the Player's Handbook chapter tells a player what to do on their sheet; this Manual tells a builder which side of the split a new field must fall on.
XP vs. milestone — and the experience field
Advancement uses either XP (SRD 5e 2024 cumulative thresholds) or milestones. The experience field is deliberately optional plumbing: it exists so an XP table can track a running total, but no computed field depends on it, so milestone tables can ignore it without anything breaking.
When you clone or adapt the system, note that the threshold table in the glossary is the only thing that binds XP totals to levels. If you want a gentler or steeper curve, or a homebrew milestone cadence, that table is the single point to change — nothing else reads the numbers.
Extending it cleanly
- A new field that scales with level? Make it computed off
level (and, for class data, off the class reference) rather than storing a value the GM must update on every level-up.
- A new level-gated class or subclass feature? Add it as a
featuresLevelX string on the class/subclass file and reference it with a computed field on the character. It then reveals automatically as level rises, with no per-character bookkeeping.
- A new XP scheme? Edit the threshold table and the glossary description together. Keep the XP table referenced from
experience's field description so the promise and the mechanism stay in sync.
The rule for everything: if it is arithmetic, compute it; if it is a choice, let the player record it. That is what makes leveling survivable across a whole campaign.
