Set a date

Originally posted on my blog.

Today I’m gonna talk a bit about project organization and planning. I have been working as a programmer at The Game Bakers for something like 5 years now (I’m bad with dates), and if I’m still learning every day about coding, I am not very involved in the projects management and other marketing aspects of game developing. With Red Skies however (a personal project on which I work on my free time with a friend), I don’t have much choice, and I’d even go as far as saying that it’s one of the main reasons why I started it. I’ve read quite a lot of articles online, from very various sources, about those questions, but obviously there’s a gap between reading about it and experiencing it. Still, I find it interesting to see how other people deal with this kind of stuff, and that’s why I want to share my bits of experience (from a guy, keep that in mind, who didn’t release any game by himself yet).

So, “Set a date”, uh? When Foxbullbee and I started working on Red Skies, we didn’t have a very precise idea of the product we wanted, we just knew that we wanted to make a small and neat game. A two months long project, maybe three, nothing too fancy. Some months later, it had almost become the opposite: a pretty good idea of the game, a lot of features in the pipeline, and a very vague idea about a launch date.

At first we wanted to finish it (kind of) in the end of December, and release it (maybe) at the beginning of February. The problem every game developer has faced, though, is that when you reach 95% of the project, you get the feeling that it’s almost done, the pressure goes down, and yet you still have about 50% of the work remaining. And those 50% are not the main, sweet features the game is all about; those are the small annoying bugs that you didn’t want to fix immediately because they look vicious, the UI screens that are full of little assets that don’t require that much time individually and aren’t too fun to draw. A LOT of tiny details, polish, social integration, that, accumulated, give a huge workload. It’s also the marketing: releasing a game is nice, but without some effort, nobody will ever see it. And it takes time too.

So we sort of reached an impasse: the game was almost finished (in our minds, at least), but we didn’t work that much on it anymore (I mean, why would we, we didn’t plan to release it just the day after, and what’s left to do can be done so quickly before launch… you get my point). The issue is that if you don’t have a clear milestone, something that gives you a day on which everything has to be done, it’s easy to postpone. Just by not looking at the amount of various – yet so small – things that have to be done, you get the feeling that it will be easy and quick.

Realizing that, I opened a spreadsheet and started writing down everything I wanted in the game, classifying them among three categories:

– TODO: the core of the game (polished, including all inevitable elements such as analytics, monetization…).

– NTH (Nice To Have): it would be very nice to have on release but it’s ok if it comes later.

– V2: looks like a nice feature, but we’ll see later how things go.

Then, I tried to estimate the duration of all those tasks, having in mind that I would like the game to be released in one or two months. If at first I didn’t really care about the release date too much, as time came by I started to think that we already invested a lot of work in a “small” project, something that’s a training for us as well as a game for players. We hope the game will be nice, that players will enjoy it, but we don’t plan to revolutionize the gaming world with it, nor earning billions, so maybe it would be a good idea to release it someday and go on with another project (because it’s probable it won’t even earn enough to cover for the time invested).

So that was it. It was time to set a date, a real one; not an estimation, not a wish, but a great, final decision. If the game is perfect at this moment, great! If it’s not, well… great, too, because I’ll release it anyway. No game is ever perfect, and if you don’t stop at some point, you may work on it and polish it for the rest of your days (that is, until you’re not interested in this project anymore and give it up to start another one).

Now, having listed the features that were 100% needed in my opinion and assigned a duration to each of them, I arrived at 49 days or work. Even if I consciously overestimated most of the tasks, I know that there will be some unexpected difficulties, so let’s make it 60 days. And here is my date. I add one week for the approval processes on the various stores, and I take the most dangerous and scary step: I make the date public. I know there aren’t a lot of people (if any) that will look forward to it or even remember it, there won’t be a mad hype or huge expectations, but it doesn’t change anything: the date is set, and I am now bound (by myself) to respect it.

Of course, all of that was decided in collaboration with my partner Foxbullbee. Now we both know exactly the tasks we have to do (including those we forgot and will only discover two days before launch, because we set apart some days for them specifically – edit: localization, for example) and the time we have to work on them. I made myself a nice timeline with each task having a given set of days. I don’t know if I’ll exactly respect it, but at least it gives me a way to have a precise following of my work, if I’m late or ok, or even if I will be able to add some of those Nice To Have features in the first release because I was so fast and talented thanks to my precious and wonderful timeline.

So if you’re working on a small project similar to mine, maybe it would be a good idea, once you have a nice working prototype that gives you a precise enough idea of where you’re going, to set a date. Of course I wouldn’t recommend doing that right at the start of the project, even if you have a good idea of what you’re planning. However, once you’ve find the core of the game, make decisions. And if really you happen to think of a new feature that really is SO good you can’t do without it, well, nothing stops you from changing your plans.

On the day of writing this, it’s been one week since I did that, and I was far more efficient in this week than during the last ones! I have finally created my Apple account, I have added leaderboards for iOS and Android and created the apps on the two stores, and I ended the minimal levels and bosses amount we aim for. If I hadn’t made that list, I don’t think I would already have started looking in those social tasks, which aren’t too fun to work on. Now that I have, I find myself one week early on my schedule (yes, I overestimated a bit, but still, 200% more efficient, that’s motivating!), and I know I’ll be able to add some NTH features.

I realize that not everybody works the same way, but I’m quite sure that we all need goals to make progress; and in most cases, I think that precise goals lead to more efficiency. So take some decisions, and stick to them (or try very hard until it’s obvious you should switch)!

And if you’re curious to see how it turns out for me, well, take an appointment to March 24th to see if Red Skies makes it!

For more articles, you can follow me on Twitter, Facebook or subscribe to my blog.

Further readings:

An article about 100 times better than mine, but well, I forgot about it when I started writing this (and now you’ve read mine before, because I put this link at the end, GOT YOU)

A good article by former students about sticking to deadlines

Not really related, but it’s while reading this list of tips that I came to realize that I really needed to finish Red Skies sooner or later