Delayed Gratification

One thing I’m having to slowly train myself into doing these days is delaying my gratification.

One thing I love about indie, completely free game development is that there’s no business case needed to justify anything I do. At no point do I have to cost out features, or focus test, or worry about manufacturing deadlines or so on. That means that the biggest reason for my implementing something is whether or not *I* think it’s worth doing. That decision is based on a number of factors, but since I code recreationally by far the biggest one is ‘am I going to enjoy doing this?’. Sometimes the enjoyment comes from the warmth of knowing that our lib has been extended to support a particular feature. Sometimes it’s the satisfaction of knowing a particularly ugly part of the code has been cleaned up all pretty like. Often, it comes from the buzz of collaboration – when you’ve enabled someone else in the team to do something they wanted to do. More often it’s because the task of coding it was in itself inherently enjoyable. But really, all I have to do is justify it to myself that this is something on which it is worth spending time.

That’s the usual case. Now though, it’s different. The end of July might be a self imposed deadline, but it’s a deadline none the less and one that we’re well on the way to hitting[1]. We’re down to less than thirty open bug-reports. My todo list now looks tameable, especially as I’m on holiday in a couple of weeks and I’ll have bags of time to simply pour into development and maintenance. There’s light at the end of the tunnel, and that light is soothing and comforting rather than frightening and upsetting.

The only reason the light is a sun rather than a train is because of late I have had to inculcate a kind of personal development discipline. I’m just not used to that, and my instinct is always to say ‘yes’ to a new development. While working my way through the code there have been many times when I started to code up a new object, or rewrite an existing system, or refactor a chunk of especially ugly code. I often get a few dozen lines into it before I tell myself ‘Bad Drakkos!’ and hit my own nose with a rolled up newspaper. We just don’t have the time at the moment for me to indulge myself with that kind of thing. I enjoy coding new things, even if they are new things that replace old things. Today I started to recode food objects, because our current old inherit is full of stuff that adds realism at the cost of lots of fiddly micromanagement in the code. You can do lots of neat things with food – slice it up, half it, pickle it, preserve it and so on. It’s all cool enough, but you know my mantra. If it’s not adding to the game, get rid of it. I was planning to convert food over to our far simpler ‘limited use’ inherit. This would neatly encapsulate all the incredibly complex eating and drinking code we currently have spread around the place. I still want to do it, but I had to remind myself ‘not now’.

New developments always introduce new bugs, and our task at the moment is to polish up the game. There will be plenty of time after 1.0 for us to investigate more substantial refactorings of various systems. Since we’ve only got a month left it would be ridiculously bad prioritisation to recode a system we already have just because I don’t like it much. Development discipline is what we need now.

A similar thing occurs as I go through our open reports. We get a range of these – bugs need to be fixed, and they’re being squashed on a pretty satisfactory schedule. Some might take a while to fix, but I am aiming for Zero Defects[2] for launch day. Typos are plentiful in the game, but they are usually trivial to resolve when they’ve been reported. The third kind of thing we get are idea reports. Those almost always look like they’d be fun to code, but I can’t be guided by that at the moment. That leaves a kind of tension – I don’t want open reports in the system for release, but we can’t invest the time needed to implement ideas right away. Luckily, back when I was on Discworld I had a system for that[3] – I called it the ‘rainy day file’.

On our wiki, we have a page marked for the ‘rainy day’, which is – when we have some idle time between projects, or we’re looking for something cool to add to a new project, or when we want to do something light before we move on to doing something heavy. When we go through our idea reports, essentially what we’re doing is a two stage pass.

The first stage is deciding which reports are going to be instantly dealt with. They’ll either get a denial (and a reason – you should absolutely always be getting a reason for any denied report you get back) or coded right away. If you catch the right person with the right access and skills at the right time, a good idea report might be implemented in a matter of hours. Those that the person reading liked the sound of but didn’t want to code right away (or thought that it was good but someone else might be interested later) we put on our rainy day file. It doesn’t guarantee the idea report will ever be coded, it just means that at least one person thought it passed muster as worth consideration. It was then promoted to a place where more people would see it.

The rainy day file does several positive things – it means that idea reports don’t languish unacknowledged for years in the system, which in turn means that you as a reporter get some feedback on the idea and we don’t have an ever increasing count of reports that we need to keep looking over. It means that our developers have somewhere to go when inspiration just isn’t striking. Every so often you get to the point where you think ‘I’d like to have another shop in this area, but I don’t know what it would sell’, and upon checking the file you find a dozen reports for ‘cool shops that there should be’. Mainly what it does though is act as an inspiration generator of its own. It’s in the nature of ideas to spark off other ideas, and bringing them together in one place can have a kind of alchemical reaction. Seeing three player idea reports for the same basic thing will spark off thoughts of our own, and they can lead down interesting avenues. Being on a wiki means that we get a chance to see the bigger picture in the relationship of idea reports, as well as bang them together in the ways we might prefer. We can categorise them, or combine them, or extract them into multiple reports. They become malleable in a way that a fixed entry in a database doesn’t even come close to permitting.

Back on Discworld, I think a lot of people thought being put on the file was just a nice way of rejecting a report. I can see why – with 8000 or so idea reports, some of which are almost a decade old, it seems like a brush off for someone to say ‘Nice idea, we’ll code it later maybe if we get time’. The problem there is in letting the idea count get that high at all – once you get to that number of open reports it becomes a chore for anyone to look through them at all and it’s virtually impossible for anyone to see any larger patterns. It’s fine for bug reports because those tend to be limited and specific to a context, a time and a place. Ideas are living things, and they want to roam free – at least, more freely than a database can allow.

Our rainy day file isn’t very big yet, but it does contain a healthy number of entries. Some of them came within a hair’s breadth of being coded when I read them, but… development discipline. Others suggested more substantial restructuring of our internal game systems, and we don’t have time for that yet. Come 1.0, we’ll be able to indulge ourselves more freely. I’m hoping release day comes with a huge explosion of excitement and suggestions and bug reports and such. It’ll be a busy time with things to do on a daily basis. That kind of thing can become wearing if it’s kept up too long, and it’s be nice to have a file of ‘off the shelf’, relatively low cost things that we can implement when we need to decompress a little. Your idea reports are too valuable to leave, forlorn and alone, in some dusty database. While we don’t have the time to do much with them at the moment, you deserve better than that for the time you invested in making a suggestion in how our shared game could be made a little better.

[1] Probably. There is a genuinely show stopping driver bug that absolutely needs to be fixed before we go live, and really that’s likely to be our limiting factor at this point. We crash constantly at the moment, and that’s not even close to being what I want the Epitaph Experience to be.
[2] As in, ‘no open bugreps’, not ‘no flaws’.
[3] One that I liked, although I suspect most everyone else simply preferred resolving the issue through indifference and indolence.

Leave a Reply