AI-Assisted Indie Dev: Week 10 Fishing Game Devlog & Multi-Session Workflow Revealed

An indie developer shared their Week 10 progress on Reddit building a fishing game with AI assistance, finally releasing a free downloadable demo. Beyond documenting the game's refinement, this devlog stands out for openly sharing a mature AI collaboration workflow and a real cost breakdown — making it a genuinely useful reference for anyone serious about using AI on long-term projects.

What Happened in Week 10: Polish Across Mechanics and Visuals

With the demo release approaching, the developer poured most of their energy into detail work. Key changes included:

Foam effects around the boat and hull were upgraded from flat texture decals on the water surface to properly simulated waves and water, with minimal performance overhead. This was one of the most visible visual improvements — replacing textures with simulation usually means higher realism, and keeping the performance cost low shows a disciplined implementation approach.

Other updates included UI texture improvements for the "refit" and "ship" pages, an overall visual overhaul of the port (new tree models, adjusted sun position for better shadows, shadow bug fixes, 3D model additions and removals), and a full redo of the "big wave" mechanic visuals during storms — the developer admitted the previous big wave effect was "far below the quality of the rest of the game" and had to be rebuilt from scratch.

The developer self-deprecatingly referred to bug fixes as part of the "AI slop" — an honesty that feels refreshingly genuine in today's AI development discourse.

The Real Highlights: Decision Tracing and Multi-Session Management

The genuine value of this devlog lies in the author's openly shared AI collaboration methodology.

Using decisions.md to Fight AI Hallucinations

The developer maintains a set of .md files, with decisions.md being the most critical. Every game design decision is tagged with either [USER] or [AI] to distinguish whether a call was made by the human or the AI. The rule is simple: [USER] tags always take precedence over [AI] tags.

This approach solves a real pain point — AI occasionally "gaslights" developers by insisting a certain decision was the user's call when it wasn't. Structurally documenting decision origins essentially gives the project a traceable "design constitution," preventing both AI hallucinations and the slow drift of design intent across months of conversation.

"AI hallucination" in long-term projects has a particularly tricky variant: the model isn't fabricating facts out of thin air, but rather incorrectly "remembers" decision attribution across repeated conversations — misattributing AI-proposed solutions as the user's original instructions. This relates to how large language models handle context: when conversation history grows long and gets compressed (compacted) or truncated, the model's tracking of "who said what" degrades significantly. A structured decisions.md is essentially an externally maintained decision log that doesn't rely on the model's own memory, bypassing this architectural flaw. The pattern isn't unfamiliar in software engineering — Architecture Decision Records (ADRs) use the same logic to document the rationale behind technical decisions, though decisions.md adds an extra dimension by tagging the decision-maker.

Multi-Session + Manager Architecture

Rather than cramming everything into a single conversation, the developer opens a separate session for each game system — a fishing session, a quests session, a shaders session, and so on — plus one dedicated "Manager session."

The workflow resembles a small team: the developer is the "boss," the Manager is the "right hand," and the Manager is responsible for dispatching tasks to each sub-session, with each sub-session staying focused on its own system. The developer only talks to the Manager day-to-day, rather than tracking a dozen open windows simultaneously.

The concrete benefits of this architecture:

• Drastically reduces context compacting. If all work happens in one session, context gets compressed every few hours and information is lost. After splitting, sub-sessions almost never hit compression limits.
• Allocate compute by task difficulty. Different systems can be assigned different "effort" levels — the quests session might run at medium, while the harder shaders session gets cranked to maximum (the author calls this Ultracode).
• Lower cognitive overhead. You only need to communicate with one session instead of juggling a dozen windows.

This "manager-executor" multi-agent division is essentially the developer manually implementing a lightweight multi-agent orchestration system at the user level — highly practical for individuals maintaining complex projects over time.

Context compacting is a real limitation of today's mainstream large language models: every session has a finite context window, and when accumulated conversation content approaches the limit, the model or platform automatically summarizes earlier content to make room for new input. This process causes information loss — details, edge cases, and implicit constraints often get lost in compression, leading the model to give advice that contradicts earlier decisions. Although Claude's paid plans (like Claude Max) offer larger context windows, a single long-running session still can't avoid compacting over a development cycle spanning weeks. By splitting sessions per system, each sub-session only needs to maintain context for its own module, dramatically reducing compression frequency and containing information loss to individual modules without affecting overall project consistency. Architecturally, this mirrors the "separation of concerns" principle in microservices — distributing the pressure of state management.

Real Toolstack and Cost Breakdown

The author clearly listed the tools used and their actual two-month spending — this kind of transparent data is rare in the community.

Tool Stack:

• Code: Claude Opus (maximum mode) handles all programming
• 3D models: Blender MCP (driven by Claude) or TripoAI
• Engine integration: Godot MCP (using the free Beckett version, though less used via MCP recently)
• Backup / all-in-one tasks: Codex (used when Claude quota runs out, or for bundled tasks like "generate texture and implement it" — usually by having Claude communicate with Codex)
• Sound effects: ElevenLabs
• Music: Stable Audio

Two-Month Cost Breakdown:

Item	Cost
Claude Max plan × 3 ($200/each)	$600
Codex $100 plan × 1	$100
ElevenLabs sound effect credits	$10
Stable Audio music generation	$15
TripoAI credits	$20
Miscellaneous	$50–70
Total	~$800

At $800 over two months, the bulk goes toward three Claude Max subscriptions. This number is a rare anchor for estimating "how much does AI-assisted indie development actually cost" — it demonstrates that AI-driven game development is far from a free lunch, while also showing that compared to traditional outsourcing for art, audio, and programming, this scale remains something an individual developer can afford.

MCP (Model Context Protocol) is an open protocol released by Anthropic in late 2024 that allows large language models to interact with external tools, data sources, and applications through a standardized interface. The Blender MCP and Godot MCP mentioned in this devlog are both built on this protocol, enabling Claude to send operation commands directly to 3D modeling software Blender or game engine Godot — realizing a "drive tools with natural language" workflow. This is fundamentally different from the traditional approach of "have AI generate code, then manually paste and execute." MCP establishes a persistent bidirectional communication channel: the model can execute actions, read feedback, and adjust the next instruction based on results, forming a complete Action-Observation loop. For indie developers, this means the previously manual "AI output → tool input" handoff can be automated, significantly reducing the friction of repetitive operations.

Why This Devlog Is Worth Your Time

Setting the game aside, what the author is really demonstrating is a replicable personal AI development methodology: use structured Markdown documents to lock in decisions, use multi-session isolation to manage context, allocate compute by task difficulty, and let AIs communicate with each other to reduce manual overhead. These lessons are worth borrowing for anyone looking to upgrade AI from a "coding toy" to a "long-term project productivity tool."

Notably, the author also mentioned someone spotted the game on X (Twitter), but the developer themselves had only reactivated their old account two days prior — a sign the project is already gaining organic community traction. The demo is currently available for free on itch.io, and the developer welcomes playtesting and feedback.

For readers following AI-assisted creation, these first-person devlogs with real costs and hard-won lessons consistently carry more information density than vendor demo reels.