I love building things. Tinkering. Creating something new.
Right now I’m working on re-doing the brick work on my house — the existing bricks having been in place for over 100 years. I find the process of re-laying those bricks profoundly satisfying.
It’s like a grown-up version of playing with Lego blocks. And, when I’m all done for the day, I know that the results will last. At least… probably for another 100 years or so.
But, with software, things are a bit different. Certainly far more short-lived.
In fact, most software is so short lived, that we, as developers, spend the majority of our time re-inventing the wheel.
Really, it’s even worse than that. We’re re-inventing the wheel that we, ourselves, have already re-invented several times.
Case in point.
I’ve been releasing software to the world since the mid-90’s. And, in that time, every application or game that I have made (with one or two exceptions) has had at least one “preference” that needed to be saved and stored between sessions.
How many times have I built (and re-built) classes and functions to handle reading/writing preferences to disk? I have absolutely no idea. Dozens. In C, C++, Obj-C, Basic, Java, PHP and Pascal. Add multiple platform frameworks (and revisions of those frameworks) on top of that… starts adding up fast.
Sure. Building functions for reading/writing preferences to disk isn’t the most challenging or time consuming task in the world… but every little thing adds up.
A specific example.
Over a decade ago I released a piece of CD burning software for MacOS X. Nothing terribly fancy or complicated, just a simple application that burned files to a CD.
Over the years that followed, that application needed to be updated approximately once every 4 to 6 months just to keep running. Even minor system updates (ala MacOS X 10.2.4, 10.2.3, etc.) broke things badly enough to make this little CD burner of mine stop working.
We’re talking about minor changing in an underlying platform causing forced obsolescence at least twice a year.
While this example is a tad extreme, the same problems hold true nowadays as well.
Host platforms come and go (how many of us are running AmigaOS as our main desktop right now?) and UI libraries change with the wind (how many GTK1 apps are you running currently?). There are, quite literally, thousands upon thousands of ways that (even seemingly minor) changes to a system will cause software to cease to function properly.
Is that bad? Do we really want to stop pushing things forward simply to keep old software running like a champ? Of course not. Progress is awesome. But the problem still exists.
And, when I build something, I want it to last. When you download (or buy) a piece of software… you want it to last too.
One of the big problems with DRM-ed content (games, media, etc.) is that we, as the consumers of that content, can’t be assured that we will continue to have access to it in the future. And that makes us grumpy.
But, in actual practice, the same effect is created when companies (or organizations/individuals) release updated versions of core libraries or systems that break backwards compatibility. Same effect, different purpose.
Ok. Great. So what’s the solution?
Oh, jeeze. I have no idea. The problem is obvious. The solution… far less so.
Many say that HTML/JS (ala “HTML5″) is the answer. To which I say:
“The same JS code barely functions similarly across current versions of a handful of web browsers… and doesn’t really work at all on browsers from just a few years back. And things are still in a state of flux. What makes us think that code that works today will work in 2 years?”
Others will point to interpreted, cross platform languages such as Java or Python. To which I say:
“Which version of Java or Python? Also which versions of the countless supporting libraries? Nope. Same problem.”
We could, of course, go back to just writing console applications. Do everything in C/ncurses and just call it a day. But…
“What about when executable formats change? Because they have. And they will. Going with something like C/ncurses reduces the total number of variables that could go wrong… but doesn’t eliminate those variables.”
Okay… so let’s focus on building languages and tools that are easy to port/update when needed! Cough:
“That solves one, small, part of the issue. This is something I’ve been focused on with Illumination and App-Make-inator for a few years now. High-level tools like this do make it easier to re-build apps when needed to work on newer systems. But they require the developers to rebuild. And they require the users to re-acquire. Which isn’t always possible. What happens 20 years from now when people want to play my games?”
You’ll notice a pattern here. Basically I’m shooting every (reasonable) possible idea down because it’s just not going to solve the problem.
The Most Ridiculous Solution Possible.
There *is* a solution. Select a platform, emulate that platform in a portable way, then only build for that platform. In order to make that work you need to pick a non-moving target that has already achieved the critical mass necessary to build and support a portable emulation system. Something like a Super Nintendo or DOS emulator.
That solves the problem. But then you’re limited to the constraints of those systems. In those cases that would be :
- No (or highly limited) networking.
- Memory and file size constraints.
- A lack of currently maintained modern development tools.
- No 3D acceleration (for the most part).
- Plenty of other issues I can’t even think up at the moment.
I went down the DOS route for one of my games. More just for fun than anything else.
Did it work for that? Yes. Yes, it did. And, to be honest, it would work for most of the types of software and games that I build. But would that sort of approach work for most software out there?
… probably. So long as it doesn’t need internet connectivity. Or 3D acceleration.
And, at least in the current world we live in, it seems like folks would far prefer a “native” experience on their platform of choice — which is a stance I totally get.
Then again… download numbers for Linux Tycoon for DOS are far higher than for all other platforms (including Windows and Linux). I posted some numbers in a rather tongue-in-cheek article. I find that notion humorous… but interesting.
Now, for making games in a retro style — which so many games use nowadays — I don’t see much of a reason to not build those games for SNES, Genesis, etc.. As they can then be bundled with emulators and sold in app stores and posted for download quite easily.
All of which is to say: I don’t have a good answer. But I’m wishing more developers built SNES and DOS games. Because then I could play those games 30 years from now with my grand-kids.