A long time ago I became infected with the idea that anyone should be able to appreciate my work. The fact that I describe this belief as an “infection” doesn’t mean I’ve been convinced wholly against it (quite yet). But, the point of this post is to delve into why that belief has severely slowed down my creative output, at least where game development is concerned.

My first serious gamedev projects started in 8th and 9th grade, right before the end of the era of XNA 4.0. Initially, I was working with Java during the off-times of my Java programming class, trying to make a text adventure and coming to the mind-blowing realization that my game code would have to structured in a giant loop. These were good times. I’d never heard of Version Control, so the code I was writing was likely saved in .java files that only existed on the computer lab desktop I tended to sit at. Occasionally I would put them on a flash drive if I wanted to move seats or show someone else. Maybe I even put them on Dropbox. The point of saying all this is to highlight how unportable and unsustainable my text adventures were. The only way to play them would be to acquire the source code from me directly and run javac and play at the terminal window. At the stage of just barely learning to make games, I was fully and completely unconcerned with packaging, distribution, or support. I knew no one would ever play my games, so it didn’t matter if it was all unsustainable spaghetti code without a platform to play on.

Microsoft XNA was my first step above that mindset. I entered my first Ludum Dare with a prototype in which you controlled a red square firing smaller red squares at green squares to earn points. (I think the theme was YOU ARE THE MONSTER and I called my game “Kill Butterflies.”) Other Ludum Dare participants were able to download the executable I generated and play it on their own computers. Before they could play it, they’d still have to run the XNA Redistributable installer to get XNA on their computers, and of course, they’d have to be running a Windows machine in the first place. But the game was technically kind of portable! The potential audience went from “people I met in class” to “anyone on the Ludum Dare community with a PC with XNA installed.” At the time I wouldn’t have thought about it in those terms, or even known what “portability” means for software. I had simply discovered XNA before any other graphical gamedev frameworks, so it’s what I used.

That mindset of building random games with whatever tools were at hand, launched a prolific time in my hobby gamedev career. My friend Will somehow implemented a component-oriented game library on top of XNA that represented a huge leap for our projects in terms of long-term code sustainability was concerned. We launched on a (give or take) year-long project called Space Hordes that we took far enough to publish for $1 on the Xbox Live Indie Games channel (a less popular, lower-quality marketplace than XBLA, famous at the time for launching Braid and Super Meat Boy on the same platform). Having a game I wrote run on my Xbox was simply an incredible experience. Reading/watching the negative reviews, not so much… but I will still proud to have created something worth critically demolishing in the first place.

Space Hordes never got a Windows release despite being compatible with the OS already. The code was still messy despite the virtue of component-oriented architecture, and no one was maintaining the game library Will wrote. He’d done it all himself, so I didn’t know enough to help in any way. I’m trying to paint a picture of a fundamental concept here:

Large amounts of closed-source code written by small, inexperienced teams will never be sufficiently portable.

Since we didn’t strike while the iron was hot and make a Windows release, our game pretty much can’t be played by anyone at this point. XNA is dead and XBLIG is discontinued, so no one can buy the Xbox build of the game, and if I remember rightly, we only sold like 42 copies (not even enough to get a payout!) so those 42 people are the complete audience of folks who could theoretically reinstall the game on an Xbox 360 and play it with 4 controllers how it was intended to be.

The fact that it was a local multiplayer game made it even less portable, come to think of it!

Digital content needs to be built on portable code, or it will be impossible to preserve for historical record, unless the content has market value.

Am I really sad that no one can play Space Hordes anymore? Of course not. (I mean, I might like to fire it up at a high school reunion a decades or two from now, but…) I only mention it because it illustrates a point about historical preservation of interactive digital art: if it’s written on closed-source libraries like XNA or Will’s component library, it will fade to the past once those libraries stop being profitable for Microsoft or whatever company is maintaining them.

Unless! Unless! Some other organization/individual comes along and ports the engine.

Sometimes people and teams will pop up with enough resources to port old libraries and runtimes that make it possible for old games to appear on new platforms. It’s one of the amazing things about open-source software. So, if I theoretically wanted to port Space Hordes, there’s still hope out there.

But I never meant this post to be about Space Hordes. It’s about The Whisperer in Darkness, a visual novel that I coded single-handedly on top of SDL2 and released for Windows, Mac, and Linux. A cross-platform game built on top of a stable open-source library? Portability at last!

But not quite. The thing is that SDL2 is a native library and when I released my game, I was personally compiling the source code (including an entire C++ library I called ASCIILib) on a computer running each operating system. For a solo hobby dev, owning a Mac, PC, and laptop running Linux all at the same time, was a situation I should have foreseen as unsustainable. Mac OS and Windows aren’t free, which is an outrageous proposition for me as a solo developer who hates both operating systems for personal use. Am I really supposed to keep buying Macs and the new version of Windows so I can support my cross-platform game? A game that didn’t even pay for its own development, and has pretty much stopped selling? That’s not gonna happen. If only there were anything approaching usable documentation on how to cross-compile SDL games. (If I’m missing something in that department, please send me a link,but it seems insurmountably complicated and more trouble than borrowing a Mac for a week or two.)

Native code is basically impossible for a solo dev to maintain cross-platform releases.

I’ve been sitting on the first complete translation of The Whisperer in Darkness game text for more than a year, grappling with how I can possibly push a stable patch without having my own Mac dev environment. And I know I could spend the money and get one, but that’s a losing proposition financially, and since I don’t actually work on a Mac, every time I need to build a new patch I’ll have to tangle with whatever random build-breaking updates Apple has pushed to Xcode. So we’re talking about a scenario where I lose money and personally suffer through a process I don’t enjoy. Repeated any and every time I need to update my game. That’s not sustainable.

So what am I left with? Porting the whole game to a non-native, cross-platform language. That probably means Javascript, which I’m not fond of either. I’m pretty sure Ink will be involved so I don’t have to reinvent all the narrative engine stuff I wrote in C++.

Wherever possible, build on top of well-maintained, Open-Source frameworks for long-term game portability.

I’m learning the hard way that every line of code I write is code I have to maintain, and I’m well aware that the most efficient way to get this job done would be to port to Unity, one of the most well-supported game engines of all time. It easily offers the same promise of stability that XNA did. So why not use it?

  1. I hate wysiwyg game editors unless it’s just for level design.
  2. Unity isn’t open-source. It seems unlikely now, but the company could fail and deprecate the library. Then my games would be back into the same limbo as XNA left them, waiting for the next MonoGame to pop up and save the day.
  3. Unity doesn’t run on Linux.

I’ve tried doing the responsible thing and working with Unity, and I just get so frustrated with it. I like writing code and I hate using heavy, non-free tools, so maybe I’m doomed to keep designing my own frameworks and then collapsing under the technical debt.

I meant to write more about plans for the Whisperer port, but got super sidetracked. I hereby declare this post a PART ONE.

—Nat

P.S. I realized halfway through writing this post that I omitted a substantial portion of my relevant gamedev experience: the years I spent obsessed with Spiderweb Software’s Blades of Avernum, designing custom scenarios for it in a graphical map editor and coding it all together in “Avernumscript.” Another great example of the learning experience I got from doing projects without portability concerns—BoA scenarios weren’t standalone games. They could only be run with a purchased copy of Blades of Avernum, a closed-source game which was basically unsupported by the time I got my hands on it. (Not to diminish how awesome it was.)

P.P.S. A lot of what I tried to convey in this post was stated better in a Patreon update by Ethan Lee who maintains FNA but that post appears to be gone now. If I ever find it, I’ll post the link.