/signal

A Co-op Game Where Player 2 Is AI

Comment

/signal — Player 2 Is an AI

Most AI products are designed around the same interaction:

You give the AI a task, and the AI does it for you.

While looking at WebMCP, I became much more interested in a different question:

What if the AI was not your assistant, but another player?

That idea became /signal, an asymmetric co-op browser game where the human and an AI agent have different information, different capabilities, and genuinely need each other to finish the mission.

The core rule is simple:

You see things it can't.
It knows things you don't.
Work together.

Inspiration

The thing that interested me most about WebMCP was not simply letting an agent click fewer buttons or fill forms faster.

It was the possibility of building software where the human interface and the agent interface are intentionally different.

Traditional games already use asymmetric co-op mechanics: one player might see a map while another has the instruction manual, and the fun comes from communicating.

I wanted to see what that would look like when Player 2 is an AI agent connected through WebMCP.

Instead of giving ChatGPT access to everything, /signal deliberately hides some information from it.

And instead of putting everything in the visual interface, some diagnostics, manuals, simulations, and actions are available only to the AI player.

Neither side gets the full puzzle.

What it does

The player is placed inside a failing remote research station called SIGNAL-9.

Four systems must be restored:

  1. Power
  2. Cooling
  3. Navigation
  4. Signal

The human plays the role of Field Ops through the visual browser interface.

The AI plays Systems through WebMCP.

Power

The human can see a visual phase symbol and operate physical breakers.

The AI can read power diagnostics and access the operating manual, but it cannot see the phase symbol.

The human has to tell the AI what they see.

The AI interprets that information using its manual and tells the human which breakers to activate.

Cooling

The human can inspect coolant colors and physically configure the valves.

The AI knows the compatibility rules and can run a simulation of the proposed configuration.

Even after the human configures everything correctly, the system cannot be restored until the AI player authorizes the pump through WebMCP.

Navigation

The human sees and interacts with a visual navigation field.

The AI has access to hidden navigation constraints, hazard coordinates, destination information, and the fuel budget.

They have to communicate to build a safe route together.

The human plots it.

The AI validates and uploads it.

Signal

The final system transmits a visual sequence that only the human can observe.

The AI has access to the decoding rules.

The human describes the sequence, the AI decodes it, the human configures the transmitter, and the AI performs the final Systems authorization.

If both players did their jobs correctly:

SIGNAL RESTORED.

How I built it

/signal is built as a fully interactive browser game using:

  • Next.js
  • React
  • TypeScript
  • Tailwind CSS
  • WebMCP
  • localStorage
  • procedural HTML, CSS, and SVG graphics

I intentionally avoided using an AI API inside the game.

ChatGPT itself is already the reasoning engine.

The game's responsibility is to provide:

  • trusted mission state
  • structured diagnostics
  • operating manuals
  • simulations
  • system rules
  • state-changing actions

through WebMCP.

The human-facing UI and the agent-facing tools interact with the same underlying game state.

The AI can use WebMCP tools to inspect diagnostics, access manuals, run simulations, read event history, and perform Systems-only actions.

Information asymmetry

One of the most important parts of the implementation was making sure WebMCP wasn't simply another way to expose everything already visible on the page.

I created separate human-facing and agent-facing information boundaries.

For example:

Human-only information includes:

  • visual phase symbols
  • coolant appearance
  • visual navigation markers
  • the final signal pattern

Agent-only information includes:

  • operating manuals
  • system diagnostics
  • hidden navigation hazards
  • decoding rules
  • certain authorization actions

This makes communication an actual game mechanic.

If the AI could retrieve the visual answer through WebMCP, there would be no reason for the human player.

If the human could see the Systems manual directly, there would be no reason for Player 2.

Why WebMCP matters

Without WebMCP, ChatGPT would just be sitting outside the game giving generic advice.

With WebMCP, the AI becomes part of the game's state machine.

It can:

  • inspect the current system
  • retrieve information unavailable to the human
  • react to actions the human takes
  • test proposed configurations
  • perform actions that the human cannot
  • help move the mission forward

The interaction becomes:

Human observes → AI investigates → both communicate → human acts → AI verifies → AI acts → game state changes.

That is what makes /signal different from simply adding a chatbot to a game.

WebMCP is not an interface added on top of the game. It is part of the game mechanic itself.

Challenges I faced

Designing puzzles that genuinely require two players

The hardest part was not implementing the interface.

It was making sure the AI could not accidentally solve everything by itself.

Every puzzle had to answer three questions:

  • What does the human know?
  • What does the agent know?
  • Why do they need to communicate?

If either side had too much information, the asymmetric mechanic disappeared.

Keeping WebMCP useful without making it overpowered

It would have been easy to expose a tool such as:

get_solution()

That would technically demonstrate WebMCP but completely undermine the game.

Instead, the tools expose capabilities and information, not answers.

The agent still has to reason.

Synchronizing two very different interfaces

There are effectively two interfaces operating on the same mission:

Field Ops: the visual game interface.

Systems: the WebMCP tool interface.

Actions performed by either side have to update the shared mission state correctly.

That became especially important in modules where the human configures something and the AI must perform the final authorization.

Making it feel like a real game

I did not want /signal to look like a dashboard built for a hackathon.

All of the visuals are built procedurally with CSS and SVG: switches, gauges, pipes, navigation fields, indicators, system traces, and controls.

The goal was to make the browser feel like a piece of fictional mission-control hardware rather than an AI demo.

What I learned

The biggest thing I learned is that agent-native software does not necessarily mean giving the agent more control.

Sometimes the more interesting experience comes from deliberately giving it less information than the human.

WebMCP makes it possible to design applications with two interfaces:

one optimized for humans,

and another optimized for agents.

Those interfaces do not have to expose the same things.

That opens up much more interesting forms of collaboration than simply asking an AI to operate software on our behalf.

I also learned that agents become much more interesting when they are given a role with constraints.

In /signal, ChatGPT is not supposed to be omniscient.

It is Systems.

The human is Field Ops.

Both have responsibilities.

And that limitation is what creates the game.

What I'm proud of

/signal is not a scripted animation or a fake MCP demonstration.

It is a complete playable mission.

A player can open the live site, connect ChatGPT through WebMCP, restore all four systems, and complete the game from beginning to end.

The moment I wanted to create was simple:

PLAYER 2: WAITING

ChatGPT connects.

PLAYER 2: ONLINE

And from that point onward, the AI is no longer outside the application.

It's playing with you.

Built With

Share this project:

Updates

Submission history