If you want to build a game like this, you do not need to know every technical detail before you begin. You need a clear idea, a reference for the feeling you want, and a way to break the work into pieces. Start with references. They can be screenshots, concept art, videos, another game, or even a rough drawing. If you do not have any, explain the idea in plain language to an LLM: what the game looks like, what the player does, what should feel satisfying, and what you definitely do not want. Then ask the LLM to turn that rough idea into one detailed master prompt for your coding agent. It should include the art direction, gameplay loop, technical stack, controls, systems, dependencies, edge cases, tests, acceptance criteria and a clear definition of “done.” A coding agent works much better from this than from a vague request like “make me a stickman style fps game.” Define the orchestration inside that first prompt too. Tell the main coding agent to act as the lead: keep the overall plan, split the game into independent systems, and give each system to a builder subagent. For this game those systems included the world and map, movement and collision, weapons, enemy AI, mission flow, animation, audio, effects and UI. After each builder finishes, the lead should start a separate verifier subagent. The verifier must inspect the changes, run the relevant tests and browser checks, and compare the result with that task’s acceptance criteria. If it finds a problem, its feedback goes back to the builder. The builder fixes it, then the verifier checks again. Only after it passes should the lead integrate that system and move to the next task. Put that builder → verifier → fix → verify loop in the first prompt once. You should not need to manually tell the agent to create a verifier after every task; the lead agent should follow the loop automatically throughout the build. Use visual references when words stop being useful. Most of my buildings and props were created directly in code, but for the military vehicle I gave the agent a blueprint-style image. That worked better than repeatedly trying to describe its shape. If an object is too complex to model, use a specialized image-to-3D model through a service such as @fal, @MeshyAI, or a similar tool. A quick credit: Project I.G.I. 1 (2000) inspired parts of the map, and I used some of its sounds as a nostalgic callback. Full credit to the original game and its rights holders. They do not fully fit the ink-and-paper style, so I may eventually replace them with something more stylized. For animations, build a separate playground first. I used one to test walking, running, weapon poses, firing, reloading, hit reactions and deaths without having to play the full mission every time. Once an animation felt right, I moved it into the game. The same character rig now powers the enemies and the hostage. When the game works, add game feel. Recoil, bullet trails, impact marks, hit direction, blood, weapon cycling, camera movement and audio are not random decoration. Each one should tell the player something: did I fire, did I hit, where is the danger, and what happened next? Finally, play the game yourself. AI can build a playable version, but it cannot decide what feels good for you. Notice where movement feels stiff, feedback is unclear, an animation looks wrong, or a moment feels empty. Explain that specific problem to the agent, make a change, test it again, and keep iterating. That was my real workflow: define the feeling, create a plan, split the work, verify each part, test difficult systems in isolation, add game feel, then play and refine. GPT Astra handled most of the game, while Fable helped me push the animations further. You do not need to solve the whole game at once. If you can describe the feeling, break it into small pieces and keep testing, you can build much more than you think.