{"slug": "building-a-three-js-game-with-and-without-githits", "title": "Building a Three.js Game With and Without GitHits", "summary": "GitHits, a coding tool that provides context from real GitHub implementations, enabled an AI agent to build a more playable Three.js game inspired by The Legend of Zelda: The Wind Waker compared to an agent without it, according to a blog post by GitHits. The experiment ran the same model and prompt twice, with only the GitHits context layer as the difference, and the GitHits version produced a more polished game.", "body_md": "[Back to blog](/blog/)\n\nAugust 17, 2026 · 8 min read\n\n# Building a Three.js Game With and Without GitHits\n\nWe ran the same model and the same prompt twice to build a Three.js game — one agent with GitHits, one without. Here is how far each got.\n\nSocial media has been flooded with AI coding demos where people recreate famous video games, like “Call of Duty”, from a single prompt. So we decided to try it ourselves.\n\nWe ran two coding sessions side by side using the exact same model and the exact same prompt. The challenge was to build a Three.js game inspired by The Legend of Zelda: The Wind Waker.\n\nThere was only one difference: one agent could use GitHits throughout the project to get context from real implementations, and the other couldn’t.\n\nOur hypothesis was that the GitHits version should lead to a more playable game.\n\n### Original Prompt with GitHits as Context Layer\n\n```\nI want you to recreate The Legend of Zelda: Wind Waker as a modern browser game in Three.js.\n\nThis should be an original fan tribute inspired by Wind Waker, not a direct copy. Do not use\nNintendo assets, models, textures, music, dialogue, or logos. Create original equivalents that\nimmediately evoke the same feeling, and use the GitHits color palette as the primary art direction.\n\nUse this GitHits color palette:\nPrimary:   #ffb8de, #ff95ce, #ff72be, #ff4fae, #cc3f8b, #992f68, #651f45\nSecondary: #fde3d0, #fcc8a1, #faac72, #ff872f, #ba6c33, #7c4822, #3e2411\nNeutral:   #ffffff, #d5d9df, #abb2bf, #72767f, #4a4e56, #21262d, #13161a\n\nIt should capture everything people love about Wind Waker: the expressive cel-shaded visuals, the\nocean, sailing, exploration, combat, animation quality, lighting, atmosphere, camera feel, game\nfeel, and polish.\n\nFan out sub-agents using clear roles:\n- Planner agents should research the best approach for each major system, define the implementation\n  strategy, identify relevant packages and APIs, and break the work into concrete tasks.\n- Worker agents should implement those plans.\n- Reviewer agents should critically inspect the result for visual quality, gameplay, UX,\n  correctness, architecture, and performance, then send concrete fixes back to the Workers.\n\nUse /loop so Planner -> Worker -> Reviewer cycles continue until the major systems are polished and\nthe reviewers are satisfied with the result.\n\nDo this entirely in Three.js. Don't stop at a prototype. Build something that looks and feels like a\nreal modern game.\n\nOperate autonomously from start to finish.\nDo not ask me for clarification, confirmation, approval, or permission during the process. When\nsomething is ambiguous, make the most reasonable decision yourself and keep moving.\nPlanner agents should make decisions and produce actionable plans without waiting for user input.\nWorker agents should execute those plans immediately. Reviewer agents should identify issues and\nsend fixes directly back into the next iteration.\nIf a task fails, debug it and try an alternative approach. If there are multiple valid options,\nchoose the one that best supports visual quality, performance, UX, and maintainability.\nKeep iterating through Planner -> Worker -> Reviewer loops until the game is complete, polished, and\nrunnable. Only stop when you have reached the best result you can produce with the available tools\nand environment.\n\nGitHits usage is mandatory throughout the project.\nEvery Planner agent must use GitHits before proposing an implementation plan for any significant\nsystem. They must actively call the relevant GitHits tools to research real-world implementations,\ncompare approaches, inspect packages and APIs, verify current usage patterns, and find\nproduction-quality code from public GitHub repositories. Plans should be grounded in what GitHits\nreturns, not primarily in internal model knowledge.\nEvery Reviewer agent must also use GitHits when evaluating significant technical decisions or\nimplementations. Reviewers should compare the implementation against real-world patterns found\nthrough GitHits, identify weak or outdated approaches, and use GitHits again when proposing\ncorrections or optimizations.\nWorkers should use GitHits whenever they need implementation details, examples, package information,\nAPI usage, debugging guidance, or optimization patterns.\nDo not treat GitHits as optional research. Do not skip GitHits because you already know how to\nimplement something. For every major system, use GitHits first, then reason from the retrieved\nevidence.\nUse whichever GitHits tools are appropriate for the task, including architecture research, package\nevaluation, API discovery, production code retrieval, implementation grounding, debugging, and\noptimization.\n```\n\n## Two different processes\n\nOne of the first things we noticed was how differently the two agents approached the problem.\n\nThe agent using GitHits looked at how difficult systems like collision, rendering, shaders, water, and physics were actually implemented in real Three.js projects, and used that information to make its own implementation decisions.\n\nThe agent without GitHits mostly reasoned from what the game needed:\n\nI need an island.\n\nI need collision.\n\nI need combat.\n\nI need a boat.\n\nI need enemies.\n\nThen it came up with its own implementations for those systems.\n\nIt also started showing a browser preview much faster. At first, that looked like faster progress. But a lot of that time was then spent running smoke tests, finding bugs, and rewriting things that weren’t working as expected. There was a lot more guessing, testing, and iterating.\n\nThe agent using GitHits seemed more confident about what it was doing. It asked fewer questions and needed less human interaction to keep moving.\n\nWhenever either agent stopped and asked what to do, our answer was basically the same: do what you think is best, keep going. We weren’t there to help them build the game. We wanted to see how far they could get from the original prompt.\n\n## GitHits wasn’t just used for code snippets\n\nThis was also interesting to see in the GitHits activity. During the session, the agent made hundreds of GitHits calls to navigate real code, find examples, inspect packages, understand Three.js internals, and investigate specific implementation problems as they came up.\n\nThere were searches around toon shading, water rendering, waves, shader injection, collision systems, and other Three.js problems.\n\nOne good example was character collision. The agent researched three-mesh-bvh and real character movement implementations using patterns like `shapecast`\n\nand `closestPointToSegment`\n\n. Those patterns later showed up in the actual `PlayerController`\n\narchitecture.\n\nYou can see the [entire session here](https://githits.com/s/three-js-shader-and-geometry-investigation-RqpbRwX8miGoSEf40ZFSRw).\n\n## So, what did we get?\n\nNeither session actually finished. We eventually paused both after several hours. So this isn’t a comparison between two finished games. It’s a comparison of how far each agent got while working autonomously from that original prompt.\n\nAnd the difference was clear.\n\n### Without GitHits\n\nThe version without GitHits looks more blocky and low-poly. The character can move, jump, and roll, but the gameplay doesn’t go much further than that.\n\nWe couldn’t collect the gems. There were no working controls for attacking or charging. We couldn’t access the boat, so the player was basically stuck on the first island.\n\nThe character also didn’t follow the terrain correctly and would sometimes partially disappear into the ground. The physics felt strange too, with characters sometimes moving more like puppets or solid blocks. The menu was there, but its options weren’t functional yet, and there were also issues with sound and music getting stuck.\n\nThat said, there were some things we liked. We actually preferred some of the color choices in this version.\n\n### With GitHits\n\nThe GitHits version was noticeably more playable.\n\nThe graphics were smoother and less blocky, although the overall color palette ended up a little too dark. More importantly, the systems worked together much better.\n\nThe character followed the terrain correctly. We could jump, roll, attack, charge, and collect diamonds. When approaching something like a chest or a pot, the game showed an interaction prompt such as “Smash”, including the key we needed to press.\n\nWe could also access the boat and navigate between islands. The character physics felt considerably better, and the overall performance was better too. Even the menu was further along: we could open it, see the map, and actually use parts of it.\n\nIt was still buggy. There were still collision problems and unfinished systems. But we could actually play it.\n\n## The takeaway\n\nNeither version blew us away visually. The UI and graphics weren’t great in either one. Both games were unfinished. Both had bugs. And obviously, this is one experiment, not a benchmark.\n\nBut when we actually played the games, the difference was pretty clear. The version without GitHits still felt like something that needed significant work before we could really start iterating on the game.\n\nWith the same prompt, the agent using GitHits made better technical and architectural decisions, needed less human interaction, and got considerably further toward something we could actually play. Better physics. Better performance. More working mechanics.\n\nThe GitHits version was also far from finished, but it was definitely something we could use as a starting point to keep iterating.", "url": "https://wpnews.pro/news/building-a-three-js-game-with-and-without-githits", "canonical_source": "https://githits.com/blog/three-js-game-with-and-without-githits/", "published_at": "2026-08-17 00:00:00+00:00", "updated_at": "2026-08-18 13:43:00.728087+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "generative-ai"], "entities": ["GitHits", "Three.js", "The Legend of Zelda: The Wind Waker"], "alternates": {"html": "https://wpnews.pro/news/building-a-three-js-game-with-and-without-githits", "markdown": "https://wpnews.pro/news/building-a-three-js-game-with-and-without-githits.md", "text": "https://wpnews.pro/news/building-a-three-js-game-with-and-without-githits.txt", "jsonld": "https://wpnews.pro/news/building-a-three-js-game-with-and-without-githits.jsonld"}}