Inspiration
Most AI interfaces are still built around the same pattern: a human asks, and an AI answers.
I wanted to explore a different relationship.
What if the human and the AI shared the same visual world, but each had different abilities? What if the AI was not an assistant, NPC, or game master, but an actual player?
That idea became AI Watermelon Smash.
The human can see the beach, obstacles, and watermelon. The AI character is blindfolded, but WebMCP gives it a body inside the browser.
The human has the eyes.
The AI has the body.
Neither can win alone.
What it does
AI Watermelon Smash is an asymmetric Human + AI co-op browser game.
The AI can use five WebMCP Site tools:
turn(degrees)for orientationwalk(distance)for movementswing()for its armget_self_status()for proprioceptionlisten_to_guides()for social perception
The tools intentionally do not provide the watermelon coordinates, target direction, obstacle map, shortest path, or which guide is correct.
Instead, humans give natural-language guidance such as:
“A little to the right.”
“Careful, there is a rock.”
“Now swing!”
The AI decides how to act.
Guide Chorus adds another layer: three human voices, A, B, and C, can give conflicting advice. Their messages are returned to the AI only as unverified testimony.
A collision can become evidence. A previously reliable guide can become suspicious. The AI can change whom it trusts, ask for clearer information, take a cautious step, or choose to swing.
The design principle became:
Physical clarity, social ambiguity.
How I built it
The game is built with TypeScript, Vite, Three.js, DOM UI, and the imperative WebMCP API using document.modelContext.registerTool().
The gameplay simulation is kept separate from Three.js.
GameState owns the actual gameplay state, while SceneView is only the visual representation. WebMCP tools call the same Game API used by the debug controls, so there is no separate agent-only version of the game.
Guide Chorus uses a bounded message store. listen_to_guides() is read-only and returns recent A/B/C statements with sequence information.
Tool outputs are intentionally minimized for the blindfolded role. They do not expose target coordinates, target direction, target distance, obstacle truth, guide truth labels, or route hints.
The final game is deployed as static assets on Cloudflare Workers.
Challenges
The hardest problem was not implementing movement.
It was deciding what the AI should and should not know.
If the tools revealed too much, the AI could simply solve the board. If the controls were intentionally confusing, the difficulty felt artificial.
That led to an important rule:
Make the body clear. Make the information uncertain.
I fixed the character's facing direction and swing so physical actions were unambiguous. Then I moved the uncertainty into human guidance.
Another challenge appeared during playtesting: with only one helpful human, the AI could start to feel like a natural-language remote-controlled character.
Guide Chorus changed that.
Once humans could disagree, the AI had to make meaningful decisions about trust rather than simply execute commands.
Accomplishments that I'm proud of
The most exciting moment came during a real ChatGPT playtest.
The AI followed advice that had previously been safe, collided with an obstacle, and then changed how much it trusted that guide.
Later, it rejected suspicious guidance, switched between different guides, followed a concrete final instruction, and successfully smashed the watermelon.
The final result was:
“Direct hit! We smashed the watermelon together.”
At that point, WebMCP was no longer just controlling a character.
It was giving the AI experiences that affected later decisions.
What I learned
I expected the interesting uncertainty to be spatial:
“Where is the watermelon?”
Instead, the more interesting question became social:
“Which human should I believe?”
A collision is not just collision feedback. It can become evidence about a person's advice.
That suggested a broader possibility for WebMCP:
Web tools can represent an agent's body and senses, not just functions for completing tasks.
The most interesting interaction appeared when the AI started asking humans to describe directions relative to its own current heading.
The human had visual information.
The AI had body-state information.
They had to exchange both to coordinate.
What's next
A future version could connect several real human devices instead of entering A/B/C messages on one screen.
Each human could have a different viewpoint, imperfect information, or different incentives. Lying could be possible without requiring a fixed “traitor” role.
The AI would become an embodied participant inside a small human social system.
The larger idea I want to explore is simple:
We are not adding AI to a game. We are designing games for humans and AI to play together.
Log in or sign up for Devpost to join the conversation.