What a 1985 computer game taught us about faster prototyping

A computer game from 1985 recently made its way into Webnorth’s Friday social time.

One of our senior developers, Michał Gwóźdź, spent around six to eight hours rebuilding Space Wars, inspired by a DOS game Simon remembered playing as a kid. The result was a browser-based multiplayer game where up to 20 people could draw their own spaceships, shoot at each other and disappear into hyperspace, with a 5% chance of exploding in the process.

Naturally, it did not take long before our Pingtime Social turned into a fairly chaotic Space Wars tournament.

Michał built the game using Node.js and WebSockets, with Claude helping speed up parts of the development process. We already use AI as part of our development workflow, and have written before about how we approach AI in software development. In this case, the interesting part was how quickly an idea could move from something experimental to something people could actually use, test and react to.

That became particularly clear once we started playing.

With 20 spaceships moving around the same screen, people kept losing track of their own ship. Instead of noting the problem for later, Michał added a distress flare almost immediately. We kept playing, the new feature was tested in practice, and the game improved while everyone was still using it.

That is where faster prototyping becomes useful. The value is not simply that development takes fewer hours. It means there is more room to try ideas that might otherwise never make it past the discussion stage.

When the cost of testing an idea comes down, you can build a rough version, put it in front of people and learn from what happens. Some ideas will turn out to be unnecessary. Others will reveal possibilities that were difficult to see before there was something concrete to interact with.

The same thinking is useful beyond experiments like Space Wars. In custom WordPress development, there are often features, workflows or interactions where seeing an early version makes it easier to understand what users actually need. Faster prototyping gives us another way to explore those questions before committing too much time to the wrong direction.

Three years ago, we probably would have thought twice about spending six to eight hours on something this experimental. Today, tools that speed up development make that kind of exploration easier to justify.

Sometimes the result is a better approach to a client problem. Sometimes it is a new technique worth exploring further. And sometimes it is 20 colleagues trying to shoot each other’s badly drawn spaceships on a Friday afternoon.

All three can teach us something.