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." --Me
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. One thing I feel that I should point out though - I'm not talking about severely over-engineering a whole project, just adding a few little things that might not be strictly necessary.
I recently released a game called Pixel Beach (available on Mac, Windows, and Linux as a free download). The core of the game was developed for a 48 hour hackathon as a web app but I wanted to test out the process of converting something like that into a full standalone desktop game.
Initially, the conversion process was the thing I was prototyping but I figured while I was at it I could test out a few other things for a bigger project I was planning.
Pixel Beach is fully translated into English, German, and Spanish. I wanted to test out a simple but robust translation engine and it worked out great.
Another successful test - The way the character sprite is loaded and rendered utilises a system that could be used for a full character creator. There is no actual character creation screen (I might add a randomiser) but that doesn't really matter. I just wanted to test that the system of loading and rendering from a custom character worked.
I also built out a virtual input handler to help deal with multiple options for player controls. It abstracts away the actual input source so it doesn't matter if a player uses the keyboard or a gamepad. The 'scene' code just handles intents and the virtual input does the work.
There are four main reasons I like releasing prototype games:
- 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.
- 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.
- 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.
- You never know when someone will fall in love with your 'throwaway' game.