Brain dump: On icing your projects

March 19, 2021

My project devel­op­ment style involves a lot of down­time. Either I lose moti­va­tion, or are busy in my actu­al work, the pro­to­type failed, or some oth­er rea­son caus­es me to be unable to con­tin­ue work­ing on the game to fin­ish it. But that does­n’t mean I’ve giv­en up on the game. For near­ly all of my games, those were made over large peri­ods of time, with effort I put in grow­ing and shrink­ing like the waves.

For this, it’s impor­tant that you ice your projects cor­rect­ly. Icing is sim­i­lar to mak­ing a back­up of a project (also super impor­tant!) but it involves more than that. When you ice a project, you should not only record it’s cur­rent state, but it’s also about ensur­ing that you can access that project mul­ti­ple years in the future, and what your inten­tions were when you last worked on it. Aside from doing obvi­ous things like com­ment­ing your code, some spe­cial con­sid­er­a­tions must be made if you want to ice your project in such a way that you can still get start­ed 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

Tech­nol­o­gy can change a lot in a cou­ple of years. Not only has this to do with the con­tin­ued improve­ment of tech­nol­o­gy, but also the tug-of-war that the plat­form hold­ers are play­ing with oth­er plat­forms and devel­op­ers. They can change the rules of the game at any moment, with or with­out rea­son. The only way you can get around this is to pick a tech­nol­o­gy that is like­ly to be around in the future.

This can be very hard to esti­mate, but it’s per­son­al­ly why I’m now most­ly mak­ing brows­er games, since the tech has been around for a while and I expect games to stay most­ly com­pat­i­ble with future browsers. If the tech­nol­o­gy is open source, or if the com­pa­ny keeps offer­ing all old­er ver­sions of their tech­nol­o­gy, it’s a good sign that you’ll prob­a­bly be able to keep open­ing your project files for at least a cou­ple of years into the future.

2) Document the most important things

Even then, you must record how to do stuff. Any doc­u­men­ta­tion or help on the inter­net can van­ish or drown at any moment. (If you have a page that you must pre­serve, con­sid­er adding it to the Inter­net Archive. That way, every­one can access it, even after the orig­i­nal goes down.) This is espe­cial­ly impor­tant if you work with tech­nol­o­gy that has been or will soon be deprecated.

The most impor­tant one is to keep a ver­sion of the tech­nol­o­gy around (for exam­ple, the installer pack­age for a game engine). Save it togeth­er with the project if you can. Aside from that, you should keep a basic instruc­tion for how to set up and com­pile a project. In this readme, record which ver­sion of spe­cif­ic pro­grams you’re using, a step-by-step guide in how to set up the project on a fresh com­put­er, and link oth­er impor­tant doc­u­men­ta­tion you’ve made (such as plan­ning or design docs).

And if you have pass­words for some­thing (like vir­tu­al machines or Android key­stores), don’t for­get to record those too. This is also impor­tant for games that are already released: ask your­self, what should I absolute­ly 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 moti­va­tion to work on it again, or that it is sim­ply left in the dust for­ev­er. On one hand, you’ll have to put in some effort to pre­serve a project that you’ve basi­cal­ly giv­en up on, which you might not have the moti­va­tion for. But, real­iz­ing that you want to revive a project, but com­ing back to the code it’s a mess? Or it com­plete­ly cor­rupt­ed in the mean­time? That will very like­ly dim any moti­va­tion you might have gained dur­ing your break.

There­fore, don’t be selec­tive about which projects to ice. Just ice ‘m all. 15 minute pro­to­types to near-fin­ished aban­doned projects, you should treat them all the same. You nev­er 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 mul­ti­ple breaks from a sin­gle project. Some­times, I’m only able to recov­er an ear­li­er ver­sion that I remem­ber last work­ing on. For exam­ple, when in 2020 I defrost a project I last worked on in 2019, I might only be able to find the old­er ver­sion from 2018 instead. This puts you in a tough dilem­ma: will I recre­ate the func­tion­al­i­ty from 2019? Or do I push the project in a dif­fer­ent direc­tion instead using the 2018 code? Or do I start over entire­ly? Or keep look­ing for the lat­est version?

Just this dilem­ma alone might cause you to give up defrost­ing the project com­plete­ly. So make sure that when you notice a wan­ing inter­est, you store the new­er ver­sion of the project, prefer­ably in the same place that the old­er ver­sion is in, and clear­ly label it with a ver­sion or a date so you can’t mix them up. (Don’t delete the old­er ver­sion though, see point 5.)

5) Don’t bury it

You might have so many unfin­ished projects across dif­fer­ent tech­nolo­gies that it becomes a mess to recov­er one, should time ever come to revive it. Or you might want to be able to steal some spe­cif­ic func­tion­al­i­ty, a spe­cif­ic part of a pro­to­type you want to reuse. Orga­ni­za­tion is key here: how would my future self attempt to recov­er this project? Try to be con­sis­tent with fold­er struc­tures, file names, and where you store projects and assets.

As for where to save the project for recov­ery, this is a tricky one. Since your project will like­ly be offline (on your local file sys­tem), stor­ing a copy in an online cloud ser­vice makes the most sense since it dou­bles as a back­up. But will the online ser­vice you use for this still be around next year? What about the next five years? Find­ing a reli­able per­ma­nent stor­age loca­tion is real­ly real­ly tricky in a world where tech­nol­o­gy is con­stant­ly changing.

As a last resort, you could remove projects to clean things up, but my rec­om­men­da­tion here is actu­al­ly to nev­er man­u­al­ly delete any project at all, if this is fea­si­ble for you. For all assets there’s a non-zero chance you might want to recov­er it in the future. I might be espe­cial­ly care­ful in this area, but do con­sid­er ask­ing your­self if you’ll absolute­ly might nev­er need the project in the future, before delet­ing it permanently.

6) Or release it anyway

In soft­ware a project is nev­er done: some­times the team runs out of mon­ey or time and is launched into the world regard­less of its com­ple­tion state. If a project is unfin­ished, you can always throw it on the web with a dis­claimer that it’s unfin­ished, and see what hap­pens. If it’s clear­ly unfin­ished, I’d add a dis­claimer that it’s a pro­to­type. This takes a cer­tain amount of brav­ery, but peo­ple might like it despite the fact that it’s unfin­ished (and of course, there are some peo­ple who like play­ing unfin­ished games for what they are).

But if it is already in some kind of playable state, you could con­sid­er releas­ing it as a nor­mal game with no dis­claimers at all. Now, at least you have some doc­u­men­ta­tion (a project page) and an exe­cutable of the project in an eas­i­ly acces­si­ble loca­tion. Final­ly, con­sid­er releas­ing the source project: this back­ups the source code, and in the rare case some­one 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 sin­gle text doc­u­ments. Some­times I also drop text files in Trel­lo cards on my pro­jec­t’s boards. For some of my games the source code fits in a sin­gle text file, so this is nice for those. Gist can also do host­ing & ver­sion his­to­ry for text files.

Github and Bit­buck­et are used to access to git and store larg­er projects. Git does a lot of things, but I most­ly use it to keep projects synced between my var­i­ous com­put­ers. But it’s also a ver­sion sys­tem, so you have back­ups for past ver­sions of your project. There’s a learn­ing curve, but it’s def­i­nite­ly worth inves­ti­gat­ing and goes a long way into solv­ing the prob­lems above.

I hope this post was helpful!

  or subscribe here!