Marshmallow Bear /
Planning and Continuous Development and Delivery

When we decided to rewrite everything from scratch in C including the Lua code for Retro Sketch, we also decided that we would build out the rest of our infrastructure. One of the things that indie developers wind up doing is spending too much time on needless things, such as setting up Jira and automation systems. We believe that writing code is what we do, it’s in our blood, and using other people’s tools is not exactly the most efficient use of our time. Oftentimes it takes just as much time to learn somebody elses tools as it does just to write your own.

Project management

One of the many problems that comes up with any developer is keeping track of all the work that you need to do. Unfortunately, we turn to complicated tools like Trello, Jira, and even Excel/Spreadsheets. As a programmer, my primary problem with this is that it makes me leave my tools to go somewhere else and do something, usually on a web page. This is incredibly annoying, and also can be very distracting, trying to workout little details like what column goes where, or what tag should I give this thing?

For me, I don’t care so much about the history of work that I’ve done. The work is done, after all. What I’m more interested in doing is keeping track of things I think about that I need to do later, that I can’t be bothered with doing right now. If I can’t be bothered by doing it right now, it means I don’t want to spend much time thinking about it. Therefore, opening up some 3rd party tool and doing all of this rigomaroo with it is just an annoying distraction.

So, the way we track things that we need to get done is inside of markdown files that is committed directly to the repository. When we’re done and need something else to do, we can look at the markdown file to find out what is left to be done. We then pick something, and then when we complete it, we delete that line from the markdown file as part of the commit.

Build and Automation

We have developed an in-house continuous delivery and automation "system". Lucky for us, both Steam and itch.io have tools for us to automatically deploy via the command line. Being that we primarily develop on Windows, and sometimes on Linux and Mac, we can easily create what we need using batch scripts and shell scripts. Sometimes the language you choose greatly impacts how you build, develop and publish your products. In this case, we use the C language, which is incredibly fast to compile. We can compile entire games and software within seconds, which really reduces the need for any kind of distributed system of building. Since builds are often a sequence of things that need to happen, such as compile the executable, package the content copied to folders, delete files and upload to steam; these kinds of tasks can be easily automated through simple native scripts.

cmake logo

Though in the past we used either Visual Studio projects or makefiles, recently we started using CMake. I have to admit, at first, the language for CMake was confusing and poorly documented. Which is ironic because they have such a crazy amount of documentation. This is partly why I didn’t want to use it in the beginning, there is too much and I just wanted to get things done, so a simple makefile would do. However, after playing around with CLion, it was able to generate a bunch of the seamake code that I wouldn’t have known how to do otherwise. Now CMake is much easier to understand and I don’t have any issues with it. In fact, it has become an integral part for our continuous development pipeline. My advice to anybody who is a little hesitant about CMake is to use an tool like CLion to generate your sea make files, it makes it a lot easier to understand.