Dev Log 15th of November 2014

This week has not been a good week for getting things done.

Monday was decent enough – I finished the import/export quote-items feature for Quick Quote, felt pretty happy about that. That afternoon I began on the ‘About’ screen that QQ has been lacking all this time, both to point people to my site/other apps, and to properly display the open-source licenses that I should have been displaying all along, but didn’t realise at the time.

Tuesday though, I felt really off and emotional and weird, and later realised it’s because I was coming down with a horrible cold. Yay. So the rest of this week, I’ve felt rotten and slept poorly, which isn’t conducive to programming of any sort. It’s starting to clear-up now, and there’s still some time left before #PROCJAM ends, but I’m fully in bum-around-feeling-sorry-for-myself mode at this point.

So, no actual game-dev to speak of, but I still have some things I’d like to write about. Firstly, TRI was finally released last month, and I’ve had the chance to play it a bit. It’s excellent. I’d played parts of it a few times over the course of its development, and the improvements I could see from about 6 months ago got me thinking – maybe continuing to polish a game for months when it’s already “done” is hugely important to its success. There’s certainly the temptation when you’re near the end of a months- or years-long project to release it and move on as quickly as possible. Development follows a curve a bit like this:

(“Game quality” is a vague measure of how good the game is, how much it appeals to players, etc.) To start with, you make a lot of visible progress with a small amount of work, but as time goes on you get less and less improvement based on the time you put in. Assuming that your living costs are the same week-by-week, the tiny improvements near the end are pretty expensive, and this create a balancing act: how early do you stop development? If you spend too long on it, you’re wasting time that could be better spent on a new project. But throw it out too early and the low quality will attract a much smaller audience, or none at all. There’s even the issue of “will anyone buy this game at all?” Perhaps it’s safer to test the waters with a small, rough prototype rather than diving into a long development cycle.

What I’m beginning to think, though, is that a longer development is more likely to produce a game that is a success. With the huge number of games being released now, there’s more of a need to stand out, and putting more time in helps to separate your game from the mediocre. To graph it, I think it’s something like this:

My point being that sales aren’t linear, but a more polished game will get drastically more sales by standing out from the crowds on stores. While an extra few months on a game might make it only 5% better, that could still make a big difference in how successful it is. Admittedly, spending that time in this way is still a potential risk if it doesn’t pay off. I’m still learning to balance my development time.

Of course, I don’t have a lot of experience, and I’m basing this on impressions of how other people’s games are doing, and there are no guarantees in game development. I’d love to hear if people have evidence in favour of this idea or against it.