Nathan Hoad

Publishing prototypes

I was recently watching John Romero's talk from GDC 16 when one of his principles stuck out to me:

"No prototypes. Just make the game. Polish as you go. Don't depend on polish happening later. Always maintain constantly shippable code."
—John Romero

When you've had the success that he had with id Software back in the day it's hard to argue. So argue I won't. Instead I will elaborate on the point Romero has made with my own interpretation of it.

"Publish your prototypes. Test out ideas on smaller games and release them before committing them to bigger projects."

This way you still technically aren't making 'prototypes' because you're releasing actual games but you're also getting the benefits of testing out ideas beforehand.

Perhaps not all prototypes make it far enough for them but, for any that do, there is value in the “releasing a game” experience.

Screenshot of Timesweeper
Timesweeper is a two-player showdown.

I recently published a game on and Itch (the Itch version is just the Gotm version embedded) called Timesweeper.

Timesweeper began as a quick prototype of the high level multiplayer API in Godot 3, then a quick prototype to see if that would work with the Gotm addon.

It wasn't long before I had the whole thing functional as a very rough prototype. The game was mostly playable but setting it up each time was a bit cumbersome.

I figured that I was close enough to having an actual game I should just tidy up the rough edges and actually finish it.

I added a title screen and some UI to host/join games as well as the end screen when someone wins.

There are four main reasons I like releasing prototype games:

  1. It makes you solve any actual problems, not just prove the basic idea. If you have to release the game into the wild you have to make sure your idea is fully formed. This means you won't have half-baked ideas making their way into your bigger project.
  2. Doing something a second time is always better. You can make a small mess of the first implementation while you learn how best to do it. Then, with your newfound knowledge, you can implement a cleaner solution into the main project.
  3. Even if you don't end up using the idea for anything else you've got something to show for it. In the example of Pixel Beach, I'm not sure if I'll end up using the web-app-as-desktop-game method for releasing my bigger project but it was fun to test out and I have a full game to show for the effort.
  4. You never know when someone will fall in love with your 'throwaway' game.