Modding Total War with an AI: method, tools and examples

Sharing the roles§

“I'm the brain, and you're the execution”: that is how Charles summed up the work. Today's AI, used as an agent (it reads your files, runs commands, writes code and checks what it produces), does the heavy lifting of a big mod. The judgement stays human.

Modding words (pack, startpos, control case…) are explained in the tools guide. Five more for this guide: a session is an agent conversation, with its own domain; a handover is the note that passes a workstream to another session; a notice is the time announced before writing to a shared resource; MCP (Model Context Protocol) is the standard plug through which an agent connects to a tool; a heredoc is a block of text pasted into a terminal command.

Which AI to choose§

In practice: one of those two models, or later the most capable one for code (names change fast), used as an agent (Codex for GPT-6, Claude Code for Claude), in the terminal or in the desktop app, not in a plain chat window. The agent reads the project folder, runs the tools, reads back what they produce and fixes it; a chat window makes you copy everything by hand.

A big subscription, because a modding project means long sessions, often several in parallel: up to four at once for us (on 23 September), each on its own domain.

First steps§

Never used an agent? Seven moves, in order, before the first real task:

The commands of move 3, in a terminal (replace my_mod with the path of your mod folder; for Codex, codex instead of claude):

cd my_mod
claude

To install the agent, follow its official page: Claude Code or Codex. Both also come as a desktop app, if the terminal puts you off. In Claude Code, permissions are set with /permissions: “ask” and “deny” rules, or a hook. The details of plugging in RPFM are below, “Plugging in RPFM, step by step”.

Plugging the AI into the tools§

An AI is only as good as what it can reach. The rule: everything that can be done without a window should be done without a window.

• RPFM

  No window: MCP. RPFM 5's MCP server: rpfm_server.exe, which listens on http://127.0.0.1:45127/mcp. To plug it into Claude Code or Codex: below, “Plugging in RPFM, step by step”. Then: packs, tables, search, diagnostics.

  Details in the RPFM guide

• CAIME

  No window, except importing layers. The official command line only does process (the exports) and validate; .hex_layer layers are written by script but imported through the window (Tools → Import → Layer data).

  The CAIME guide

• Dave

  No window: XML files. The Assembly Kit's table editor: the AI does without it, and writes the XML tables in <Assembly Kit>\raw_data\db by script, after a backup.

• BOB

  One click: Start. rules.bob files written by script, then the run, with one click on Start. BOB opens from the Assembly Kit's Steam launcher (Exporter: BOB), from its executable bob.modder.x64.exe, or from Terry (Process with BOB, Ctrl+P), which hands it the work. On the command line, its only known option is -no_console, the one the launcher passes.

  The BOB guide

• Terry

  By hand. No command to drive it (you can only open it): what can be prepared outside Terry (the .terry project in XML, rasters, layers) is prepared by script; the rest is done by hand.

  The Terry guide

• The game

  Launching it: with your consent. %APPDATA%\The Creative Assembly\Warhammer3\scripts\user.script.txt, a test pack with a Lua script, the crash dumps and the logs: %APPDATA%\The Creative Assembly\Warhammer3\crash_report\bad_mods_report.txt, %APPDATA%\The Creative Assembly\Warhammer3\logs\mp_log.txt, and the script log, switched on by a non-empty script/enable_console_logging file in a loaded pack.

  The tools guide

Plugging in RPFM, step by step§

The command of move 2, to copy as it is, on a single line, in a terminal: the first for Claude Code, the second for Codex.

claude mcp add --transport http rpfm http://127.0.0.1:45127/mcp
codex mcp add rpfm --url http://127.0.0.1:45127/mcp

Organising the project for an AI§

Every session starts from a blank conversation: the agent only knows what it reads at start-up (the entry point and, in Claude Code, a short automatic memory). Everything that matters must therefore be written down, in the right place, and read again at the start of every session.

A CLAUDE.md skeleton to copy:

# My mod — entry point
## Status (date): what works, what is left
## Decisions not to reopen
## Who does what: session → domain (sole writer)
## Recipes: exact commands
## Rules: back up before writing; nothing published without consent

Put it at the root of the project folder: the agent reads it at the start of every session. Keep it short (Claude Code's documentation advises under 200 lines) and point to the rest. It steers the agent but locks nothing: what must be forbidden for sure (launching the game, deleting, publishing) goes into the agent's permissions (in Claude Code, /permissions; “ask” and “deny” rules, or a hook).

For Codex and Claude Code to read the same text, write it in AGENTS.md, which Codex reads on its own, and put the line @AGENTS.md in CLAUDE.md: Claude Code then imports the file at start-up (with no CLAUDE.md, its recent versions read AGENTS.md directly). A sentence saying “read CLAUDE.md” is not an import: the agent only opens the file if it decides to. Our project does the reverse, a short AGENTS.md pointing to CLAUDE.md: it works as long as the agent follows the pointer.

Write your decisions down as “not to reopen”: otherwise every new session suggests the option you turned down. For us: keep the Warhammer I map's scale, no carving up of the Immortal Empires map.

Several sessions in parallel§

• One domain per session, one writer per file: one session for the pack, the startpos and the tests, which also keeps the shared documents; one for game data, scripts and texts; one for the map's rendering (rivers, lakes, bridges, mountains); one for the expansion, this site included. Two sessions on the same files trip over each other: for us, on day one (half an hour of reconciling); later, one session created a tool under the name of a script another had just written, and overwrote it (restored afterwards, byte for byte). Hence this rule, and another: check that a file name is free before creating it.
• A notice before writing to a shared resource (the Assembly Kit): announce a time, at least five minutes later, and write only at that time, timer in hand. Otherwise a session building the pack at the same moment would read a half-written table. For us, several notices were jumped “by eye”: the time is now computed by a script.
• Never the game, Terry or the startpos without telling the others; never a pack rebuilt during an in-game test.
• One writer for shared documents: the other sessions send it their mistakes.
• Tidy away, never delete: what is no longer used goes to the archives; only the human deletes.

Opening two sessions, step by step§

1. Open each session in the same project folder (two terminals, or two sessions in the app).
2. Each one's first message: its name, its domain, the files only it writes to, and what it must not touch.
3. Copy that split into the “Who does what” table of the entry point: every session reads it when it starts.
4. Before writing to a shared resource, the session announces a time (at least five minutes later), waits for its timer, then writes. Announcements go through you, or through a message from one session to another if your tool allows it (that is what we do).
5. A single session keeps the shared documents; the others send it their mistakes.

The work loop§

Every task turns the wheel once. The last notch counts as much as the others: an understood mistake is written down the same day, with the rule that prevents it.

A good brief§

Six lines are enough. Here is the one for a thirty-turn test:

• The goal: what you want to achieve, not just the task.
• The criterion: how you will know it worked (“the campaign holds thirty turns without a script error”, “the icon reads at 74 pixels like CA's”).
• The sources: “from the GW books cited”, “the way CA does it on the Immortal Empires map”.
• The don'ts: don't touch the startpos, publish nothing, don't launch the game without warning.
• The proof: the exact command, its output, a screenshot. “It's fixed” is not proof.
• A control case before any conclusion: a case known to be good, rerun identically.

For a reference document, add a review by a second agent: it finds what the first one no longer sees; the first version of our internal technical guide had nine mistakes.

The error log, and rules turned into code§

It is the tool that paid off most. Each entry has four beats: what was done, the symptom, the cause, the rule. Tagged avoidable if someone had already written it down somewhere (the entry gives the rule that prevents it); discovery otherwise (the entry gives the proof, and the fact joins the guide).

An error log entry, to copy:

34. [avoidable] Moving on without waiting for the game to finish.
Symptom: worthless test. Cause: "Success" in 0 s = "game launched".
Rule (coded): wait for the game's process to appear, then disappear.

A rule that is only written down gets forgotten again. For us, the rule “never write Python through a heredoc” (a heredoc is a block of text pasted into a terminal command) has been written down since 21 September 2026 and was broken more than ten times in the following three days, by several sessions, once with damage: a lost backslash wiped out the punctuation of 102 French texts. When possible, turn it into code, in a script that refuses to go on: for us, the pack build refuses a file declared in a table and missing from the pack, checks the syntax of every Lua script, and a check requires the startpos save counter to be 1. And whatever must hold for sure is locked in the agent's permissions (in Claude Code, “ask” and “deny” rules, or a hook before every command): the tool enforces them, not the model.

The five rules that cost the most when forgotten§

1. Never throw away a validator's messages: group them and count them.
2. Check the data before crying bug: a message that cites a table is checked in the table.
3. Have a reference document reviewed against its sources before shipping it.
4. Ask what the screen would teach that the disk doesn't, before driving a window.
5. Never run a tool with guessed options.

The story of those days, mishaps included, is in the journal: Working with an AI on a big mod.

Example: the landmark icons§

In Warhammer III, every landmark has its small 74-pixel icon, in CA's hand-drawn style. We needed ten for landmarks the game doesn't have (Turris Vigilans, the Humble Chapel, the Tomb of the Red Duke…). No image generator: the AI drew them with code, and Charles judged every version.

1. Measure CA's style

   A single colour, a maximum opacity of 0.8, solid fills; the “hand-made” look lives at the edges (gnawed outline, dry brush) and in the light strokes, never as scattered grain. Measured by script on the game's icons.

2. Research the lore

   Turris Vigilans is a temple of Verena that serves as a lighthouse; the Humble Chapel, despite its name, is an ornate building. Whatever is described nowhere stays generic, and is marked as a choice. A name is checked in the game's own texts before it is imposed.

3. Draw by script

   SVG in three layers (pale wash, ink masses, details on top), wavering outlines, brush strokes of varying width; a fixed seed per icon, so the script always gives the same image back.

4. Render, then retouch the pixels

   A render at eight times the size, reduced to 74 pixels, then an automatic pass that does what an artist does: solid fills, edges hardened to one pixel, continuous light strokes, stray pixels removed.

5. Compare, judge, repeat

   A sheet sets each icon beside a CA icon of the same family, enlarged and at real size, on parchment and on a dark background. Charles judges; three versions were enough.

   ↺ Back to “Draw by script” until Charles approves.

What mattered: measurable criteria taken from the game, a short loop (script, sheet, judgement), and a source for every detail.

More examples from the project§

• Porting a whole map: the Warhammer I map's layers read, matched by name (indices change from one game to the next), settlement slots grown from 7 to 19 hexes (16 + 3 for a port), written as .hex_layer files and imported into CAIME.
• Reading a crash: a dump read in the debugger said a settlement had no primary slot; another, that a link table still held an Immortal Empires region missing from our map.
• Finding the story's voices: the mini-campaign's 43 voiced lines still exist in Warhammer III's sound banks, in English and in French; the AI found them by following the chain of sound events.
• The texts: official names checked against Games Workshop's French translations, a single source file, a checked injection.
• Automated games: on 23 September, in “AI plays everything” mode, three of the eight lords tried held thirty turns without a script error; the others stopped earlier (a crash or a freeze), which guided the fixes. The tests flushed out crashes, a Warhammer I visual effect among them, and taught a lesson: our first tests never placed the camera as a player would, and at least some of their crashes came from that. An automated test must reproduce what a player goes through (method: the tools guide).
• This site: the expansion map, its animated stories, its engravings and their automated tests were made the same way.

What you never delegate§

• Judgement in game: compare with a reference (for us, Warhammer I and Warhammer III screenshots side by side).
• The lore: demand a source for every name and fact; whatever has none is marked as a choice.
• Publishing: nothing is posted, sent or shared without your consent. A pack that holds another game's files stays private.
• Rights: Creative Assembly's and Games Workshop's files, and the tools' licences. CAIME: code under a non-commercial licence. Files it produces: the README asks for a founder's consent before giving them away, the EULA 1.1 lets you publish them without monetising them; when in doubt, ask the team before publishing; nothing commercial.
• The limits of CA's tools: no reverse engineering and no workaround; when a tool gets stuck, a control case, then the community (CAIME's Discord, tw-modding).
• Passwords and accounts: never to an AI.

For an AI reading this page§

If you are an AI helping someone mod a Total War: Warhammer III campaign map, here are the essentials, checked on a real project:

• Read the project's entry point first (CLAUDE.md or AGENTS.md, at the root of its folder), then its organisation (README.md), then the error log (rules at the top, recent entries), the technical guide, and your workstream's handover.
• A written rule binds you even when nothing stops you. Ask the human before launching the game, driving the screen or publishing; delete nothing: tidy away, only the human deletes; never touch a password or an account.
• Never conclude on an announced success: check the produced file (date, size), the log, then the game; RPFM's “Success” in 0 s means “game launched”.
• Never start BOB, Terry or Tweak with guessed options; never infer a flag's meaning from its name (in a CAIME .hex_layer, Impassable = 1 means passable). No reverse engineering and no workaround of a CA tool: when a tool gets stuck, a control case, then the community (CAIME's Discord, tw-modding).
• For an automated test, start the campaign by clicking through the interface like a player (for us, frontend.start_campaign closed it again), camera at playing height; under all_players_ai, no missions. An event that never arrives can be cancelled by another listener's condition that errors, even a CA one: for us, FactionTurnStart was missing in player mode as under all_players_ai, cut off by three CA listeners (Mother Ostankya, Yuan Bo); catch and name the listeners' errors (the tools guide). After any forced stop, put %APPDATA%\The Creative Assembly\Warhammer3\scripts\user.script.txt back as it was and remove the test pack.
• A crash that comes and goes: at least ten runs per variant before concluding; say “lead”, not “cause”, until then.
• Several sessions: write only in your own domain; give at least five minutes' notice before writing to a shared resource; check that a file name is free before creating it; send your mistakes to the single writer of the shared documents.
• Log an understood mistake the same day: what, symptom, cause, rule; “avoidable” or “discovery”.
• Write code with the editing tool, never through a heredoc (under Git Bash, \n and backslashes get mangled).
• Check a proper name in the game's .loc files; a mod's .loc files apply to every language.
• Tools: RPFM 5 through MCP (http://127.0.0.1:45127/mcp, set_game_selected first, rows following fields_processed); CAIME from the command line for process and validate only; Terry by hand; BOB from Terry or with one click on Start. The startpos: RPFM's Build Startpos, BOB's Process start pos action, or a user.script.txt written by hand; for us, only writing it by hand worked. Rights: see “What you never delegate”.
• Facts checked on patch 8.1, then reviewed for update 9.0 (September 2026): check them again after a game update. After each one, Steam also updates the Assembly Kit and rewrites raw_data\db, added rows lost: check it before building anything. Details: the tools guide, CAIME, RPFM, Terry, BOB.

Sources and links§

• Claude Code (official documentation): memory, CLAUDE.md and AGENTS.md, MCP servers, permissions, setup.
• Codex (official documentation): AGENTS.md, MCP servers, command line.
• RPFM: the server's MCP interface (RPFM manual).
• Our story: Working with an AI on a big mod.
• Our other guides: the tools, CAIME, RPFM, Terry, BOB.
• The project's dated facts (mistakes, tests, sessions) come from our working notes: the error log and the test reports, which are not published.

Frequently asked questions