Get the latest Education e-news
 
  • How To Take 7 Years To Ship A Beta

    [07.31.18]
    - Ben Porter
  • It's been almost 7 years since I quit my last job. Back in 2011 I was a freshly baked postgraduate in Melbourne. I was entering my 30's and the indie game renaissance was in full swing. When my contract ended I decided to leave academia and pursue my own path in game development. I then began working on a game called Moonman. Fast forward some long years and that game, now called MoonQuest, has just been released on Steam Early Access and itch.io.

    So how can you take 7 years to make your game? Here are some important tips and tricks for taking your sweet time.

    Build Your Own Engine

    This is probably the most important part. If you're a curious soul and need to understand how every little part of a game works, then this step is quite easy. Simply open up your code editor, download a basic windowing layer like SFML (we aren't savages and this isn't handmade hero), and then start writing your resource manager, event system, animation system, physics system (which you'll ultimately throw out and replace with Box2D), scene manager, GUI code, serialisation framework, build tool-chain, entity-component system, and texture manager, to name but a few. By this stage you'll have a fully functioning non-game.

    To extend your development time even further consider using a language that introduces a major version upgrade (like C++11) partway through your development. Just try to resist refactoring.

    Don't stop at creating your own engine. You can also create your own tools, like a custom sprite editor, because all those other sprite editors out there do not do exactly what you need.

    Have An Unclear Game Idea

    Before development be sure to have an unclear image about what kind of game you are making. This will lengthen both your engine development time and your game design time.

    For instance, say you want to make a game with an infinite world where the player can keep walking in one direction and never reach the edge of the world. You will need to build a decent amount of technology to support that. A couple of years later you realise (from a game design perspective) that, no, you don't actually need an infinite world. Throw away all those data structures and algorithms that you've built. The 3 months you spent building a fluid system that works on an infinite grid? Throw it away! A simple array of fluid cells will work!

    Your game idea doesn't exist in a vacuum, and if it did it'd probably evaporate because it's so amorphous. This benefits our time-stretching goal in the following way: by constantly monitoring similar games that are released you can simply change your game to be less like them. Do all those games have "sandbox" in the description? Just make yours an anti-sandbox with a specific goal, that'll surely differentiate your game in the market. Are they all moddable? Throw away any ideas of modding and instead focus on providing more unique content. Or something like that.

    All that matters is that the idea for the game is in flux, constantly adapting to the market - to the extent that you cannot even write a single paragraph explaining what it is.

Comments

comments powered by Disqus