ScreenPlink

This is a laser shooting game. Your monitor is the target.

You shoot your own monitor with either a laser training pistol or with your own gun & laser bullet. A webcam watches the monitor (instead of watching you), the app figures out which pixel you hit, punches a bullet hole there and plays the shot. Targets fall, scores count, the gun's magazine runs dry.

Full source code included with the build. Free, offline, no account, no ads. Version 1.0 works on Windows only. Feel free to clone and make it work for Mac if you feel like it.

It is an ideal addition to a man cave, and it works anywhere you have the hardware and can control the lighting: a games room, a basement, a bar. The lighting is the real constraint rather than the space. You are not asked to sit in the dark, but a room you can dim is a room this works better in.

What you get

• Nine drills. Static targets, an escalating ball, bouncing balls, reaction, clear the board, pop-up figures, a held figure, a figure that walks in and back out, and a soldier who takes hits and drops.
• Fifteen figures with scoring rings printed on them, and a fall for each.
• A seventeen-round magazine. Every shot spends a round, hit or miss. Fire on empty and you get a click instead of a bang.
• Two players on one screen, left and right, scored separately, each with their own magazine and their own score. Play someone else, or take both halves yourself with a pistol in each hand and work your weak side. Two lasers landing in the same camera frame are detected as two separate shots, so firing together is not a problem.
• Shoot the menu. The menu is targets too, so you never need the keyboard.
• It sets itself up without you firing a shot. It photographs its own markers on the screen to learn where the screen is and which pixel is which, so calibration costs you no ammunition and no patience.
• It tells you when it is ready, in about thirty seconds, or tells you the one thing to fix.

📖 The User Guide describes the gameplay exactly: every drill and how it is scored, the magazine, two players, and every key.

Why this exists

In Q4 2026 I went looking for a free game that would let me shoot moving targets on my own computer monitor with my laser trainer pistols. I did not find anything quite like that.

So I [read up on the dry-fire laser landscape][book], and worked out that it ought to be possible, provided the monitor is matte and the camera does at least 60 frames per second. Then I built the game I wanted, to my own taste and my own requirements.

I am sharing it in case a few other people find it useful.

What you need

One setup, honestly

All of this was built and measured against exactly one rig: a Dell U4320Q (42.5″ 4K, matte) watched by a Razer Kiyo Pro, shot with two LaserLyte LT-TTL trainers. Nothing is hard-coded to any of it, and the app measures your camera and your room rather than assuming mine. But one monitor and one webcam is one monitor and one webcam. Your camera may report its exposure differently, your panel may scatter the dot differently, and you may meet something I never did.

That is what TROUBLESHOOTING.md is for. It is written from the faults this hardware actually produced, and it lists the numbers a healthy setup gives, so you can tell how far yours is from working. If you hit something that is not in it, open an issue: numbers from a second rig are worth more to this project than any feature.

Get it

Download the latest release, unzip it anywhere, and run Play.cmd. That is the whole installation: no Python, no dependencies, no installer. Windows only for now.

Run Doctor.cmd first if you want to know which of your cameras is fit for this before you start. It tests every one it finds and writes doctor-report.txt beside itself.

Or do not set it up at all: ask Claude Code to. Unzip the release, open the folder with Claude Code, and ask it to set up the app. The release ships a CLAUDE.md written for exactly that job, and an .mcp.json so the session finds the app's own tools by itself. Nothing to configure first. It runs the camera doctor, picks the camera that is actually pointed at your monitor (by what each one measures, not by its name), starts the app, reads what the app measured about your room, and tells you when to shoot or which one physical thing is in the way.

This is how the author sets it up now. See Asking the app what it sees.

If you would rather run from source, or you are on a machine where you build your own things:

python -m venv app\.venv
app\.venv\Scripts\python.exe -m pip install -r app\requirements.txt
app\scripts\Play.cmd

Close the game with Escape. Never End Task because a force-killed app can leave the webcam needing a replug.

The physics, briefly

Your trainer fires about 100 ms of red light per trigger pull. At 60 frames per second the camera gets six looks at it, which is what makes an ordinary webcam enough: six frames is a shot, one frame is noise.

The detector does not hunt for bright. It hunts for red, meaning red minus the stronger of green and blue. That is why the whole game is grey and dim. Anything red on that screen is something the camera could mistake for your laser, and anything bright underneath the dot drowns it.

The reason the panel must be matte is the same sort of thing. A matte coating scatters the dot, so a camera off to one side can see it. Glossy glass reflects it away instead, in a direction that changes with every shot, so no camera placement can follow.

If you are building something like this

The whole thing was written by Claude Code over about two weeks. I directed it, shot at it, and decided what was acceptable, but I did not write the implementation.

Built with Claude Code is the index to how that worked: giving an agent an instrument instead of a log, making tests that can actually fail, and gating the word "ready". It links everything else worth reading.

The file underneath it is Lessons learned: twenty findings, each with the measurement that caused it.

I am putting it in front of you because almost none of it is about lasers. It is about the things that go wrong when a program has to measure the physical world and then decide something on the strength of it:

• I chose an exposure by a number that correlated with what I cared about instead of the thing itself, and darkening the room, the single best condition this app can have, is what broke it.
• My whole-launch test harness exited after its first launch and reported success, for as long as it had existed. A figure I had quoted for days had never been measured.
• A cleanup worked for weeks because of what happened to run after it, and failed the day that stopped being true.
• One missing file raised an exception inside a paint handler, and the app spent days telling me to unplug a camera that was measuring sub-millimetre accuracy four seconds earlier.

If you are writing anything with a camera, a real-time loop, or a program that has to diagnose its own hardware and explain itself to a human, I think you will recognise several of these, and some of them are cheaper to read about than to find. There is nothing personal in that file and nothing specific to my setup.

Read more