Brain dump: On icing your projects

March 19, 2021

My project development style involves a lot of downtime. Either I lose motivation, or are busy in my actual work, the prototype failed, or some other reason causes me to be unable to continue working on the game to finish it. But that doesn’t mean I’ve given up on the game. For nearly all of my games, those were made over large periods of time, with effort I put in growing and shrinking like the waves.

For this, it’s important that you ice your projects correctly. Icing is similar to making a backup of a project (also super important!) but it involves more than that. When you ice a project, you should not only record it’s current state, but it’s also about ensuring that you can access that project multiple years in the future, and what your intentions were when you last worked on it. Aside from doing obvious things like commenting your code, some special considerations must be made if you want to ice your project in such a way that you can still get started with it years into the future. That is what this post is about. I have six thoughts I want to share.

1) Choose stable development technology

Technology can change a lot in a couple of years. Not only has this to do with the continued improvement of technology, but also the tug-of-war that the platform holders are playing with other platforms and developers. They can change the rules of the game at any moment, with or without reason. The only way you can get around this is to pick a technology that is likely to be around in the future.

This can be very hard to estimate, but it’s personally why I’m now mostly making browser games, since the tech has been around for a while and I expect games to stay mostly compatible with future browsers. If the technology is open source, or if the company keeps offering all older versions of their technology, it’s a good sign that you’ll probably be able to keep opening your project files for at least a couple of years into the future.

2) Document the most important things

Even then, you must record how to do stuff. Any documentation or help on the internet can vanish or drown at any moment. (If you have a page that you must preserve, consider adding it to the Internet Archive. That way, everyone can access it, even after the original goes down.) This is especially important if you work with technology that has been or will soon be deprecated.

The most important one is to keep a version of the technology around (for example, the installer package for a game engine). Save it together with the project if you can. Aside from that, you should keep a basic instruction for how to set up and compile a project. In this readme, record which version of specific programs you’re using, a step-by-step guide in how to set up the project on a fresh computer, and link other important documentation you’ve made (such as planning or design docs).

And if you have passwords for something (like virtual machines or Android keystores), don’t forget to record those too. This is also important for games that are already released: ask yourself, what should I absolutely record in case I want to update the game in the future?

3) Ice every single project

If you drop a project, it’s hard to say if you’ll ever gain the motivation to work on it again, or that it is simply left in the dust forever. On one hand, you’ll have to put in some effort to preserve a project that you’ve basically given up on, which you might not have the motivation for. But, realizing that you want to revive a project, but coming back to the code it’s a mess? Or it completely corrupted in the meantime? That will very likely dim any motivation you might have gained during your break.

Therefore, don’t be selective about which projects to ice. Just ice ‘m all. 15 minute prototypes to near-finished abandoned projects, you should treat them all the same. You never know when you might need it. (This could get messy though, we’ll talk about that in a bit: see point 5.)

4) Ice the latest version

If you’re a bit like me, you might take multiple breaks from a single project. Sometimes, I’m only able to recover an earlier version that I remember last working on. For example, when in 2020 I defrost a project I last worked on in 2019, I might only be able to find the older version from 2018 instead. This puts you in a tough dilemma: will I recreate the functionality from 2019? Or do I push the project in a different direction instead using the 2018 code? Or do I start over entirely? Or keep looking for the latest version?

Just this dilemma alone might cause you to give up defrosting the project completely. So make sure that when you notice a waning interest, you store the newer version of the project, preferably in the same place that the older version is in, and clearly label it with a version or a date so you can’t mix them up. (Don’t delete the older version though, see point 5.)

5) Don’t bury it

You might have so many unfinished projects across different technologies that it becomes a mess to recover one, should time ever come to revive it. Or you might want to be able to steal some specific functionality, a specific part of a prototype you want to reuse. Organization is key here: how would my future self attempt to recover this project? Try to be consistent with folder structures, file names, and where you store projects and assets.

As for where to save the project for recovery, this is a tricky one. Since your project will likely be offline (on your local file system), storing a copy in an online cloud service makes the most sense since it doubles as a backup. But will the online service you use for this still be around next year? What about the next five years? Finding a reliable permanent storage location is really really tricky in a world where technology is constantly changing.

As a last resort, you could remove projects to clean things up, but my recommendation here is actually to never manually delete any project at all, if this is feasible for you. For all assets there’s a non-zero chance you might want to recover it in the future. I might be especially careful in this area, but do consider asking yourself if you’ll absolutely might never need the project in the future, before deleting it permanently.

6) Or release it anyway

In software a project is never done: sometimes the team runs out of money or time and is launched into the world regardless of its completion state. If a project is unfinished, you can always throw it on the web with a disclaimer that it’s unfinished, and see what happens. If it’s clearly unfinished, I’d add a disclaimer that it’s a prototype. This takes a certain amount of bravery, but people might like it despite the fact that it’s unfinished (and of course, there are some people who like playing unfinished games for what they are).

But if it is already in some kind of playable state, you could consider releasing it as a normal game with no disclaimers at all. Now, at least you have some documentation (a project page) and an executable of the project in an easily accessible location. Finally, consider releasing the source project: this backups the source code, and in the rare case someone else want to pick up the project, they can do so (if you want this and give the project an open source license).

Final Words: What I use

I use Writer and Github Gist for single text documents. Sometimes I also drop text files in Trello cards on my project’s boards. For some of my games the source code fits in a single text file, so this is nice for those. Gist can also do hosting & version history for text files.

Github and Bitbucket are used to access to git and store larger projects. Git does a lot of things, but I mostly use it to keep projects synced between my various computers. But it’s also a version system, so you have backups for past versions of your project. There’s a learning curve, but it’s definitely worth investigating and goes a long way into solving the problems above.

I hope this post was helpful!