Project Archivability

May 30, 2011

PlayCrafter, an online videogame building site I helped build in 2007-2008, is now offline. (Project videos: Physics Puzzland, Matcheroo, Domino Shomimino). An effect of the site going offline is that the 130,000 videogames created on it are no longer playable, since the games referenced files and database entries on the server.

Of course, fortunately, PlayCrafter was created with beginning developers in mind. Due to its emphasis on learning game design, the projects lost were unlikely to be someone’s magnum opus. However the question of whether videogame projects developed will still be playable one month, one year, or one decade from now is a concern relevant to hobbyists and professionals as well.

Anything Networked or Rapidly Changing

In my post a couple of months ago about porting self-published iPhone/iPad games to Flash (web), I mentioned that when new iOS hardware comes out, and when new updates to the operating system are released, many existing applications are rendered unusable – on one or all device types – until manually updated. This has already happened a couple of times yearly since 2008. Ten years from now, for someone to try something I made on iOS, they might need not only an iPhone emulator, but support for switching between operating system versions. That doesn’t even graze the difficulties of making accelerometer data and the general form factor available to players everywhere.

A different type of complication, the sort found in the PlayCrafter case, is that many modern games rely on server information hosted by a central authority, with no legal or supported way for users to run dedicated servers. Most MMORPGs, Facebook games, and console online multiplayer are examples of this. In addition to requiring an active online community of players, which comparatively few games of these types succeed at keeping for extended periods of time (none of which can succeed at doing so indefinitely), if or when the business behind it needs to change directions the old experience ceases to be available.

For many types of games or businesses, this is unavoidable, or at least makes sense for now. That’s fine. I don’t mean to imply that all videogames need to last decades, only to highlight it as a recognized tradeoff for developers in such cases.

Media Archivability

Yesterday I watched Cecil Hepworth’s black-and-white silent film of Alice in Wonderland from 1903, which I found in a store that sold all varieties of classical music and film. That same day, a friend and I played Mario Kart 64 on a 15 year old N64. Later that night, I played through Super Mario Bros – though I used an emulator, which worked fine with a generic USB controller, my NES and its cartridges are still in fine and working condition. As far as my own projects, most of the DOS games I wrote in 1998 work with DOSBox.

Size can also be a prohibitive issue. Panzer Dragoon Saga is one of my favorite (semi-)turn-based videogames, however it came on 4 discs. While streaming Netflix and Hulu movies has become commonplace, downloading and mounting or burning 4 separate CDs is still (or has maybe gone back to being?) a relatively fringe, inconvenient activity. My copy is an old retail unit purchased used, but the Sega Saturn being somewhat rare hardware (1/3 as many Saturn consoles as N64s were ever sold), and the discs coming very late in the system’s lifetime (only 30,000 American copies produced), emulating PGS would be a more practical way to experience it. However file size differences have rendered emulation and rom collection significantly more complicated and involved for disc-based systems than for cartridge formats with their tiny files (NES: 45-800 kb each / SNES: 200 kb-4 mb / N64: 8-50 mb and so on).

In learning and discussing videogame design it’s nice to be able to go back and play seminal games, or even to study widely panned ones. As a personal matter, it’s enjoyable to go back and re-experience my old work. As a professional, being able to let potential employers, clients, or fans play past projects – rather than browsing screenshots or watching YouTube videos – certainly has advantages.

Emulation Layer

Emulation has kept old games from most systems playable, even now 20-30 years later. Instead of porting every game to every modern platform, the emulators are instead ported to major operating systems, and with that one stroke (virtually) all videogames for that classic hardware work on today’s machines.

If the videogame is written as a new rom for an emulated system (like the homebrew projects A Slow Year for Atari 2600 or Sack of Flour, Heart of Gold for NES), the videogame is automatically playable on every system with an emulator for that hardware. The downside to this approach is that the development for those old systems is extremely time consuming, and restrictive by modern standards. Old platforms lack support for modern file formats or tool chains, are tightly constrained in memory and processing power, are only capable of low screen resolution and poor audio fidelity, and so on. While those limitations can be appreciated by modern developers as creative constraints, or embraced as engineering challenges to gain historical perspective, they don’t lend themselves to rapid development or presentation styles amenable to today’s audiences.

Additionally, when old consoles are emulated, something is often lost in the translation between input devices – the old Atari dial (“paddle”) doesn’t feel nearly like playing with the mouse for analog input, and the crude 8-way digital joysticks feel a lot different than playing with keyboard arrows. Dual analog controllers often survive the translation, since so many USB variants are available (including drivers to directly use modern console controllers), but the N64 controller for example doesn’t translate well to most other input set ups.

Thinking of Flash as Emulation

Flash works like an emulation layer for hardware that never existed. This was, I believe, the intention of Java and the Java Virtual Machine, however the number, variety, and performance of Flash-based videogames compared to Java videogames speaks to the difference between software platforms in achieving that ideal. (Minecraft and RuneScape are prominent though few Java counterexamples to the tens of thousands of Flash SWF games at Kongregate. Remember that ActionScript 3 / Flash can be used for free without Adobe’s pricey Flash CS animation software. Additionally, Java is terrific for some purposes – server backend comes to mind – just not gameplay code.)

Flash is a format that runs mostly independent of the processor, operating system, or browser that opens it. The videogame will run at the same speed, with the same graphics quality (or sharper, if vector graphics were used), and since the content was already authored for keyboard and mouse input, it’s less likely to require rare or antiquated devices.

The team project I recently led, MechStrike, has been played 41,085 times in its first month online. In the process, the swf has been re-uploaded (by random other users) to 78 websites, making it likely to survive any given site going down. The numbers of daily players will likely dwindle, but I anticipate that well into the future when I want to share my (then) old 2011 work with someone, it will still come up in an internet search [Oct 2013 update: it’s still played on some sites, and now has over 121,000 plays]. The videogame has no external database or server dependencies, so even if it doesn’t come up in search, for whatever reason, I can e-mail a SWF to be played locally without much hassle, or simply mirror it myself.

Consider

Alongside how many people your game can reach now and in the near future, which are understandably often the dominant concerns, it’s worth giving some thought to:

How far into the distant future will your videogame projects likely be playable, even if only by emulator? How easily, cheaply, and/or conveniently?

Will it only remain playable if it is updated and maintained consistently over the years to keep up with changing platforms, APIs, libraries, operating systems, hardware, and so on?

Will an online server need to be kept running and properly maintained?

Will the original business or team that created it need to still be actively supporting the project for anyone to use it?

Will special or antiquated hardware likely be required to get the full experience?

There are of course no easy nor universal answer for these types of questions, especially without forfeiting a lot of opportunities that newer technologies make possible. It’s just something to keep in mind. There are videogames from 35 years ago that are still in playable shape in their original form, and there are also videogames from just last year that no one in the world will ever be able to experience again.

Just something to consider.



Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.




Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!



Leave a comment

Comments Form
  • Your email will not be used for any purpose other than to update you in replies to your comments. Your website address will be shown as a link from your name with your comment. Your profile photo is auto-magically provided by Gravatar.

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.