WARD/EN is a programming game about sending autonomous drones into derelict spacecraft. You run the recovery ship, choose the contracts, fit the equipment and write the programs. Then you dispatch a drone and watch it put your decisions into practice. There are no movement controls to reach for when it takes a wrong turn. Getting it home is a problem for your code.

The whole thing takes place at the terminal of a salvage ship: green phosphor, deck schematics, sensor sweeps and whatever telemetry your drones can send back. A drone keeps running its program when it loses the link. You get to sit there wondering whether you thought of everything.

At first the job sounds straightforward. Find the cargo, collect it, return to the airlock. But the registry might hold a plan from before the ship’s last refit. The part you’re looking for might have been moved, with the only clue in a maintenance record aboard. Two apparently identical items might have different markings, and only one belongs to your client. Your program has to discover enough to make a decision, then act on what it actually knows.

The same goes for the things moving around inside the wreck. A sensor return tells you something was there when the instrument sampled it. It doesn’t tell you what that body intends to do. Keeping a history of sightings can help you judge whether a contact is heading towards a nest, but you can still be wrong. Different sensors give you different evidence to work with.

I’ve built a small programming language for the drones, also called WARD/EN. It has functions, modules, arrays, records and state your program can carry through a run. The libraries are ordinary source: route planning, sensing and recovery routines are all things you can read and change. You can start with a simple directive, find where its assumptions break, and gradually build a library of your own.

The development tools are part of the game. The Workbench has an editor and a test bench where you can set a breakpoint, step into a library function, inspect the call stack and look at the drone’s local variables alongside the wreck. If your return-to-base routine gets stuck, you can stop on the line where it made the decision. There’s also a language server and a VS Code extension for working in an external editor.

Hardware gives the programming some practical constraints. Batteries, payload, sensor coverage and controller capacity all matter. A cheap, specialised drone can be a better choice than an expensive machine if you’ve written a good plan for it. You can also send several drones with different jobs and programs that exchange messages. Working together introduces its own questions: what does the other drone know, has it received the instruction, and what should happen if it doesn’t reply?

The campaign ties those expeditions together through contracts, repairs, refits and improvements to your ship. Wrecks retain the changes you make, so a first visit can survey the route or cut access for a later recovery fit. A successful expedition can be one that brings back useful knowledge and leaves the cargo for next time.

For experimenting, the Training Grounds give you the whole equipment catalogue, a budget and a generated problem. You can share the challenge as a code and compare approaches by cost, time and what comes home. There’s a guided language course, plus a shorter Fast Track for people who already program.

It’s still in development. The part I keep coming back to is that moment when a program finally handles something it couldn’t before: it spots a bad map, follows the evidence, or decides to turn back while it still has the power. You wrote that judgement, and now you get to watch it work.