The core games available from Dust Scratch Games are approaching 8 years old now. On modern computers, we tend to assume that software and games will still “just work,” but there are always caveats. I just learned this week that the native Linux builds for “Drew and the Floating Labyrinth” and “Unfinished – An Artist’s Lament” were broken, for example.
When I first prepared these (we’re talking around 2013 / 2014), 32-bit operating systems were still commonplace. My main computer ran Windows 8, and I was able to test Linux versions of my games through dual-boot or virtual machines (I used a 32-bit Ubuntu). I was able to get a friend to briefly test the Mac version at the time. And at the time, all three operating systems seemed to work fine (there were one or two minor issues that were fixed by omitting the feature; I think having a custom cursor icon was one of them).
But the default at the time was to compile for 32-bit. I think Unity might have had 64-bit at the time, but it was considered experimental, and generally not recommended, unless your game required the extra RAM or other benefits 64-bit allowed. So 32-bit I used.
And to this day, my games seem to run fine on Windows 10 64-bit. But I was surprised to learn, and then verify, that modern 64-bit versions of Ubuntu couldn’t open my games at all!
Technically, it appears to be possible for Ubuntu to run these older games. But you’d have to download some special x86 libraries, and true to the Linux way, exactly what to download or how isn’t clear for outside users. After doing this, I was briefly able to open one of my games, but only once… for some reason, it wouldn’t open again after that. Also, the old Unity3D resolution/input dialog window didn’t appear with this.
The other solution, which worked for a user who brought this to my attention, was simply to use WINE and the Windows build. Due to unrelated issues on my new development desktop, I can only use Ubuntu 18 and nothing newer, so I can’t verify that newer versions of WINE actually work. And this didn’t satisfy the purpose of having a native Linux build to begin with.
So I rolled up my sleeves, took out my old development PC from the closet, and tried to open my old project files in a slightly newer version of Unity3D. Everything was backed-up first, of course. I think we’re talking about Unity3D 5.0 to 5.3, the version my follow up game “True King” used. With all the changes made since then, I’m certain newer versions of Unity3D wouldn’t play nicely. In fact, I remember trying to upgrade the projects once to 5.3 years ago, but it crashed due to some memory issue. Even if it works, it takes a good hour or two to reimport everything.
Luckily, the project upgrade seemed to work this time… mostly. For some reason, one or two minor materials were corrupted and left at 0 KB. And a projector-shadow asset shader completely broke into something bizarre for one project (this was fixed by editing the shader code back to the old version), but worked fine in the other.
Anyway, this time I was able to compile the game for Linux with the “Universal x86 – x64” option, giving me a single build with both. And sure enough, it actually runs on 64-bit Ubuntu. I can wash my hands and be done with it now… except that resolution/input dialog window doesn’t save gamepad input properly, so only keyboard and mouse reliably work on Linux now. This reminds me of a touchscreen bug I found that was fixed with newer versions of Unity, only useful if I was able to properly upgrade to it; I’m assuming this gamepad-Linux bug was also fixed, perhaps by their decision to recently remove the dialog window altogether and force developers to maintain their own.
What was the point of all this?
One issue with selling old software and games is ensuring that it’s still compatible with newer operating systems. And this whole adventure proved that it’s still a modern issue. Linux is increasingly becoming viable for gaming, but this relies on using the latest upgrades to WINE (which made big leaps in the past 5 years), or at least making sure a native-build works with the latest drivers and features of Linux and its common distros. The Steam Deck just came out in 2022, and I’m eager to test my old games on its version of Linux (Steam OS and Proton). After this week, I only now realize that I might need to upload new versions to Steam.
Linux also seems to load games much faster than Windows does. At least, for me and my sprite-heavy games, it does. It’s very probable that Linux will surpass Windows in user-gaming-experience one day.
The issue is worse on Mac, now moving to the new M1 ARM-based architecture. I’ve heard that the operating system goes to great pains to ensure that older software can run on it, but I’ve also already seen cases where it doesn’t work at all. I have absolutely no idea if my games would run on those newer Mac’s, and I’m trusting that a user would be savvy enough to assume any software that hasn’t updated after 2020 won’t natively work with M1. Most of the Mac users I run into aren’t developers though, so savvy isn’t likely.
I wouldn’t be surprised if newer versions of Windows eventually break my games too. Windows 10 tries to include compatibility layers for Vista and XP, but these still don’t run any of the games I made back in high school or early university. The only solution would be to properly upgrade my old projects to newer Unity3D engine versions every 5 – 10 years… spending weeks testing and re-implementing things that break… which is difficult to justify for a small game that stopped making money years ago. And this is assuming that no other data in the projects gets lost due to time and data rot.
I might do this eventually, but for the time being, I do technically have 64-bit Linux builds of the two games. I’ll probably upload these to Itch.io in a few weeks, and I might update the Steam page too after doing a test with the Steam Deck. But the new builds were just to make them playable: those minor lost assets are still lost, and I’m not bothering to replace them. And I’m not fixing any of the other “bugs” or “unfinished features” for these games. I’m not a company that constantly updates a single product, and I prefer to focus on making new things. And that’s hard enough without distractions.
(This came to light after my games were included in a March 2022 charity bundle along with 900+ other games on Itch.io, to support victims of the invasion of Ukraine: https://itch.io/b/1316/bundle-for-ukraine . At the time of this writing, it raised over $5,000,000 with 4 days to go. Over 340,000 new players now have my games in their library, and Itch’s analytics specifically show my games have 2,500 combined new downloads. I expect more issues to come as people try them out. 🙁 )
