🎯 Project Overview — A Solo Photoreal Survival Game Built with AI-Assisted Development

Day of the Forest is a first-person photoreal survival project being developed solo in Unreal Engine. I started with no professional game-development or programming background and use AI not as a simple code generator, but as a development pipeline for design, research, implementation, debugging, and verification. The project integrates a large open world, photoreal environments, MetaHuman characters, AI, survival systems, combat, inventory, building, interaction, and animation into one playable game.

AI-Assisted Development Pipeline

Instead of explaining the entire project to the AI from scratch every time, I built persistent project memory and verification procedures into the development workflow itself. CLAUDE.md stores operating rules and protected invariants, while GameDesignDoc.md records real problems, causes, fixes, results, and failed approaches. Before modifying anything, the AI checks prior decisions and the current project state, traces vendor or official documentation when necessary, and only then makes changes. Final judgment comes from actual Play testing, and confirmed results are written back into the project's long-term knowledge base.

Symptom / Requirement → Search Past Records → Measure Current Code & Assets → Identify Root Cause → Minimal Fix → Play Verification → Update Project Memory

For long-running agent work, facts are separated into OBSERVED (directly seen in-game), MEASURED (confirmed through logs or runtime values), and INFERRED (evidence-based reasoning) so assumptions do not silently become facts. scratchpad/STATE_*.md files are used as task-specific checkpoints, preserving confirmed values, eliminated causes, failed paths, current changes, and the next investigation point so work can resume after context compaction. Solved issues are promoted into GameDesignDoc.md, while invariants and protected rules in CLAUDE.md prevent regressions and repeated failures. The goal is to compensate for AI weaknesses such as context loss, hallucination, scope drift, and repeated failure through external memory, measurement, checkpoints, and human Play verification.

Agentic Development Operating System

AI usage in this project is not just prompt writing. It is structured as an operating system for long-term agentic development, designed to control the weaknesses of AI agents over extended production work.

1. Behavioral Policy — Defines investigation, modification, reporting, and prohibited actions so the agent operates within a fixed development discipline.
2. Epistemic Framework — Separates evidence levels such as OBSERVED, MEASURED, and INFERRED so speculation cannot quietly become accepted fact.
3. Context Engineering — Connects the current symptom, previous decisions, vendor architecture, and protected invariants at the moment they are needed.
4. External Memory — Stores problems, root causes, failed paths, and confirmed fixes in GameDesignDoc.md so the same investigation cost is not paid repeatedly.
5. State Persistence — Uses scratchpad/STATE_*.md as checkpoints to preserve confirmed values, UNKNOWNs, eliminated causes, current state, and next steps across context compaction.
6. Escalation Policy — If evidence-based hypotheses repeatedly fail, speculation stops. The system compares against known-good vendor behavior and increases investigation resolution down to DataTable rows, references, function calls, and final runtime consumption points when necessary.
7. Human-in-the-loop Ground Truth — Automated tests and logs are evidence, but final visual and gameplay judgment is made by a human during actual Play testing and then written back into long-term project memory.

The purpose of this structure is to stop the AI from repeating the same failures or overwriting project-specific reality with generic assumptions, while systematically reducing context loss, hallucination, scope drift, and repeated failure. The longer development continues, the more project-specific verified knowledge accumulates.

Commercial Asset Integration Became More Like Reverse Engineering Than Assembly

At first, I expected finished commercial assets to be relatively easy to connect. In practice, every vendor system came with different assumptions about characters, skeletons, AnimBPs, cameras, input, collision, data ownership, and component architecture, so simple plug-and-play integration was rarely enough.

Changing one connection could trigger chain reactions across every kind of asset and system integrated into the project — including aiming, animation, IK, locomotion, weather, ocean, small-animal systems, and many others — and some integration bugs took more than 20 hours just to isolate their root cause. The real task was not to rebuild vendor features from scratch, but to reverse-trace each vendor's Blueprint, C++, animation, and data flow, understand the original causal structure, and find integration points that preserve it.

Commercial assets dramatically reduce raw production time, but the core work behind the final result is reverse-engineering multiple independent systems, resolving their conflicts, and integrating them into a single coherent game architecture.