Building the Tool Behind the Tour: From Foundry to P.A.T.H.: ANE
Today I am turning a recurring development problem into a tool of its own.
My working name for the toolkit was P.A.T.H.: Foundry. But I'm thinking of renaming it P.A.T.H.: ANE—the Assisted Narrative Engine.
The new name is more accurate. “Foundry” suggests a place where content is manufactured. The larger purpose is assistance: helping me research, structure, test, review and expand narrative content without allowing generation to become automatic canon.
The name change is a direction, not a claim that every label in the current source has already changed. The game needs a controlled migration when I return to that work. For now, ANE is the clearer description of what I was trying to build.
Why the game needs a tool behind it
P.A.T.H.: Vietnam contains more than scenes in a line.
A scene may depend on a date, location, role, relationship, item, wound, earlier promise, historical condition and the current state of the squad. Its artwork may need identity variants and historical review. Its text may need content-mode alternatives. Its result may create an event that has to survive saving, loading and movement to another device.
As the tour grew, managing those relationships directly in files became harder. A change in one place could quietly disagree with another. An interesting new beat could repeat too often, name someone who was no longer alive or display artwork that did not match the person described.
The Foundry/ANE began as a way to make those connections visible before they reached the player.
Assisted does not mean autonomous
I don't want a live model inventing historical canon, casualties, dialogue and consequences without review while somebody plays. That would make continuity difficult to test and historical claims difficult to source. It would also make it harder to explain why the game produced a particular outcome.
The intended process is slower and more accountable:
- Define what the game needs.
- Record the relevant constraints, evidence and existing state.
- Create or collect candidates.
- Review those candidates for design, history, tone, identity, rights and duplication.
- Approve a specific version.
- Export a versioned package.
- Integrate it through ordinary code review, testing and release gates.
An export is not the same thing as putting content into the live game. A generated image is not approved art. A queue entry is not an image at all. The distinctions can sound bureaucratic until a project contains hundreds of assets and a full year of consequences. Then they become the difference between a system that can be trusted and a folder full of mysteries.
What the Foundry/ANE could eventually help manage
The engine’s useful scope is broader than content production.
It tracks historical claims and the evidence behind them. It can identify places where the tabletop rule and digital rule intentionally differ. It describes a scene contract: when the scene may occur, which characters are eligible, which choices appear and what must be recorded afterward.
It helps inspect campaign coverage. Are there long stretches with too much repetition? Does one role receive far more unique material than another? Are the important relationships visible outside dramatic events? Does a later callback have the state it needs to make sense?
For artwork, it keeps the target, candidate, provenance, identity requirements, review notes and approved runtime file separate. For narrative content, it can keep draft, revision, approval and versioned export separate. For testing, it can run deterministic tours and look for patterns a single manual play-through may miss.
That is an engine to create purposeful narrative production, not automatic generator.
The dangerous invitation: make everything now
Once the tool started taking shape, the temptation became obvious.
Why stop at one campaign? Why not create 5 eras, ten years of dates, events, items, roles, images and alternate tours? Why not create every branch while the system was exciting?
Than answer is clear: Because the player-facing game is still changing.
Developing content on an unstable contract multiply every mistaken assumption. If the mail system changes, hundreds of letters may need repair. If the identity model changes, a large art library may become inconsistent. If the daily rhythm changes, years of carefully tagged scenes may no longer fit the actual game.
Scale does not make an unresolved design more correct. It makes it more expensive to correct.
I am deciding to stabilize the tour first.
What “stabilize” meant
Stability doesn't mean freezing the game or declaring it finished. It meant protecting the promises other content would depend on.
The same soldier should return after a reload. A committed outcome should not reroll. Mail should reach the right system. Inventory should identify where an item is and whether it is usable. Relationships should refer to living people and remember what happened. Accessibility choices should persist. The current campaign dates and state transitions should remain deterministic enough to test.
Those foundations are not glamorous compared with the possibility of developing other tours. But they are what will make it possible without rebuilding everything again.
Where the Foundry/ANE stands today
The toolkit is an early production design system, not an automatic pipeline. Some foundations are taking shape; other parts remain plans I need to test. I am deliberately keeping simple to establish stable contracts before the tool helps me produce years of material against them.
ANE should help me improve the content and game experience without losing the thread.