How to Voice a Game's Codex and Lore Entries With AI

October 11, 2026

A codex is the text a player chooses to read. The monster they just killed gets a bestiary page. The faction they keep hearing about gets an entry. The sword they picked up has three paragraphs of history nobody asked for and some players read twice.

It is the one part of a game script that is written to be read and almost never gets voiced, because there is too much of it and none of it is urgent. That is exactly the shape that makes it worth generating as audio: a large pile of low-priority static text that a player might want read to them while they keep walking.

The part that changes how you plan it: AudioProducer renders the text you give it, and the same text renders the same way every time. A codex entry does not need variation, so the thing that makes ambient dialogue hard makes lore easy. You write the entry once, generate it once, and it reads the same on every visit, which is what a reference text should do anyway.

The spoken lines characters actually perform in a scene are a different job, covered in how to voice NPCs in your indie game. This is the readable half of the world, the part with no scene around it.

What counts as codex, lore, and bestiary text

Codex and lore entries are the optional reference text a player opens from a menu: an encyclopedia of places and factions, the history behind an item, the log a character keeps. Bestiary entries are the same thing pointed at enemies, usually a page that unlocks the first time you meet or kill one.

What they share is that nobody is speaking them in the fiction. They are the game explaining itself to the player, read on demand, outside of time. That is the opposite of dialogue, which happens to a character in a moment, and it is why the two want different handling.

The practical upshot is that codex audio is a reading, not a performance. It should sound like someone reading you a good reference, steady and clear, not like a character emoting at you.

One entry is one chapter

The export unit in AudioProducer is the chapter: one click renders a chapter to a single audio file, and each chapter downloads separately. So make each codex entry its own chapter and you get one audio file per entry, which is the file your menu plays when the player opens that page.

That mapping is the whole reason to structure it this way. The engine already knows which entry is open; it needs the matching file to hand. Keep the chapter name tied to the entry's identifier rather than its title, since chapter names become download names and naming and organizing game voice line files has a scheme that survives a few hundred of them.

Resist the urge to pour the entire codex into one long chapter. A single file you have to seek inside is useless to a menu that wants to play one entry, and it is harder to regenerate when you revise a single page.

Cast one reader voice, not a voice per subject

The reflex from dialogue work is to give each faction or monster its own voice. For a codex that is the wrong instinct. The entries are not those characters talking; they are a neutral source describing them, so one consistent reader across the whole codex is what makes it feel like a single in-world reference rather than a cast taking turns.

Pick that reader voice to match the frame. A survival-horror log wants someone plain and tired. A high-fantasy compendium can carry a more formal narrator. Assign that one voice to every codex chapter and keep it stable, the same way turning a TTRPG sourcebook into audio leans on one steady narrator across a whole rulebook.

The exception is a quoted passage inside an entry, a letter or an overheard line the lore reproduces in another character's words. Those can take that character's voice as a short insert, then hand back to the reader. Used sparingly it marks the quote; used on every entry it turns the codex back into a radio play.

Rewrite the entry for the ear before you generate it

Codex text is written to be read on a screen, and screen-reading forgives things listening does not. Before you generate an entry, read it aloud once and cut what only works on the page:

  • Spell out what the eye skims. "HP", "Lv. 3", "the 2nd Legion" and a date written as digits all need a spoken form, because the renderer voices the characters as written.
  • Break the wall. A dense screen paragraph that scans fine becomes a breathless run when spoken, so split it where a reader would pause.
  • Drop the parentheticals and cross-reference asides. "(see also: the Sundering)" is a hyperlink, not a sentence, and it stalls the read.
  • Keep the first sentence a real summary. A player who opened the bestiary page wants the gist before deciding whether to listen to all of it.

This is a light edit, not a rewrite. The goal is a version that survives being heard once, since most players will listen rather than re-read.

Bestiary pages: voice the flavor, not the stat block

A bestiary entry is usually half prose and half numbers: a description of the creature, then resistances, drops, and spawn locations. The numbers do not want to be audio. A spoken "fire resistance forty percent, weak to lightning, drops two to four hide" is slower and less useful than the on-screen table the player is already looking at.

Generate the flavor text, the part that reads like writing, and let the stat block stay on screen. If you want the audio to acknowledge the mechanics, one spoken sentence of guidance beats reading the table: "it shrugs off fire and hates the cold." That is a line worth hearing; a list of figures is not.

Export, triggering, and what stays in your engine

After the download the pipeline is yours. AudioProducer exports MP3 files and stops there. There is no engine plugin, no API for pulling lines, and nothing hosted or distributed on our side, so playing the right entry when a menu opens, stopping it when the menu closes, and any fade happens in your engine against the file you exported. There is also no per-line volume control in the editor, so levels are set on your side too.

Budget the pass in words the way you would any other voice work. Lore is text-heavy and it adds up faster than dialogue does, so a codex of a few hundred entries is a real chunk of your monthly word budget and worth sequencing rather than generating in one sitting. If you are localizing, the entries translate and regenerate like any other text, and localizing your game's dialogue with AI voices covers keeping a voice consistent across languages. The full guide index collects the rest of the game-audio and export guides.

A reasonable first pass is one category: five bestiary pages, each its own chapter, one reader voice, the stat lines left on screen. Generate the set, listen to them back to back, and check that an entry still lands when you are half-reading the map instead of staring at the page. Sign up free for AudioProducer.ai to voice your first batch of lore entries.

Frequently asked questions

Should each codex or lore entry be its own chapter in AudioProducer?
Yes. The export unit is the chapter: one click renders a chapter to one audio file and each downloads separately, so one entry per chapter gives you one file per entry, which is the file your menu plays when the player opens that page. Keep the chapter name tied to the entry identifier, since chapter names become download names.
Should I use a different voice for each faction or monster in the codex?
Usually no. Codex entries are a neutral source describing the world, not those characters talking, so one consistent reader voice across the whole codex reads as a single in-world reference rather than a cast taking turns. The exception is a quoted letter or line inside an entry, which can take that character's voice as a short insert.
Can AudioProducer read a bestiary stat block aloud?
It will voice whatever text you give it, but stat blocks do not make good audio. A spoken list of resistances and drop rates is slower and less useful than the on-screen table. Generate the flavor text and leave the numbers on screen; if you want the audio to nod at the mechanics, one plain sentence of guidance beats reading the table.
Do I need to write variations of a codex entry so it does not sound repetitive?
No. A codex entry is reference text a player opens on demand, so it should read the same every time. AudioProducer renders identical text identically, which is exactly what you want here, unlike idle or ambient dialogue where you write several versions on purpose.
How does the voiced codex get into my game?
AudioProducer exports MP3 files and stops there. There is no engine plugin and no API for pulling lines, so playing the right entry when a menu opens, stopping it when the menu closes, and setting levels all happen in your engine against the exported files. The export maps one chapter to one file to make that wiring straightforward.

Related posts