Building a Laser Shooting Game with Claude Code: A Camera Scores the Screen

A developer used Claude Code to build an open-source laser shooting training game called ScreenPlink in two weeks: turn your monitor into a target, train pistol shooting with a laser, and a camera films the screen from the side, identifying hit pixels in real time and punching bullet holes. Virtually all of the project's code was written by an AI agent, with the author responsible only for design, playtesting, and judgment calls. This may be a hardcore experiment in taking "AI programming" from a toy to something that measures the physical world.

From Screen to Shooting Range: ScreenPlink's Gameplay and Hardware Requirements

ScreenPlink's core idea is straightforward: you shoot at the screen (with a laser training pistol or a real gun fitted with a laser cartridge), a camera mounted beside the monitor watches the screen rather than you, and the app calculates which pixel the laser dot lands on, "punches" a bullet hole there, and the target drops. The game includes nine training drills, fifteen target shapes with scoring rings, a 17-round magazine capacity, and supports same-screen two-player competition.

Even flashier is dual-wield mode: hold a laser pistol in each hand, and two laser beams appearing simultaneously in the camera frame are recognized as two independent shots. Calibration doesn't require live fire either—the program photographs marker points it places on the monitor to learn on its own, and the camera need not face the screen directly; angled placement is a supported, normal scenario.

Hardware requirements are clear: Windows, a matte (anti-glare) monitor, a 60fps camera, and a red laser trainer. The author specifically warns that glossy screens and TVs won't work.

The Hard Part of AI Coding Isn't Game Logic—It's "Not Being Able to See the Physical World"

The most fascinating part of the project is how Claude Code was used. The author's design principle was clear: he designs the game, directs Claude, shoots at the screen, and decides what counts as acceptable—but he didn't hand-write any code. The real challenge isn't game logic; it's getting an AI agent that can neither see the monitor nor pull a trigger to develop and debug a program that measures the physical world.

To this end, the author built an in-process MCP server that lets Claude ask the running app "what did you measure?" It exposes the latest camera frame, the detector's arithmetic for each candidate spot (including rejected candidates and why), what's being drawn in both screen coordinates and camera coordinates, and the ability to inject keypresses and clicks without stealing focus from the fullscreen window.

The key design decision: MCP returns only measurements, never the app's own conclusions—because the app's conclusions were repeatedly wrong. The author notes that the program once printed "100% of measured shots met standard" on the same line as its own measurement data showing test points below threshold. This mechanism cut a single diagnostic session from hours to about 90 seconds.

MCP (Model Context Protocol) is an open protocol Anthropic launched in late 2024 to let AI models access external tools and data sources in a standardized way. It uses a client-server architecture: the AI agent acts as client, communicating via JSON-RPC with local or remote MCP servers, which expose three kinds of capabilities: resources (readable data), tools (callable functions), and prompt templates. Compared with having a model call hard-coded functions directly, MCP's value is decoupling—the same server can be reused by different AI clients, and tool descriptions are self-describing to the model. The "in-process MCP server" in this article means the server runs in the same process space as the app, so it can directly read runtime state such as in-memory camera frames and detector intermediate variables without serializing to disk or network, with very low latency. This design lets the AI agent "peek into" a real-time system it cannot physically perceive.

A "Camera Blamed" Incident Triggered by an Escaping Exception

The article records a typical debugging case: one build kept prompting "please unplug the camera." Through MCP, Claude read the calibration result of 0.91mm from seconds earlier, re-ran the self-test and got 12/12 passing, and finally traced the fault to a missing art asset file—it threw an exception inside the draw handler. Because the exception escaped before the "frame already presented" signal was sent, all timeouts waiting on drawing were triggered, and the camera became the scapegoat. A single launch produced 1722 stack traces, yet not one appeared in the app log.

This case shows that when an AI agent cannot directly observe physical output, giving it raw measurements rather than conclusions is an effective path for troubleshooting cross-hardware-software problems.

Making Tests Actually Fail: Mutation Testing and the "Ready" Gate

The author's approach to test credibility is equally noteworthy. The entire startup test framework had long had a flaw: it exited after the first launch and reported success, so the so-called "8/8 cold starts" number was never actually measured. The fix was mutation testing—deliberately reintroducing each known fault and requiring the corresponding check to go red. The first run injected 7 faults and 3 survived; the project now performs 326 mutations across 6 runners, all caught.

Moreover, a single successful run is highly misleading here: one calibration had a holdout error of 0.4mm, and the next became 273mm with no code change. The project therefore stipulates that five consecutive clean cold starts count as "usable," and gates the word "ready."

The author's "honest headline number" isn't a test result either: an independent microphone channel separately counts trigger pulls and compares them with camera detections—84% to 89% of heard pulls were converted into detected shots.

Mutation Testing is a technique for evaluating the effectiveness of a test suite. It works by injecting small artificial defects into source code (called "mutants," such as changing > to >=, deleting a line, or negating a condition), then running the tests: if the tests fail, the mutant is "killed" and the tests are effective; if the tests still pass, the mutant "survives," meaning the tests didn't cover that defect. The higher the survival rate, the less trustworthy the test suite. In this article, the author first injected 7 known faults and 3 survived, directly exposing blind spots in the startup test framework. The difference between mutation testing and conventional coverage metrics is that coverage only shows code was executed, while mutation testing actually checks whether assertions can distinguish right from wrong. The cost is computation—each mutant requires a full test run, which is why 326 mutations were run in parallel across 6 runners.

Open Source and Getting Started

ScreenPlink is open-sourced under Apache-2.0, with source code and a Windows release available. There are two ways to get started: download the release package, extract it, and run Play.cmd; or open the extracted folder with Claude Code and let it install and configure everything for you—the release package ships with CLAUDE.md and .mcp.json precisely for this, and Claude will run a camera check, pick out the camera actually aimed at the monitor, launch the app, and then tell you whether to start shooting or which physical problem to fix.

The project repository also documents all twenty lessons learned in detail; for developers wanting to use AI agents on projects combining software and hardware, these pitfall records may be more valuable as reference than the game itself.

One-line Summary

The developer built a laser shooting training game with Claude Code in two weeks, using MCP to expose raw measurements so AI can debug a physical-world program.

Paragraph Summary

ScreenPlink is an open-source laser shooting training game that turns your monitor into a target: a side camera identifies laser hit pixels and punches bullet holes, with nine drills, dual-wield mode, and same-screen competition, requiring a matte screen, 60fps camera, and red laser trainer. Nearly the entire project was written by Claude Code, with the author only designing, playtesting, and judging. The real difficulty was letting an AI that can't see the physical world debug a measurement program, so the author built an in-process MCP server that returns only raw measurements—camera frames, detector arithmetic—rather than the app's conclusions, cutting a single diagnosis from hours to about 90 seconds. Mutation testing also exposed a startup framework flaw that had never truly been verified, and all 326 mutations were caught. The core metric comes from an independent microphone channel: 84%-89% of trigger pulls were detected as shots.