Hi I’m AceOfSpider of Buy Me A Drink First games and this week I’ll be sharing how I plan what goes into the monthly updates for my game.

I have committed to releasing content every 4 weeks, this could be any combination of new areas, enemies, NPCs, resources, equipment and quests. So why have I chosen 4 weeks instead of monthly. Well in short, consistency, if I were to release content on the 1st of every month, then I might be releasing on any day of the week. This means it’s less predictable for followers and for me developing the content, I’d prefer to release on a friday. I could instead release content on the first friday of each month, but then you run into another issue which means that most updates would be 4 weeks, but some would be 3 weeks or 5, leading to inconsistent development time and harder to scope updates. Why not just release content when it is done, there is a risk to this, I might not ever think it is ‘ready’ and therefore it would never get released and the project would just stand still. Having a set time limit holds me accountable to keep scope narrow. So 4 weeks for a sprint, how many things can I actually fit in?

I have no idea, but I am getting better at estimating but there are a lot of variation between tasks. I look at how many tickets I have completed in the previous sprint and how many are carried over, and use that to inform the next sprint. By the way this is all in my spare time I usually have less than 30 minutes on a weekday and a couple of hours on a weekend to work on game projects. So at the time of this recording I am on 0.8 tickets per day.

I have a backlog of tickets in GitHub for new content, bug fixes, feedback. I use GitHub milestones to keep them together. Then I keep track of sprint progress using a Google Sheet. I’ve got a table that includes; the Day of the Week, Date and number of tickets remaining, which I update as I go. I also have an expected remaining along side it as a goal. From this you’ve got a burndown chart. If my line is below the guide then I am on track, if it’s above then I should probably put more time into the current milestone to bring it back on schedule. The whole point of this is that I only have a small amount of time per day, so I am more likely to be able to do many small updates rather than spending an entire weekend hacking away. (Although I do do that in Game Jams but I usually book time off of work for that and don’t see the light of the sun).

I also have a pie chart showing the distribution of the types of tickets to make sure I have a balance of art, sound, features and bugs rather than a tonne of updates to one type. This is mostly for me to have a variety of tasks to focus on and keep me engaged.

During the sprint there are key dates; every wednesday there is a staging build, this is an automated build deployed to Itch.io this is to make sure the game is still deployable and invites regular testing. The last wednesday is when the final content build is created so the week before (between the last wednesday and the second to last wednesday) there is a feature freeze, during this week I cannot add any new major features, this is to prevent the chance of adding last minute bugs. This features freeze week is usually reserved for testing, bug fixing, preparing marketing and the release post.

So far this process if working for me, it has allowed me to release the game with 0.6, it’s first expansion with 0.7 getting smelly and I am not far from 0.8 a grand improvement. I already have content planned for the next zone The Undersludge and this system has given me confidence that I will be able to delivery it.

Thanks for listening, see you in the next one.

~AceOfSpider