I've been rummaging around in old backup CDs looking for a particular unfinished game project, the ancestor of the prime candidate for my next major game. I worked on this project - a kind of Chaos Overlords with flying saucers instead of crime - back in 2002. This was before I went to university and learned some slightly more "proper" programming languages, which meant I did the project in REALbasic.
RB could be best described as "sort of like Visual Basic for Mac". Charitably speaking, it was a useful rapid application development tool suitable for quickly creating simple GUI-driven programs, prototypes, and 2D games. If you were a Mac user in the early 2000s, you were more likely aware of it as "that horror responsible for a flood of badly programmed shovelware that would inevitably crash with a NilObjectException". That exception type was super-popular in RB not only because the language supported null (Nil) values, but also because its library functions used a Nil return value to indicate all kinds of failures. So unless you knew what you were doing and programmed very defensively, Nil values would creep into your data and eventually cause your program to crash.
But it was easy to get started in, not very expensive, and had a broad standard library. This made it understandably popular with hobbyist programmers like me.
So fast-forward to 2015, and I've just found the complete project folder of my saucer game on a gently scratched CD labelled "Backup 2002". I'd like to get the game running so I can take some screenshots. The plan is that when I start blogging in earnest about my next project, I can do a whole series of blog posts on its slow 15-year genesis. And maybe I'll even find some cool ideas I'd forgotten about.
The project contains a folder with a nice compiled copy of the game and all the data files, ready to run. Well, ready to run on Mac OS 9 running on PowerPC, a defunct operating system on a defunct CPU architecture. I have a machine with Linux and Windows 7 and a slightly creaky Mac from 2009 running OS X Leviathan Yosemite. So either I have to dig up or emulate a machine that can run the game, or I have to recompile for a modern OS.
I try an OS 9 emulation first, using SheepShaver plus a dubiously-legal machine image to start up an emulated OS 9 environment. I copy over the game folder and try to launch the game. Except that the game executable shows up as a generic file. This is when I remember about resource forks.
Explanation: right from the very first Macintosh operating system until the introduction of OS X, files would contain two "forks" - two separate repositories of data. The "data fork" was for storing arbitrary data, while the "resource fork" stored structured binary data.
This might seem like a weird complication, but it was actually pretty useful. Information in the resource fork was subdivided into numbered records of different types, with each type having a particular memory layout. Using the ResEdit tool or similar software, you could create and edit resource records. This was heavily used for storing GUI information like menus and window layouts, translation keys, and pretty much any information that was suitable for the format. In modern terms, resources were a high-performance fixed-schema non-relational database system with support built right into the OS.
My Mac didn't want to read the old backup CD, so I'd used my Linux machine to copy over the files. In the process, the resource forks had been stripped, removing vital information from the game executable and its data files, which themselves used resources quite heavily.
I ended up turning the entire CD into an ISO disk image and copying it over to the Mac to keep the resource fork intact. Now the game actually launched. It played one note of music, tried to fullscreen, and crashed the entire emulator. So short of buying an original model iMac off eBay, getting the game to run as is was a no-go - but perhaps it was possible to recompile the game for OS X?
Usefully, REALbasic is still around too, now renamed "Xojo" in a move vaguely reminiscent of the Blackwater/Academi/Xe rebranding. You can even get a 30-day trial for the Xojo IDE!
At this point I have to mention that REALbasic projects are stored as a single file in a proprietary format.
So I downloaded Xojo and succeeded in opening the project, only to find that all of the library functions for dealing with resource forks had been removed, making the game unable to load in its data. I started working on a work-around, but when I tried to save the project, Xojo told me that it had been actually unable to load in the full project, and saving would result in data loss. So without major re-engineering shading into re-implementation, recompiling the game for a modern platform was also impossible.
One final option remained: if I could find the version of RB I originally used, and run it under the OS 9 emulator, I might be able to recompile the game without the fullscreen behaviour that was crashing the emulator. But of course, you can't get old versions of REALbasic from anywhere. There used to be an FTP site for old versions back when it was still called REALbasic, but that's now defunct.
So with no way to run the game or recompile it, I gave up. I did find some concept art and some low-resolution screenshots I'd taken at the time, hidden away unlinked in a backup of an ancient version of my website, so I do have some pictures I can include in those future blog posts. But I'm disappointed I didn't get to actually play my prototype.
The analogy is probably pretty clear: like REALbasic thirteen years ago, Unity is also a development tool that's fully-featured, easy to get started in, and not too expensive. As with REALbasic, there is now something of a backlash against Unity shovelware - graphics bought from the asset store patched together with amateurish code and somehow rammed through Steam Greenlight for a quick cash-grab, crashy hobbyist and student projects, me-too games about zombies. There's also lots of really good and interesting games being made using Unity - and because it's only non-pro users that have to display the Unity logo at game startup, there's a fair number of bigger titles that are actually built on Unity without players being aware of it.
And like REALbasic, Unity heavily relies on proprietary file formats. The source code files are at least independent, but a lot of what makes an Unity game is encoded in proprietary scene and prefab files. As I showed at length in my anecdote above, proprietary file formats are very bad for game preservation. Now, as long as there's some version of Unity available, you can probably open up earlier projects and get them to compile after some mild cursing. But Unity won't be around forever. In thirteen years, it might be gone to the degree where we can't even launch the Unity IDE on modern computers anymore. And what happens then?
With Airships, which is written in Java, everything in the project is either a text file, a PNG image, or an Ogg Vorbis audio file. I'd expect that at least the first two can still be opened in many decades' time. And if you can somehow bodge together a cross-compiler, or translator, or virtual machine - whatever - that understands Java - you can compile and run the game. At worst, everything about the game is laid out in plain text, so you can at least study the code.
With an Unity game - not so much. You'd have to build specialized tools to read the various kinds of proprietary formats, and you'd have to accurately recreate the Unity engine and its understanding of those files. So my worry is that 20 years down the line, we might find that a lot of mid-2010's games are just gone - you can't get them to work again without a massive engineering effort, and a lot of their semantics are buried in unreadable scene files.
So if you want to preserve games history, what can you do about this? The saving grace of Unity might be that it's so popular that it will be worth finding ways to reanimate Unity games even in several decades' time. The hard bit will be identifying the point in time to start on conservation efforts. REALbasic didn't just wink out of existence from one day to the next. It lost popularity over time as the Mac-specific shareware and games market withered and the remaining developers switched to the new, nicer OS X APIs. Until now, fifteen years later, we find that part of history inaccessible, effectively vanished.
Something to keep in mind.