P.A.T.H.: Vietnam

P.A.T.H.: Vietnam — Developer's Dispatch

Game Updates, Reflections, and Dev Notes

Developer's Dispatches on design, history, systems, and other stories behind the P.A.T.H. Games title; P.A.T.H.: VIETNAM.

· development event reflection

What OpenAI Build Week Taught Me About Finishing

Soldiers carry supplies and work beside a helicopter in a smoky field
Build Week is teaching me that finishing is less glamorous than ideation—and much more useful.

It is 25 July 2026, four days after the OpenAI Build Week submission deadline.

The P.A.T.H.: Vietnam Devpost page is the public record of the submission. This note is not an announcement of a result. Judging is still underway. It is about what the process taught me while the work is still fresh.

OpenAI’s official event name was Build Week. The registration and submission period ran through 21 July, with judging following afterward. A short deadline is useful because it removes the fantasy that every possible improvement belongs in the same release.

It also reveals whether the project can explain itself.

The submission needed a story, not a repository tour

P.A.T.H.: Vietnam had accumulated years of research and a fast-growing current build. I could describe the game through mechanics, history, architecture, artifacts, roles, saves, radio, Foundry and a long list of features. None of that automatically answered the first question a reviewer would have: what is the experience?

The clearest answer became one soldier living one historically situated tour, carrying decisions across ordinary days and major events toward home.

That sentence helped decide what belonged in the submission story. The calendar mattered. The Field Desk mattered. Durable relationships and records mattered. A technical feature mattered when it protected that continuity.

The deadline forced me to stop presenting complexity as its own evidence.

Making the public overview exposed weak language

On 21 July, the repository gained a project overview written for the Build Week submission. The first version recorded a validation baseline of 97 passing test files and 644 passing tests, with TypeScript and the production build passing at that moment. Those are dated submission-period figures, not current totals and not proof of production behaviour.

The overview also needed an immediate framing correction. Language about a universal “365-day tour” was too broad. The game’s first campaign has specific dates and its own DEROS path; historical tour policies varied by service, role and assignment. The correction changed the public explanation from a universal rule to a campaign-specific chronology.

That was a valuable Build Week lesson. Public writing is part of testing. If I cannot describe the campaign precisely, there may be an assumption inside the design that also needs examination.

Codex was most useful when it could be checked

Codex with GPT-5.6 helped across research, code, tests, documentation and review. During the Build Week period, the work included reconciling documentation with the current repository, tracing React and Phaser lifecycle problems, strengthening save continuity, building an event ledger, analyzing pacing, expanding mail and narrative memory, integrating the researched PX catalogue and establishing private Foundry review workflows.

The important part was not how many areas an AI system could touch. It was whether each contribution could be inspected.

A test can pass or fail. A Git change can be reviewed. A scene can be opened in the developer viewer. A deterministic replay can be compared. A content candidate can remain unapproved. A historical claim can be separated from the code that implements it.

The weaker use of AI is persuasive explanation without evidence. A model can describe a system as complete even when one handoff is still manual or one production state has never been verified. Build Week reinforced a rule I want to keep: the current source, tests and actual player experience outrank a confident summary of them.

A deadline makes scope visible

Every day produced another reason to add something.

The private Foundry system could expand. Art could receive more variants. Onboarding could become smoother. The Field Desk could hold another record. The tour could use more unique content. The submission could always use a better image or sentence.

The deadline required a boundary between “important” and “important for this submission.”

That is difficult for a solo creator because no department is waiting for another department to deliver. I can move from a save bug to a piece of copy to a visual asset without leaving my desk. The flexibility feels efficient, but constant switching can hide the fact that nothing has crossed a finish line.

For Build Week, finishing meant having a coherent project story, a working validation baseline, a repository overview that did not expose private manuals or secrets, and a submission that represented the game honestly enough for somebody outside the project to understand it.

It did not mean the game was commercially finished.

What did not become true because I submitted

The submission did not verify the production database. It did not clear every piece of audio or art for commercial release. It did not complete the historical source ledger or replace human advisory review. It did not prove an App Store, Steam or itch.io route. It did not make every Foundry module automatic.

Those distinctions can make a project description sound less triumphant. They make it more useful.

An event entry is a snapshot of a project under pressure. It should not become a permanent excuse to repeat claims after the source has changed.

The lessons I want to keep

Build Week left me with several practical lessons:

  1. Explain the player’s experience before the technology. The stack matters after a person understands why the game exists.
  2. Treat public copy as a test. Sweeping language often points to a design or evidence problem.
  3. Use AI where the output can be reviewed. Speed is valuable when it produces a visible change, test or candidate—not invisible certainty.
  4. Keep private foundations private. Manuals, research, credentials, production identifiers and internal tools do not need to become submission content.
  5. Record dated evidence. A test count belongs to the run that produced it, not to every future version.
  6. Finish a boundary. A submission is complete because its scope is defined, not because the project has no remaining ideas.

The first days after the deadline

The first days after the deadline have not become quiet. Foundry is gaining more recovery, disposition, revision, editing and export controls. The game continues to stabilize. New work exposes new risks.

But the submission changed my relationship with the project. P.A.T.H.: Vietnam no longer existed only as a private world I could explain indefinitely. I had to present a version another person could judge on the evidence in front of them.

That pressure was useful.

I did not learn how to finish the entire P.A.T.H. idea in one week. I learned how important it is to finish one honest version of the story, test the foundation underneath it and leave the next ten years outside the deadline.