litrpgwriting toolsgame systems

LitRPG Character Sheet: What to Track

By Rob Chipman

Pull up a D&D character sheet. Good for a tabletop session. Mostly useless for a LitRPG novel.

The format isn't the problem. The problem is that a D&D sheet is a snapshot of one moment. A LitRPG character sheet has to hold together across 200,000 words, survive a dozen level-ups, and still tell you exactly what Kira's STR was in chapter 47 when a reader asks. That's a harder job, and a different one.

Here's what actually belongs on a LitRPG character sheet, and why most approaches start breaking around chapter 40.

What a LitRPG character sheet needs to track

Start with what makes the genre different.

In tabletop RPGs, stats change slowly. In LitRPG fiction, they're the plot. Leveling up, breaking through to a new tier, getting a class-specific unlock — these are story beats, not bookkeeping footnotes. The character sheet isn't a reference document you check occasionally. It's a living record you're in every time you write.

That changes what belongs on it.

Base stats and derived stats, kept separate. Base STR is 12. Equipment grants +5. A buff adds +3 temporarily. Derived STR is 20. These need to be distinct columns or fields, not a single number. Every time something changes — you swap out a piece of gear, a buff expires — you need to recalculate without losing track of where the base sits. Conflate them and your math breaks constantly.

Skills and abilities with tier and acquisition info. Not just "Fireball" but "Fireball, Tier 2, unlocked at level 15, damage scales with INT modifier." Skills in LitRPG evolve. A skill your character learned in chapter 3 might look completely different by chapter 80. The sheet needs to track the progression history, not just the current version.

Equipment with explicit stat grants. Items in LitRPG aren't flavor. A sword isn't just "deals 10 damage." It's "+5 STR, +2 DEX, special ability: Vorpal Edge (once per combat)." Equipment is a stat layer that sits on top of everything else. If your character sheet doesn't model that separately, you're doing the math by hand every time something changes hands.

Passive bonuses from titles, classes, and factions. Many LitRPG systems stack bonuses from sources that aren't items or skills. Your character is a [Dungeon Knight], a member of the Iron Pact, and has a [System Blessing] active. Each of those might grant properties or modify existing ones. These need their own section on the sheet, not a footnote.

A chronological change log. This is the section most authors skip and later regret. Every significant change should be traceable: what changed, what caused it, which chapter. Without it, you're doing archaeology on your own manuscript whenever a reader spots an inconsistency. It doesn't need to be elaborate. "Ch. 47: STR +2 from Iron Body skill" is enough.

Going beyond the numbers to make characters feel real

Stats make a character functional. They don't make a character feel like a person.

The part that does that is what fiction writing craft has understood for decades: characters need three dimensions to feel real. The physical (what they look like, how they move, what they've survived in their body). The sociological (where they came from, who shaped them, what they owe and to whom). The psychological (what they fear, what they want versus what they actually need, the contradiction that makes them interesting). This is the information that determines how your character speaks, which fights they pick, whether they hesitate before making the call that costs them everything.

Most LitRPG authors keep this separate from the mechanical sheet. One spreadsheet for the numbers, one document for the person. Both essential. Neither complete without the other.

The friction shows up slowly. You update the character profile when they lose an eye in chapter 60, update the mechanical sheet when they get a class upgrade in chapter 61, and hope you caught everything in both places. Over a long series, they drift. The profile says one thing about a relationship; the event log implies something different. By book three you're cross-referencing two separate systems just to write a scene.

The reason they live in separate documents is that the tools aren't designed to hold both. A spreadsheet is great for numbers and terrible for prose notes. A character bible document is great for backstory and useless for tracking that DEX went up twice in the last arc.

In AxiomWeaver, a character is a single entity and you define what properties it has. There's nothing stopping you from putting "physical appearance," "core motivation," and "relationship to Kira" on the same entity as STR, DEX, and skill list. The persona properties and the mechanical properties live in the same place, updated through the same event log, visible on the same screen.

That unification is not something I planned to emphasize early. Then I kept hearing the same thing from authors: "I have my character bibles in one place and my character sheets in another and they've drifted." Anyone past the first book in a series runs into it eventually.

The section that almost everyone forgets

Here's what's missing from most LitRPG character sheet templates: a distinction between what the author knows and what readers have seen.

Your character might have a hidden passive ability that doesn't get revealed until chapter 60. The stat is real, it's affecting the story, but it's not yet in the reader's understanding of the character. If you're tracking everything in one flat list, you lose that distinction.

This matters most for stories with unreliable reveals or reader-facing character sheets as a narrative device. But even for straight-ahead progression stories, it's useful to flag which stats are confirmed vs which are still building toward a moment.

It's a small thing to add. A simple "revealed / hidden" column on your skill and ability list covers most of it.

Why your character sheet breaks around chapter 40

A well-designed character sheet, maintained carefully, still only tells you the current state. Not what it was. Not what it will be. Now.

For a 10-chapter story, that's fine. For a 300-chapter progression fantasy series, it isn't. Eventually someone asks "what were Kira's stats at the end of the dungeon arc?" and you have no answer. The sheet only knows today.

You end up with one of two bad outcomes: versioned spreadsheets ("stats_v3_postdungeon.xlsx") that nobody actually maintains consistently, or you accept that some continuity questions can't be answered after the fact.

This is the deeper architectural problem, and it's worth understanding before you commit to any system. Tracking stats as events rather than snapshots changes the equation significantly. If every change is recorded as an event with a chapter reference, you can reconstruct the sheet at any point in the story. The character sheet becomes a view of that history rather than a static document you have to keep synchronized.

How AxiomWeaver handles character sheets

I built AxiomWeaver to solve this problem, so I should be honest about what it does and doesn't do right now.

Each character in AW is an entity with properties you define. When something changes in your manuscript, you log it as an event. The character sheet in AW isn't a form you fill in — it's derived from the event history. Change something upstream and the sheet recalculates. Hover any stat and you see the full breakdown: base value, each modifier, what granted it.

AxiomWeaver character entity showing base stats, derived stats, and equipment grants side by side

The base vs derived distinction is handled automatically. A sword is an entity. Equipping it creates a relationship that grants stats. Unequip it and those grants drop off. You don't update the math by hand.

The underlying structure for skills and equipment comes from a model of four composable primitives — entities, templates, relations, and events. It sounds abstract, but the practical result is that you can model most LitRPG systems without fighting the tool.

What AW doesn't do yet: multi-book series support is on the roadmap, not shipped. It's alpha, which means some rough edges. If you're 200K words in, the importer will pull your characters from an existing manuscript, but expect to do some cleanup.

A practical template if you're not ready for a dedicated tool

If you want to set something up today without new software, here's the structure that holds up:

One section for base stats, with each derived value broken down by source. One section for active skills with tier, chapter acquired, and current description. One section for equipment with explicit grant lists per item. One section for passive bonuses from classes, titles, and factions. And a running change log in chapter order — what changed, what caused it.

Keep the change log current as you write, not after. Retroactive logging is almost always incomplete. The discipline has to happen in the moment, or it doesn't happen at all.

The specific format matters less than the habit of recording events when they occur.

Try it

AxiomWeaver is free in alpha. Mac, Windows, and Linux. If the character sheet problem is one you're actively fighting, it's worth 20 minutes to see if the approach fits your system.

If you're building something with a more complex progression structure, the skill tree breakdown is a good next read.

And if you have a LitRPG system that's unusually complicated to track, I'd genuinely like to hear about it. Drop it in the Discord and tell me what's giving you trouble. Those conversations are usually what shapes what gets built next.

Writing LitRPG? Stop tracking stats by hand.

AxiomWeaver tracks your entities, stats, and timeline so you can focus on the story. Free to download, no account required.

Download for Mac (Apple Silicon)

Free during alpha · No account required