about codex and guardian tales

[洛雨]

A Letter to the Kong Studios Guardian Tales Team
From: Luoyu — indie developer & long-time GT player
Dear Kong Studios team,
Long time no see — it's been a while. I'm Luoyu.
I'm an indie developer and a long-time player of Guardian Tales. I recently noticed your team is hiring across several roles — narrative design, art, engineering. I stared at that post for a long time, not because I was drafting a résumé, but because it reminded me of the problems I've been running into myself these past few months. I thought I'd write them down. Maybe something here will be useful.
Attached is the iteration log (V01–V07) of a deep-sea tower-defense prototype I built alone using the process described below.
1. What I Actually Believe
For a game that lives on high-density content updates, the real pressure is never "running out of ideas." It's the pipeline — the grind of reliably shipping those ideas. Design waits on art, art waits on engineering, engineering waits on review, and every hour of waiting is stolen from creativity.
This isn't a guess from the outside. It's what I learned by building things myself.
So this letter isn't about "AI replacing anyone." It's about a workflow that turns AI from one do-everything assistant into a small team with actual job divisions. It doesn't take anyone's job. It just frees people from the back-and-forth.
2. The Failures I Ran Into First
① The single-window trap. One chat window wrote story, drew maps, rewrote code, and tuned numbers. The first two or three weeks felt amazing. Then it inevitably collapsed: context got polluted by information from different disciplines, the model started mixing up its own settings from the previous turn, and outputs became self-contradictory. The fix was always "open a new window and start over," which zeroed out every judgment I'd accumulated. This is the most insidious kind of failure, because it looks extremely efficient at the start.
② The fragmented-chat trap. Ask whatever comes to mind, no archiving, no versioning, no acceptance criteria. A month later, there isn't a single sentence you can hand directly to engineering.
③ The ticket-file trap (Codex's default Markdown dispatch). This one deserves special warning because it looks the most engineered, the most orderly. But orderliness isn't productivity. Every dispatch required a full task description, preconditions, and acceptance criteria — and the model had to re-swallow all of it on every read. As the file tree bloated, it spent more and more effort just figuring out which task is in progress, which is done, which got rejected. Worst of all, the ticket mechanism itself became the discussion venue: lots of turns spent confirm‎ing status, restating requirements, updating progress markers. The project ended up permanently discussing and barely moving.
3. The One Change That Mattered: Role Windows
I made a single change, but it was the decisive one: instead of one window doing everything, give each discipline its own independent, persistent chat window, with a strictly enforced responsibility boundary.
Gameplay design · level & numbers · UI/UX · art director · asset production (incl. VFX) · tech architecture · gameplay engineering — each stays in its lane, no临时混用. The art window doesn't touch numbers, the numbers window doesn't touch story, the engineering window doesn't make aesthetic calls.
Once context was physically isolated, the pollution problem disappeared on its own. Each window only carries the memory it actually needs, so read volume drops sharply. And — perhaps most importantly — you can start managing them like a real team: you learn which window is good at what, where each one tends to drift, and your instructions get sharper over time.
I call these role windows.
4. The Commander Window, and Writing Prompts Like Specs
On top of the role windows sits a commander window. It produces no content. Its job is intake, decomposition, issuing constrained prompts, tracking replies, cross-checking, and version archiving — only major directional decisions come back to me.
The biggest lever in the whole system is prompt hardness. My early instructions read: "make a deep-sea-style battlefield, with guardians and rune monoliths, route a bit twisty." It drifted every single time, because "deep-sea style" and "twisty" are subjective — the model can only guess.
Later dispatches read like this (excerpt from the V07 round):
Vertical battlefield, reference spec 540×960. Three horizontal defense lines, each formed by guardian deployment slots and intact rune monoliths arranged horizontally. Under normal conditions each line keeps exactly one passable gap for enemies. The three gaps must stagger left / right / left, so the path from the top entrance to the bottom chest forms a clear zigzag approach. No central-straight-through design. No rubble-default layout. Keep V04's eye-level composition and the monolith-stagger rhythm; discard V05/V06 entirely, not candidates.
Every requirement is objectively checkable. Three gaps? Staggered? Central straight-through present or not? Did it carry V04 forward? Answers are yes or no, no aesthetic debate required.
Two habits grew out of this: always write a negation list (and verify each item at acceptance), and put the acceptance checklist up front in the dispatch itself — self-constraint improves noticeably once the model knows how it'll be judged.
Each delivery must reply in three fixed lines: what I did / what changed / please check this one thing. Replies must be self-contained, since windows don't call each other.
5. Cross-Window Parallelism Needs No Bridge Service
I assumed early on that cross-conversation coordination would need MCP or some external bridge. I wasted a lot of time on that. It doesn't. Persistent windows are your long-term staff, the human is the message bus, and a clear window roster is the contact list.
What actually determines success are three plain disciplines:
• Role boundaries fixed, never temporarily mixed
• Replies self-contained, no dependence on follow-up questions
• Ship only the delta, never the full text
Do those and the token bill drops on its own. Context isolation means no window re-loads the whole project state; delta passing means I send only what changed; structured replies replace hundreds of words of free-form restatement; and state lookup cost — the ticket approach's biggest hidden expense — falls to nearly zero, since the state sits right in the window's last few turns.
At comparable scale, the ticket approach burned roughly three to five times what this does. But the more valuable saving isn't tokens — it's patience and velocity. Tokens you can buy. Attention you can't.
Honest limitation: because there's no automatic cross-calling, the commander carries all coordination weight. If replies go vague, parallel degrades straight back into serial. So the real gate here is can you write a合格 dispatch prompt and reply template, not can you install a tool.
6. Art Assets: image2 / 2.5 as Concept Finish Art, Not the Production Line
My positioning here is deliberate, and getting it wrong collapses quality expectations everywhere downstream.
7. Style anchor. Lock one基准图; hang every subsequent render on the same style description plus the same reference. Describe to a checkable degree: line weight, hue range, contrast intensity, shadow treatment, whether outlines exist. Vague words like "deep-sea vibe" have no constraining power.
8. Layered passes. Lineart → color → VFX, three separate runs. When one layer drifts you only redo that layer. This matters enormously for iteration cost.
9. Composition first. Vertical games have harsher constraints than horizontal — narrow visible area, large UI footprint. Have the UI window produce the safe-area grid first, then have the art window render inside it. Avoids the classic rework of "beautiful image that doesn't fit the screen."
10. Placeholders first. Low fidelity until gameplay locks; raise precision only after. The common mistake is chasing art finish too early, then scrapping everything when玩法 changes.
11. Export rules前置. Slice naming, atlas packing, pivot points, nine-patch stretch — written into the asset window's hard constraints before a single image is generated, or engineering inherits another round of rework.
12. Consistency control. Reuse reference image and seed across renders of the same character or scene, and lock a batch of invariant description fragments. Perfect consistency is unreachable, but "obviously the same thing" is very reachable.
I treat these images as direction-confirmation pieces for humans and reference material for other AIs — not as in-game finals.
13. Two Paths, and Why GT Probably Needs Both Running at Once
After making a few different small games, I've formed a strong opinion: you must pick a path first, and picking wrong hurts.
Art-first — for visually driven, simple-玩法 games (fishing, match-3, idle). Generate a concept image that looks like a shipped screenshot, reverse-engineer rules/interaction/feedback rhythm from it, then build a clickable prototype in Cocos aimed at reproducing that image. Visual direction locks on day one; everything afterward orbits "reproduce it." Trap:沉迷于 making the image pretty and never reaching playable. Countermeasure: a hard deadline — clickable prototype within two weeks of concept lock.
Logic-first — for rule-driven games (tower defense, strategy, roguelike). Don't touch art at all. Represent the map as a 2D array, enemies and towers as colored blocks; get pathfinding, attack ranges, wave curves, economy, skill chains working. Only skin it once the MVP is fun. Iteration cost is near-zero — changing a number takes seconds — and once the logic frame locks, art production can run in parallel without fear of rework. Trap: stopping too early at "good enough," since pure whitebox hides the final feel. Countermeasure: one small "art injection" verification immediately after logic lock, even with placeholders.
Hybrid (the hidden third) — logic skeleton and art placeholders advance in parallel, meet once mid-stream for alignment, then各自完善. My deep-sea prototype took this road: V01–V04 logic-led, art window joined at V04, the two ran in parallel and closed at V07.
GT's mainline content reads strongly logic-first to me, while characters, skins, and event visuals lean heavily art-first. Which is why I suspect what you actually want is both paths running under one command structure, not a choice between them.
14. On the Narrative-Design Opening
Seeing that role listed made me want to say something carefully. Story is the most overrated and most underrated part of this whole setup.
Overrated, because people think "AI writes stories" means type a prompt and wait for a masterpiece. Underrated, because it's arguably the highest-return application of this paradigm — provided you're willing to do the boring work first: build the knowledge base.
If I were doing it, I'd feed the story window five things before any creative dispatch:
• Character cards — identity, motive, personality keywords, speech habits (catchphrases, sentence length, honorific usage), ability specs, relationships, major events that have happened
• Timeline — released story in order, tagged主线/支线/event-limited
• Relationship graph — alliance, opposition, mentor, blood, one-sided fixation, with starting nodes
• Glossary — locked spellings for world nouns, place names, org names, skill names. Trivial-looking, and the single most effective guard against "this doesn't feel like GT."
• Taboo list — settings that must not be touched, facts that must not be rewritten, character floors that must not break
Then dispatch with constraints: "New character X's entrance scene must echo character Y's chapter-3 side branch; emotional tone keeps the humor-with-tears register; no new world-building that conflicts with the existing timeline; X must not use honorifics in dialogue (see character card item 4)."
And three anti-drift guards: citation required at key setting points (character-card number or timeline node), anything new without a source flagged red for review; conflict diff against the taboo list and established fact on every delivery, hit means reject; human final pass — AI does first draft and consistency checking only, emotional landing and pacing stay with the writer.
I don't think adding writers is a bad sign at all. For a live-service game it's normal, even healthy. I just think if there's an assistant shouldering first drafts and consistency checks, human writers get more time for the things that actually need humans — emotional landing, pacing, the lines players remember three years later.
15. One Necessary Clarification
Everything described here runs locally, uses no company confidential material, involves no reproduction of GT official assets, and exists solely as personal ideation and pipeline stress-testing. All prototypes and renders mentioned are my own original content, available for inspection.
Closing
The detailed V01–V07 iteration record is attached; I kept the body short so as not to take up your time.
This has only ever run in a one-person project, at a scale far below GT's and untested in a team environment, so I won't claim it maps cleanly onto your pipeline. But if any of it offers a useful angle on coordination cost — or if you're exploring AI-assisted production and would like a short demo — I'd be glad to show it. Demo build and iteration log are both attached.
Either way, thank you for reading this far. May Guardian Tales always have a new story to tell.
Sincerely,
Luoyu(contact info)
AttachmentsA. Deep-sea TD prototype iteration record V01–V07 (per-round problem定位 / 修改指令 / 验收结果)B. Role window roster + responsibility boundariesC. Dispatch prompt template (目标/硬约束/参考/验收清单) + negation-list notesD. Reply templateE. Art-first vs. logic-first comparisonF. Story-window knowledge-base structure + citation & conflict-diff mechanism

thank you

[가디언 테일즈]

안녕하세요. 洛雨 기사님

보내주신 소중한 의견은 담당 부서로 전달하여
꼼꼼히 검토할 수 있도록 하겠습니다.

감사합니다.