Probability of Shipment

I have been writing software for past 32 years. A nice round number. I have done business software, frontends, backends, games, demoscene demos, tiny scripts and large monolithic behemots. There are dozens if not hundreds of my commercial programs released out there, yet I have not shipped a commercial game. Yet.

I am confident I will ship one.

Feature creep is the bane of any software. Independent developer has an inherent advantage – there is no publisher to push release dates, there are no forced changes. I have found that a key for successful software development is the agile mantra: limit scope to MVP and then PSI it all the way to release. I am doing to apply this to my games.

Minimum Viable Product

The basic idea is to first make something as small as possible that is a viable product. For a game it means: the absolute minimum core gameplay, with reasonable graphics and sound. It does not have to have most of the planned features, but is a something that you could probably release and call it a “minigame” or a “demo”.  ΔV has almost reached this stage – the graphics is polished, the sound is there, the bugs are squashed. It still needs trivialities like a pause menu and game over screen and I could release it as a demo of the gameplay.

I actually have a milestone for that, and it expires tomorrow. I will probably not make it – but that’s another good thing about independent development – you make your own deadlines.

An MVP will be there in couple of days. Then comes the incremental iteration.

Probably Shippable Increments

Idea behind PSI is to develop it in short iterations (“sprints”) and have a shippable product after each one. You take a week to add some features, and you ensure that after end of the week you have a game that can be shipped as-is. My development cycle is really short – I usually have features that I can put in within few hours, then I spend few hours on polishing them and fixing any bugs. My ultimate limit is – on every Monday morning there has to be a shippable, debugged game to show off.

So far it worked really well.

The pros and cons

It does take some discipline to push cool features down the backlog and fix bugs and polish first everything. It also makes the overall development longer. I need to create at least decent assets for the game – no placeholders allowed, sorry.

But I get to have a polished product along the way that I can show off to people. I can make a cool GIFs and animations just by recording one of playtest sessions.

And finally – If I ever get tired or burned out, I will have a shippable game right there. It could not have all the features I have planned, but neither will it be a bugged mess.

That is why I am confident I can ship it.

Tools for the job

Version control is an absolute requirement. I need to be able to work on multiple problems concurrently, the ability to rewind or cherry-pick any of the changes is a life-saver. If I ever experiment and end up with tangled mess of bugs, I can just store current state and abandon the branch.

Fortunately, Godot plays really nice with version control. I’m using git as my version control system – mostly because that’s what I use every other day in my day job.

Privately hosted instance of Gitlab serves both as a backup service and issue tracing. Issues are conveniently tied both to specific commits in my source tree and branches. It serves as project organization tool, kanban board and bug tracer in one place.

I also toyed with idea of CI builds on the Gitlab server, but current Godot requires a graphics card for texture imports, and my server has none. That is a real shame – with “Detached” I had a server-side build, so my testers could grab a fresh build on each platform minutes after I pushed a patch.

It would be nice to have automated tests for games, but I don’t think that’s going to happen anytime soon.

This slideshow requires JavaScript.

TL;DR

To be certain of a release, I made smallest shippable playable game first, and then ensured that at end of each week I still have a polished potentially shippable product.