By Karyl Gilbertson
The days of shipping software on physical media are fading rapidly, yellowing with age like old newspapers. Indies have embraced digital distribution channels from the word “go”, even lumbering AAA publishers are moving further and further away from physical discs.
Withering, along with the demand for physical media, is the concept of software ever being finished. I believe this is a good thing overall, but this sudden shift requires a significant change in thinking. Many of us still hold (perhaps unconsciously) outdated attitudes about how projects get to “done”, and we cling to these obsolete ideas at our own peril.
That’s not to say we shouldn't attempt to finish things, but we need to poke around in our brains and redefine what the idea of “finished” really means in the realm of software development. By doing so, we can craft a better development workflow that is less naive and more sane.
So What’s The Problem?
I believe that for a lot of people working on indie games (and software in general), there is this idea that whatever we are working on will truly be "finished." We believe at some point, our product will be wrapped up with a neat red bow and shipped out into the big wide world. We dust our hands off and congratulate ourselves on a job well done, before turning towards the next exciting project. Nice and shiny.
Sadly, this is nothing more than a fantasy. Some of you may have already come to this realization, but many have not. There are a number of ways in which these projects will continue to demand our time and attention.
The first and most obvious is bugs. We humans are prone to making mistakes, and even the best programmers unwittingly create bugs now and then. In this regard, digital distribution platforms have been a massive boon. Can you believe that people used to ship patches and software upgrades on actual discs (and before that, disks)! While we can be thankful that pushing updates has never been easier, it bears remembering that there are things that will need fixing.
Second: marketing and building a community. For many developers this is an afterthought, which is a huge mistake. Not investing time and resources into marketing and community building is often a death knell for a game, regardless of how fun that game may be. Ideally, these efforts should begin alongside the development process itself, and continue on through release and as long as possible afterwards. Unless you’re amazingly lucky, there is no magic that will make everyone download your game. You simply have to put in the work, consistently, and over a long period of time.
Third: once you have a community, (i.e. users that actually buy and play your game), guess what? You’re going to need to support them. You’re going to have to answer questions, troubleshoot technical problems, all for your audience. Even if you write impeccable code and mostly avoid the bugs mentioned above, support will likely take up more of your time than you realize.
What if you hit the sweet spot of luck and hard work, and your game is really a success? It’d be a smart decision to keep things going for as long as possible with downloadable and expansion content.
Another smart business decision, provided there is some kind of demand for your game, is to port your game to additional platforms in hopes of attracting new customers without having to make a whole new game. It goes without saying that while the development cost of such endeavours are significantly lower than starting from scratch, they’re far from zero.
There are additional concerns that apply if you’re developing a game for a mobile device such as a smartphone or tablet. The product cycles for these devices are quite short and both hardware and software are in constant flux. Even if you leave your game more or less as-is, there is still a need to test and update your game with each new hardware and software configuration to make sure no new bugs are introduced and that it doesn’t look or act totally broken.
This is why in the world of software, and particularly in indie games, the current definition of “done” doesn’t really cut it anymore.
Where do we go from here?
I believe it’s actually simpler than you might think. We as developers need to accept the fact that software is almost never complete. Keep calm and carry on. Adjust our expectations and design our workflows with an eye on continuous development. It's not really a problem once we change our perspective.
We need to adjust our schedules so that we can hop back and forth between working on new games and projects, and keeping the old ones well maintained and running smoothly. It might not sound like much fun, but the silver lining here is that you’ll never be bored—you’ll have an even more varied pool of tasks to keep things interesting.
And if you can make this change now, you’ll be better off. You’ll have more realistic expectations that’ll line up with your needs, and you'll be less likely to burn out when faced with the inevitable sudden tasks that pop up.
We must also try to raise awareness of this workflow issue amongst our peers. While this is also a lesson that is eventually taught by experience, the transition will likely be much smoother and less traumatic if done mindfully.
So, what are your experiences with projects not really being “done” when you thought they were? I’d love to hear your thoughts on these ideas, as well as any development stories from the trenches.
Karyl Gilbertson is an independent game developer currently working on a first-person adventure game called Arkaia: The Mysterious Island. He can also be found tweeting over at @karyl.