Skill Trees for LitRPG Writers

Your MC just hit Tier 4 of the Manashaping track in chapter 174. Do they unlock the skills they should have? Did the Mana Weave ability fire? Is the +5 INT stacking right with the Sword of Focus buff they picked up at chapter 89?

If the answer is in a spreadsheet on your second monitor, you've already lost the thread. Your readers will catch it first.

This is the tax of LitRPG. Your world has rules — tiers, prerequisites, stat thresholds, unlock conditions — and those rules have to still be right 200 chapters in. Progression fantasy readers will tolerate some hand-waving. LitRPG readers will not. The whole promise of the genre is that the numbers add up.

Most authors I've talked to are solving this by hand, on graph paper, in spreadsheets, in Obsidian, or in their heads. Most of them eventually lose track. The good ones apologize in author notes. The lucky ones have readers who spreadsheet it for them.

LitRPG writing software — the kind that actually respects the crunch instead of treating it as decoration — has to do one thing the generic writing tools can't: treat skill trees as a first-class artifact.

The LitRPG spreadsheet problem

I surveyed 67 Royal Road authors about their tooling. The most common answer for tracking progression systems was "spreadsheet." The second-most was "my head." These are the same answer — just one has longer battery life.

The issue isn't that spreadsheets are bad. They're fine for chapter 1. They fail somewhere between chapter 30 and chapter 100, when:

• The MC gets a new skill and you forget to update the cell that tracks skill count for a downstream trigger
• A faction granted a buff in chapter 12 that's supposed to expire at chapter 60, but the expiration logic lives in your head
• A relic the MC grabbed at chapter 45 modifies a stat, but the stat formula changed in chapter 78, and retroactive math is now inconsistent
• You introduce a new stat in chapter 120 (authors do this constantly) and half your prior chapters need retconning to stay consistent

By the time you notice, the spreadsheet is three tabs deep and you're afraid to touch it because you're not sure which cell is load-bearing.

What a skill tree actually is

Strip away the terminology. A skill tree in a LitRPG progression system is a directed graph of:

• Nodes — the skills, abilities, or stat grants available
• Edges — the prerequisite relationships (Mana Sense before Manashape; Tier 2 of the track before any Tier 3 ability)
• Unlock conditions — the triggers that gate a node (level thresholds, event counts, prerequisite completion, item possession)
• Rewards — what the node actually grants (a new skill, a stat modifier, a whole property group)

That graph is the spec for your progression system. Every time your MC levels up, you're walking that graph. Every time a reader spots an inconsistency, they've detected a divergence between the graph in your head and the graph on the page.

Take Kyle Kirrin's Ripple System — one of the most explicit class-and-stat LitRPGs in the genre. The ripple mechanic, the class unlocks, the level thresholds: none of it is hand-waved. You can read a system message in that book and reverse-engineer the rules. That's the bar. That's what "the math adds up" looks like to a LitRPG reader. You don't need a system that rigorous for every book, but you do need one that's explicit enough to survive scrutiny.

Tiers, triggers, and the math that has to add up

When you make a progression system explicit, three things happen.

Tiers become gates, not suggestions. If Tier 4 of the Manashaping track requires 50 successful spellcasts and possession of the Focus Talisman, your character can't reach Tier 4 without both. A tool that understands progression tracks will refuse to let you retcon the Tier 4 unlock if the prerequisites aren't met. A spreadsheet will let you type the number anyway and you'll find out in the comments.

Triggered progression becomes visible. When your MC crosses a threshold — 50 sword attacks, 1,000 mana spent, fighting their first Nightmare — the system can surface the moment: "Character hit the Swordsmith: Novice progression trigger. Want to grant the Blade Sense skill?" You still make the decision. The system just makes sure you see the moment instead of writing past it.

Property groups scale with tiers. Reaching Tier 4 of Manashaping can unlock the Arcane Resonance property group — Mana Pool, Spell Power, three associated skills, all applied automatically. You design the group once; every character who reaches that tier inherits it. No copy-paste into each character sheet. No "wait, did I update Kira's stats when she tiered up?" Yes, you did, because the system did it.

None of this is a new idea. Video games have been doing it for forty years. What's new is building it for the writing side instead of the playing side — so authors can design with the rigor of a game designer without needing a game engine.

Designing before writing vs. designing as you go

Two kinds of authors show up in my research.

Architects design the progression system before chapter 1. They sketch the tiers, define the unlock conditions, draw the skill trees, then start writing. When they reach Tier 4 at chapter 174, they already know what's waiting there.

Discovery writers discover the system as they go. Chapter 12 introduces Manashaping. Chapter 47 reveals it has tiers. Chapter 89 retcons the tier requirements because they thought of something better. By chapter 150, the system has evolved three times.

Neither approach is wrong. LitRPG is a genre that rewards upfront architecture — the promise of the genre is that the crunch is consistent. But architects write rigid books sometimes, and discovery writers get the best emergent systems. Most serious LitRPG authors sit in the middle.

The tooling problem is that spreadsheets serve architects poorly and discovery writers worse. An architect wants to design a full skill tree and validate it before writing. A discovery writer wants to extend the tree as ideas surface and have prior chapters stay consistent under the new rules. Both need structured editing that knows what changed.

Why spreadsheets keep failing this

Spreadsheets are 2D. Skill trees are graphs. You can encode a graph in a spreadsheet, the same way you can encode a novel in JSON — technically possible, practically miserable. The edge cases pile up: prerequisite chains you can't visualize, tier thresholds you can't auto-enforce, grants you can't retroactively apply.

What skill tree tooling has to actually do:

• Let you draw the graph directly — nodes, edges, prerequisites
• Enforce unlock conditions — can't reach Tier 4 without Tiers 1–3
• Grant property groups at thresholds — tier unlock = bundle of stats and skills, applied automatically
• Surface triggered progression — character hits a threshold? Prompt the author
• Validate retroactively — change a tier requirement, catch every character who would no longer qualify

AxiomWeaver's tier generator does this math for you. Define the formula once — polynomial scaling, however many levels, whatever reward per tier — and the system generates the full threshold table. Tiers can grant individual skills or whole property groups. When a character hits a trigger in the prose, the event ledger flags it. Edit the formula at chapter 89? The system re-validates every affected character. It's the tool you'd build if you actually wanted to write a 200-chapter LitRPG and have the math still work at the end.

One practical note

You don't need a tool to build a 200-chapter consistent progression system. Plenty of authors do it with discipline and spreadsheets. But the tax is real — and the first time you notice a reader on Royal Road pointing out a chapter 12 inconsistency you should have caught, you'll wonder what it would cost to just have the tool do the tracking.

AxiomWeaver's alpha ships soon. If you're writing LitRPG and the spreadsheet is getting away from you, join the waitlist and I'll send you the download when it's ready. Or come talk shop in Discord — there's a good conversation happening about how to design systems that survive long serials without breaking.