Building a Three.js Game With and Without GitHits

Social 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.

We 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.

There was only one difference: one agent could use GitHits throughout the project to get context from real implementations, and the other couldn’t.

Our hypothesis was that the GitHits version should lead to a more playable game.

Original Prompt with GitHits as Context Layer

I want you to recreate The Legend of Zelda: Wind Waker as a modern browser game in Three.js.

This should be an original fan tribute inspired by Wind Waker, not a direct copy. Do not use
Nintendo assets, models, textures, music, dialogue, or logos. Create original equivalents that
immediately evoke the same feeling, and use the GitHits color palette as the primary art direction.

Use this GitHits color palette:
Primary:   #ffb8de, #ff95ce, #ff72be, #ff4fae, #cc3f8b, #992f68, #651f45
Secondary: #fde3d0, #fcc8a1, #faac72, #ff872f, #ba6c33, #7c4822, #3e2411
Neutral:   #ffffff, #d5d9df, #abb2bf, #72767f, #4a4e56, #21262d, #13161a

It should capture everything people love about Wind Waker: the expressive cel-shaded visuals, the
ocean, sailing, exploration, combat, animation quality, lighting, atmosphere, camera feel, game
feel, and polish.

Fan out sub-agents using clear roles:
- Planner agents should research the best approach for each major system, define the implementation
  strategy, identify relevant packages and APIs, and break the work into concrete tasks.
- Worker agents should implement those plans.
- Reviewer agents should critically inspect the result for visual quality, gameplay, UX,
  correctness, architecture, and performance, then send concrete fixes back to the Workers.

Use /loop so Planner -> Worker -> Reviewer cycles continue until the major systems are polished and
the reviewers are satisfied with the result.

Do this entirely in Three.js. Don't stop at a prototype. Build something that looks and feels like a
real modern game.

Operate autonomously from start to finish.
Do not ask me for clarification, confirmation, approval, or permission during the process. When
something is ambiguous, make the most reasonable decision yourself and keep moving.
Planner agents should make decisions and produce actionable plans without waiting for user input.
Worker agents should execute those plans immediately. Reviewer agents should identify issues and
send fixes directly back into the next iteration.
If a task fails, debug it and try an alternative approach. If there are multiple valid options,
choose the one that best supports visual quality, performance, UX, and maintainability.
Keep iterating through Planner -> Worker -> Reviewer loops until the game is complete, polished, and
runnable. Only stop when you have reached the best result you can produce with the available tools
and environment.

GitHits usage is mandatory throughout the project.
Every Planner agent must use GitHits before proposing an implementation plan for any significant
system. They must actively call the relevant GitHits tools to research real-world implementations,
compare approaches, inspect packages and APIs, verify current usage patterns, and find
production-quality code from public GitHub repositories. Plans should be grounded in what GitHits
returns, not primarily in internal model knowledge.
Every Reviewer agent must also use GitHits when evaluating significant technical decisions or
implementations. Reviewers should compare the implementation against real-world patterns found
through GitHits, identify weak or outdated approaches, and use GitHits again when proposing
corrections or optimizations.
Workers should use GitHits whenever they need implementation details, examples, package information,
API usage, debugging guidance, or optimization patterns.
Do not treat GitHits as optional research. Do not skip GitHits because you already know how to
implement something. For every major system, use GitHits first, then reason from the retrieved
evidence.
Use whichever GitHits tools are appropriate for the task, including architecture research, package
evaluation, API discovery, production code retrieval, implementation grounding, debugging, and
optimization.

Two different processes

One of the first things we noticed was how differently the two agents approached the problem.

The 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.

The agent without GitHits mostly reasoned from what the game needed:

I need an island.
I need collision.
I need combat.
I need a boat.
I need enemies.

Then it came up with its own implementations for those systems.

It 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.

The agent using GitHits seemed more confident about what it was doing. It asked fewer questions and needed less human interaction to keep moving.

Whenever 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.

GitHits wasn’t just used for code snippets

This 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.

There were searches around toon shading, water rendering, waves, shader injection, collision systems, and other Three.js problems.

One good example was character collision. The agent researched three-mesh-bvh and real character movement implementations using patterns like shapecast and closestPointToSegment. Those patterns later showed up in the actual PlayerController architecture.

You can see the entire session here.

So, what did we get?

Neither 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.

And the difference was clear.

Without GitHits

The 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.

We 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.

The 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.

That said, there were some things we liked. We actually preferred some of the color choices in this version.

With GitHits

The GitHits version was noticeably more playable.

The 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.

The 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.

We 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.

It was still buggy. There were still collision problems and unfinished systems. But we could actually play it.

The takeaway

Neither 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.

But 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.

With 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.

The GitHits version was also far from finished, but it was definitely something we could use as a starting point to keep iterating.