[
Fabrice Lete, a developer at Fishing Cactus, warns of the problems that you may face when trying to exhume an old project, in this #altdevblogaday-reprinted opinion piece.]
Continuous integration and an automated asset pipeline should guarantee that you can produce an up-to-date working version of the game you are currently working on in very little time. And usually that pretty much works, besides the eventual “damn, old texture” self-note during demos.
But what happens when you have to exhume an old project? That usually doesn’t go that smooth, but why would you do that anyway? Here are a few reasons from the top of my head:
- To issue a patch long after the game has been released.
- To put back in production a game that was waiting for financing.
- To re-publish a game at budget price, or as a bundled freebie.
- To port an old game to a new platform.
- To use the old game as a sandbox for testing ideas.
And now here is a collection of things that can go wrong, all of which I have either experienced first-hand or was told about straight from the horse’s mouth; they relate to both personal and professional projects. But I want to stress that in all occurrences of the problems where it really mattered, we hopefully had clever people around who managed to sort it out, in sometimes very creative ways.
Where did we archive it again?
When someone tells you that in front of a large cabinet filled with CD-R and DVD-R with cryptic labels you know you are in trouble. Today, archiving stuff anywhere else than on hard drives and remote servers sounds funky. But ten years ago, affordable cheap external hard drives were not common and uploading gigabytes of data on the Internet was not practical for most of us.
Is it “game_00_final_test RC1” or “final_final_temp_GM backup”?
Did you notice the naming of everything gets less and less precise as a project approaches its deadline? And when files get copied around, the date stamp might not help anymore. Outdated sources are better than nothing, but do you remember how much critical stuff was changed at the very last moment? Was this backup done right after you fixed the “console hangs and catches fire at random” bug, or right before?
Physical mediums do not age well.
CD-R and DVD-R have terrible reliability and a very short life, cheap ones can become partially or completely unreadable in a matter of years. Magnetic tapes are better; I still have a few gigabytes of backups on QIC Data Cartridges and although I am quite confident the data is still there, getting the drive to work again might be a challenge. Hopefully, besides nostalgia I don’t really care about what is in there anymore; I keep it around to scare the kids when I’ll be rambling in my wheelchair at the hospice.
Old file formats.
Source code has always been text, that should not be too much of an issue. But what about project files? And what about art files? Especially 3D ones? Most computer graphics software has backward compatibility, but in practice something always goes wrong, requiring a lot of tedious work to fix. And when you have to deal with antediluvian versions, like a 3DS MAX 2.5 file or even older, things get messy.
How could that ever work?
Recent C++ compilers are a lot more standard compliant than what we had to put up with ten years ago. That also means they are better at catching errors and will refuse to compile invalid code that was tolerated by old compilers. They will also organize memory very differently, and an old buffer overflow without consequence will now wreck havoc in the most unlikely places.
We kept the libraries around, right?
You might get the game to compile, but it now has to link against an obscure video codec from 1995. At the time, getting access to that library was easy as pie. But now it’s a whole different story, since then the company that made the codec is gone, and it turns out that a lot of things are archived on the web, but not licenced libraries.
What about DRM?
I have a sword of Damocles on top of my head, an old accounting software still in production that I made using an obscure RAD tool from 1994. That tool uses a parallel port dongle and runs on Windows 3.1, and I never managed to crack this software. I didn’t have to touch it for the last 5 years, but I still keep an old computer with Windows 3.1 and a parallel port around, just for that. In some other cases of renewable licences, you simply cannot use your software anymore, good luck.
Who made that crap?
Having a fresh look at old code is a terrifying experience, especially when it is code that got through the legendary “final deadline hacking frenzy”. You can eventually swear and scream at the moron responsible for the mess, plan to get him fired and post some code on dailywtf to share your pain with the world, but often the culprit is yourself from a few years ago. That’s a humbling experience, but it only makes it more painful. Also, don’t count on remembering everything you need for your current project in a few years from now; things that seemed so trivial that nobody cared writing them down will be puzzling in a few years. It could also be that the only guy who knew some critical system inside-out now became a goat breeder up on a mountain without a decent Internet connection (such mountains exist).
Meet your old SDK.
Your SDK got a brand new feature X, and you got old game Y that was using that same SDK. Let’s integrate X in Y, that would be awesome! And now you have to port everything to the new SDK, and you can be sure it won’t be all about renaming functions. So be sure that everyone involved understands how much time and effort this will take, because from an external point of view it sure looks easy.
In conclusion
You might argue that my post is just a list of problems without a solution, and you would be right. You might argue that properly archiving a project (both data and knowledge) once it is completed or shelved should be done carefully, and you would also be right.
But I am quite sure every company has at least a few projects that were not carefully archived, or that seem to be but will prove the contrary at the first occasion. And if my post would serve only one purpose it would be to stress the fact that putting an old project back in a usable state can go wrong at so many levels that its cost should be carefully investigated. Especially because, once again, it looks so easy from the outside.
[
This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]
