ΔV: Rings of Saturn - 15 months of progress news

Looking back at last 15 months

Looking back on my internal changelog, in this time I fixed 553 bugs, added 415 new features, released 883 experimental builds and 30 stable ones. I’m quite amazed at these numbers - they add up to a stable release roughly every two weeks and two experimental releases a day. That’s not some short-time sprint, we got this steady torrent of releases going for more than a year. How did I pull that off?

Experimental releases

When you hear the word “experimental” you might get a wrong idea. None of them were broken, with placeholder art or in any way un-polished. Sometimes we got a regression - when adding a feature or fixing a bug causes something else that is not expected, but you never get a half-product, and bugs rarely persist for more than a few hours.

In fact, roughly 58% of players opt to play the experimental branch exclusively, to get their hands on the newest features as soon as possible. In fact, the stable releases are not not driven by stability of the game, but my ability to compile meaningful and entertaining release notes - the “experimental” branch is usually just as stable.

Minimum Shippable Product

Two versions of the game released a day is the average - sometimes you get 8 in a day, other times one every two or three day, and it evens up over a month. Releasing versions with this velocity requires a specific workflow - something that I wagered that would work well for game development two years ago, and it turned out it was a good bet.

I develop ΔV using a subset of agile software development methodology.

I start with a minimum shippable version. That was the game I released in Early Access back in 2019 - a version that has no bugs I know of, no placeholders, no blatant missing pieces. It didn’t have all the features that I wanted and it was a small game, but it was a complete, shippable game.

After that I just had to make sure that every step along the way, I start my work with a shippable product so I need to end it the same way. Nothing broken, no balant bugs, no placeholders.

And to do that I needed to embrace the idea to fix bugs first.

We, the software developers, are easily distracted by shiny new features. But I needed to repress that. Want to add this cool new gun? Sure, that will be my reward for fixing these bugs. Don’t let bugs lay around and pile up, fix them as soon as I can find them.
Ultimately, I start each day with a shippable game and I end each day with one. And if I just broke everything beyond repair? That’s what source control is for. I wasn’t shy to revert all that rubble, at worst I just lost a day of work.

Having my game shippable all the time was paramount.

What didn’t work

It’s not all rose gardens. Some of my ideas for development, as nice as they were, didn’t actually work out.
Monthly roadmaps seemed like a good extension of the workflow I use. What could go wrong if I just list things that I think are manageable to do next month and post that for a community? Couple of things, as it turns out.

First, planning month ahead is just too far away for an indie scope. I did three monthly roadmaps and none of them actually made it in the way I planned. Sometimes I came across unexpected bugs that delayed features I planned, sometimes things we planned were just too big to fit in a month, and sometimes we just found things that were much fun for an hour of work. Ultimately I scrapped the monthly roadmap idea for something more manageable - and I’ll elaborate on that in a minute.

Another thing that I didn’t plan was the effort it took to actually prepare the roadmap and write it down in an non-boring way. It’s one thing to just list the features you plan to add, but taking a step back and writing a coherent narrative, keeping in mind that it will be read by both new players and current fans, took a couple of days - and that was way too much. I would very much prefer spending my time on making the game rather than describing what I was making. But we did work out a solution.

The wonders of game community

The best thing I did for my development was to start the game Discord. But it’s not about just making an outlet - it’s about actually connecting to my players. I started with a simple idea - a community where I can communicate real-time would very much benefit my ability to understand and fix any reported bug. If I can query the player realtime, I can get in minutes all the relevant details that would take days to get over a forum or email.

What I didn’t expect was the personal connection I got with players. I made a lot of friends - and some even went as far as to join our team. This is not only my way to get bug reports or post news - we hang out, talk about all the geeky tech stuff, and joke around.

And the most important thing, for me, is that I can see that people actually care about what I do. I get near-realtime feedback to all the releases and it does wonders for the morale. We have dedicated channels for posting and voting on ideas, and a periodic vote on where to take development next, so players get to say if they would prefer more story, more upgrades or some quality-of-life improvements to UI.

Things that sparked joy

After a few months I found that the easy way to solve my problems was to scale down. A month of planning ahead was unmanageable, but I could plan for a week consistently. But that didn’t warrant a big announcement on the game page - instead I’m just doing a short weekly summary on what I’m going to do next week.

But how do I keep track of what to do?

I got myself a Kanban board. The concept is really simple - get a list of things that I eventually want to do (the Backlog), things I currently work on (the ToDo) and a list of things done.

The Backlog is huge - over 500 items at this point, and the Done list is even bigger - over 2000 entries. But the ToDo is what needs to be manageable. I worked out that the best size is around 10 items - ten things that I need to do before I take another ten - there is no adding to this list before I’m done with all of them.

Why not just one? Sometimes I got stuck on something. I was hunting for a bug and I just couldn’t replicate it (and you can’t fix a bug you don’t see), or I just didn’t have an idea how a new ship should look like. At that time I took another task from the list - and I could do that freely, because I was confident that no task would go abandoned. I still needed to do this ten things before I moved forward.

To make it work with a weekly timetable I keep everything bite-sized - stuff that can be done under a day. No big “make a trading system”, just small things like “design a trading station”, “make a trading station sprite”, “add trading station to the engine”, “write dialogs for trading station” - just to take a recent example.

Having small issues to work with has many benefits. One of them is planning - I can reliably pick 10 of the issues to make and be fairly certain I’ll finish them up in at most a week. Things on that scale are just manageable, providing tangible progress that players enjoy.

Another, and most important benefit, is psychological. With small tasks ahead of me I never run into “what I should do next” problem. I might wonder where I should go when I’m done with my current ToDo, but once I have my ten tasks for a week it’s just effortless to pick one up and do it.

And the most important thing? With bite-sized tasks, every time I finish one I have a shippable product again. I can just publish it right here and now, fully polished and fully playable.

This is the core of my rapid development cycle.

Tools for the job

I drew from my experience as a programmer to pick the tools I used. If you follow in my footsteps you’ll probably want to pick your own - but here is what worked for me:

• Git as the version control. You can use any source control you want, but you need to use one. Version control is a programmers quicksave, the tools that allowed me to recover from failures quickly and the tool that documents my progress. When I broke something badly - I just reverted. When I needed to write changelog - my Git history was an awesome resource.
• Gitlab as a Kanban board. It integrates with Git nicely, so I have code branches bound to issues and I can check what changes exactly I did to address any given task.
• Godot Engine as my game engine was also a really important choice. Most obvious benefit is the build time - I can run my build script, which prepares 6 versions of the game (windows, mac and linux for both full version and the demo) and send it to all the storefronts in mere minutes, fully automatically. I wouldn’t be able to iterate so fast if my builds took hours.

Free demo version of ΔV: Rings of Saturn is available on Steam.