How to Track Character Stats Across a LitRPG Novel (Without Losing Your Mind)
By Rob Chipman
You have a spreadsheet. I know you do.
It started as one tab — character stats. Then you added items. Then gold. Then a cross-reference sheet for who-has-what-equipped. Then a formula column to calculate Kira's effective STR after the Sword of Rage (+5) and the Iron Skin buff (+12) that expires at the end of chapter 19.
Then you added a second character and the whole thing doubled.
I've been talking to LitRPG authors about this for months — on Royal Road, Reddit, Discord. The pain is universal. A recent thread on r/litrpg titled "Non-crunchy author attempting crunchy LitRPG spreadsheet… please send help!" had seventeen replies. Not one person said they had a good system. The answers ranged from "poorly" to "begrudgingly" to "I wrote 200K words before I finally gave in and made one."
Here's what everyone's doing, where each approach breaks, and what I think the fix looks like.
The spreadsheet
This is the default. Excel or Google Sheets, one tab per concern — stats, inventory, gold, skills.
It works. For a while. The problem isn't that spreadsheets are bad at math. The problem is they're snapshots.
Your spreadsheet knows Kira has 1,200 HP right now. It doesn't know she had 847 in chapter 31 and 432 in chapter 38, right after the Wraith ambush. Every time you need to check "wait, what were her stats at this point?" you're cross-referencing cells with chapter notes and praying your last edit didn't break a formula.
One author on Royal Road described it perfectly: the hardest part isn't building the spreadsheet. It's pulling yourself out of the writing long enough to update it. You're in flow, the scene is working, and then you have to stop and go maintain a database.
That context switch is where consistency dies.
The wiki approach
Obsidian, Notion, a Google Doc with internal links. Some authors build elaborate wikis with pages per character, cross-linked inventories, and nested databases.
The wiki is better for prose-style notes — backstory, motivations, relationships. But it has the same temporal problem as the spreadsheet: it only knows the current state. And unlike a spreadsheet, it can't do math. When Kira levels up and gains +2 STR, you update the wiki manually and hope you didn't forget.
One author told me he keeps a second fiction on Royal Road — not published, just a private parallel document where each chapter maps to the stat state at that point. A shadow novel of bookkeeping, maintained alongside the real one.
That's dedication. It's also a sign that the tools are failing.
The "be vague" strategy
Some experienced authors solve the problem by avoiding it entirely. Don't specify exact gold counts — say "a handful of coins." Don't track XP to the integer — use milestone leveling and skip the math.
This is genuinely good advice for many writers. If your story doesn't hinge on precise numbers, being vague saves you from tracking errors that readers will absolutely catch.
But it doesn't work for everyone. Some authors want the crunch. Some readers want the crunch. The comment on Royal Road you're trying to prevent — "um actually she couldn't have used Void Step there, she burned her mana two chapters ago" — that reader is doing the math whether you are or not.
If precision is part of your story's appeal, you can't hand-wave the numbers. You need to track them. The question is how.
The custom tool approach
I've seen authors build HTML trackers, Python scripts, Obsidian plugins with version control. One author on Royal Road built a GUI stat tracker that doubles as a visual character sheet for readers.
These solutions are creative and often impressive. They're also one-off — built for a specific system, by a specific author, for a specific novel. When you start book two with a different stat structure, you're rebuilding from scratch.
What actually works: events, not snapshots
After talking to dozens of authors and hitting these walls myself, I think the core problem is architectural. Every approach above tries to maintain a current state — "here's where things are right now." And maintaining current state manually, across hundreds of chapters, is a losing game.
The alternative is to think in events, not snapshots.
Instead of updating a spreadsheet cell when Kira levels up, you log the event: "Chapter 23: Kira gains 500 XP from defeating the Stone Golem." Instead of manually recalculating her stats, you let the math flow from the event history. Her stats at any point in the story are just the sum of everything that's happened to her up to that point.
This means you can answer "what was Kira's HP in chapter 31?" without maintaining a separate sheet per chapter. You can change an event in chapter 12 — she found a slightly better sword — and everything downstream recalculates. You never maintain a running total. The total is always derived.
If that sounds like event sourcing from distributed systems — it is. It's the same pattern banks use to track account balances. Instead of storing "Kira has 1,200 HP" and updating it, you store every transaction and compute the balance on demand.
What I'm building around this idea
This is the core of AxiomWeaver — a desktop writing tool I've been building specifically for LitRPG, Progression Fantasy, and GameLit authors.
The event ledger records every change to your world as it happens in the narrative. "Kira takes 340 damage" becomes a structured event that updates her character sheet automatically. Hover any stat and see the full breakdown — base value, equipment bonuses, buffs, level-ups. Every source, every modifier.
The scene scrubber lets you move to any point in your manuscript and see the projected state of every character at that moment. No cross-referencing. No shadow documents. The engine knows what chapter it is.
It's in active development right now, with a free alpha coming soon. If the spreadsheet problem resonates, sign up to get notified when it's ready. Or join the Discord and tell me how you're currently tracking things. Every conversation shapes what gets built.
Your spreadsheet has earned its retirement.