#preservation

Software preservation, archivization, and so on / 6 posts

Newsletter
  • Get a newsletter digest every Friday:
Contact

Send me feedback, tips, bug reports, and anything else:

About me and the blog

My name is Marcin Wichary. I’ve worked as a UX designer, typographer, front-end person, and manager at Google, Medium, and Figma. I’ve also written a book about keyboards and typing, gave talks, and published essays about design, typography, and technology.

Unsung is my blog about software craft and quality.

More info about Unsung

Send me feedback, tips, bug reports, and anything else:

More info about Unsung

“But, as we all know, the individual light bulbs are not moving.”

I linked to palette cycling before, and I was just reminded of palette cycling art by Mark Ferrari, who back in the 1990s made 30+ landscapes that looked like this:

They have been collected on this webpage some 15 years ago, and I’m linking to it in part because it’s also a great explainer of how palette cycling works – you can see the colors move around, you can point to one to see it frozen, and you can see multiple cycles running in parallel, compare palette ranges between different environmental conditions, and turn on a “blended” technique that feels clever and I didn’t realize existed.

The page was made by Joe Huckaby, who wrote a little intro:

Mark J. Ferrari […] invented his own unique ways of using color cycling for envrironmental effects that you really have to see to believe. These include rain, snow, ocean waves, moving fog, clouds, smoke, waterfalls, streams, lakes, and more. And all these effects are achieved without any layers or alpha channels – just one single flat image with one 256 color palette.

The launch was also accompanied by an interview with Ferrari, which is an interesting read – in part because it shows the work was even more elaborate than all of the above:

These versions of the scene are all the same piece of art ‘shifted’ to different palettes, and, in some cases, using additional ‘baked in’ overlays, (such as rain or the lighted windows at night). But those overlays are all ‘baked in’ to the same layer of the same piece of art that appears in any other ‘day-time’ or clear weather iterations, and are all deriving their color and motion from the same palette as the rest of the picture in that state.

While [the page above] finally allows us all to watch these images color cycle online, many of the scenes posted were actually ‘built’ to do much more than merely animate. By fading the one piece of art through whole sets of palettes, sometimes also using a very sparse set of ‘baked in’ overlays, a number of these scenes can go seamlessly through the 24 hour light cycle, and even change weather conditions ‘naturally’ and seamlessly in real time as you watch. I am not just talking about changing the brightness or color scheme of these pictures either. In the images built for it, over the course of ‘sunrise and morning,’ ‘morning to afternoon’ or ‘evening and sunset,’ light and shadow will actually gradually change angle, climb down the sides of things, move across lawns, up cliffs or building walls, as changing light does in life – all just by fading through palette series designed to make those things happen without altering or adding anything at all to the single layer of 8-bit pixel art.

Ferrari also suggests an interesting analog to palette cycling, which I quoted in the title.

Bonus: Ferrari’s animated landscapes were made for a new-age’y personal organizer app called Seize The Day, and on top of the above preservation effort, there is also this independent, extremely retro page from a fan of the app who loved it so much she decided to keep the app itself alive, too.

“If you aim for the king, you better not show up eight years late.”

Something different for today: a one-hour episode of a podcast A Life Well Wasted from 2025. (I can’t link to it directly, but it’s the most recent episode, called “Game Over.”)

It’s a human story whose beats might be familiar to some of you: a long software project that ultimately failed despite the enormous effort. And it did so in an industry – high-budget videogames – where failures might feel particularly brutal: the projects take multiple years but the defeat can be swift, the servers get shut down and the game instantly evaporates, and instead of employees being reallocated to other games, the studio gets disbanded and people let go.

There are some nice moments in the podcast’s interviews with about a dozen people, hearing about personal pride and responsibility, working together with others, and a certain camaraderie not just with other people, but with their software that develops:

I think the best part about it was being able to play with my coworkers and then cutting loose, and being silly, and really enjoying what we made together, as a unit. That experience alone made it worth it.

There are also questions about the management’s role in all of this – this part we might never get to know fully – and the worry about game preservation.

This is not mentioned in the podcast, but it seems widely understood the story is about Concord, a AAA live-service game that is rumored to have cost a staggering $400 million dollars and taken 8 years to develop, only to be shut down mere 12 days after its launch in the late 2024. (AAA means a blockbuster with highest budgets seen by the industry, and live service means a game like Fortnite, which is expected to make money over time from add-ons and upgrades.)

Learning about Concord’s macro view adds a lot of color to the boots-on-the-ground podcast above, but one has to be careful exploring it; the online discourse about the game felt similar to the 2016 reboot of the movie Ghostbusters where sure, the product might have been subpar, but also a lot of commenters seemed eager to arrive to the conversation carrying truckloads of bad faith, gatekeeping, and misogyny.

Some good articles? Keza MacDonald in the Guardian has a nice summary of the whole situation:

This is a brutal sequence of events. Sony bought the makers of Concord, Firewalk Studios, in 2023. Concord had been in development for eight years, and it was an expensive game, with bespoke cinematics and a long-term plan that would have cost $100m or more to develop. In its two weeks on the market, it sold fewer than 25,000 copies, according to estimates. This is a shocker, even compared with the year’s other bad news for developers and studios.

MacDonald also adds:

Speaking personally, I do not want a game that takes years to play. I want one with something to say, an experience to impart, and one that eventually ends. A game whose artistry comes before its business model.

This is partly a matter of taste. Self-evidently, there is an enormous market for live-service multiplayer games; it’s just that most of those people are already playing one. I highly doubt that there are untapped millions of players desperate for a hero shooter or battle royale game who just haven’t found the right one yet. It’s time that publishers try something new instead.

An article by Matt Kim at IGN adds to this notion:

With so many games now taking close to a decade from the beginning of development to release, we’re starting to see the financial and creative consequences of an overlong development cycle. Spend too much time in development and ideas that were once novel are no longer in vogue. Furthermore, the time and money spent over those years has to be recouped somehow, which leads to decisions like the $40 cost of entry for Concord when many of its peers are free to play.

The cost of coming late to the party means you must bring something new to the table. Unfortunately, Concord is neither particularly innovative nor content-heavy. That said, it does have a level of polish at launch that was often absent from its hero shooter peers when they were first released. Indeed, Concord’s weekly animation story drops are fully motion-capture, and Firewalk’s time spent on crafting its lore has helped secure Concord an episode of this winter’s video game animation anthology series, Secret Level.

But well-established hero shooters like EA’s Apex Legends launched almost bare bones and still managed to make a splash thanks to its intriguing central concept which combined hero loadouts with a battle royale match format. Valve’s Deadlock doesn’t even have finalized assets or art but has still caused a huge burst of excitement among the PC community, thanks to the way it changes up the classic 6v6 hero formula with its heavy lane-and-minions MOBA [Multiplayer Online Battle Arena—ed.] mechanics. By contrast Concord appeared with an all-too-familiar offering and, frankly, the time spent on finessing its presentation – the graphics, motion capture, performance, and so on – likely lead to a later release date which in turn meant it lost valuable time establishing itself among its peers. If it had been released four or five years ago, when the PS5 first came out, maybe its launch would have been an entirely different story.

I think this is important to quote on this blog that often talks about “finessing” and implicitly – or sometimes explicitly – about the value of taking time to get the details right. We can’t forget that there are such things as overdesigning and overproducing, and that ultimately there is no way to polish your way out of something that lacks a soul.

“It’s unclear how Sopwith escaped to the general public.”

Sopwith is a 1984 videogame made by David L. Clark for the original, seminal IBM PC model 5150. It sports the distinctive 4-color CGA palette and an equally distinctive PC speaker soundtrack.

It’s also one of the oldest videogames still in active development, and I was surprised how enthralled I was learning about it.

(First of all, you can play Sopwith in a browser. Choose “single player” and then “novice” first for the game to tell you about its unusual keyboard control scheme.)

The current maintainer of the effort is Simon Howard. He wrote about Sopwith’s interesting history; I appreciate this kind of approachable and caring preservation of obscure titles. The history is worth a read.

From that, I learned a fascinating factoid. The game was intended as a demo for networking hardware, and the original author didn’t realize the game was “in circulation” for many years:

Intended as a trade-show demo, it’s unclear how Sopwith escaped to the general public. David L. Clark didn’t even discover until around 2000 that it had “gotten out”. Little did he know, Sopwith had been circulating for years in collections of early games for the IBM PC. Only a couple of years after the first version was released, ads were appearing in magazines like PC Magazine advertising Sopwith for sale as part of collections of games for the IBM PC

The modern edition started by Howard is called SDL Sopwith (SDL being a cross-platform graphics library):

SDL Sopwith is directly derived from the source code to the original DOS versions, and still includes changelog comments that date all the way back to 1984.

What I particularly liked about the contemporary Sopwith is its guiding document/​philosophy page, also worth checking out in full. Here are some choice principles:

  • Sopwith has a long history that deserves to be honored and preserved. By default, the game should always play like the original DOS version. That means the gameplay in particular should be the same, without any significant differences. Someone who has just discovered the project should find it to be a delightfully accurate recreation of the game they may have played when they were younger. […]
  • Some new features can be enabled by default, as long as they are subtle, unintrusive, carefully considered and can be turned off. An example is the medals feature.
  • The game will never try to be “something it’s not”. This means that it will always have four color CGA graphics, PC speaker sound effects and a low resolution display. It will never add (for example) hi-res sprites or 3D models, digital sound effects or MP3 music. The goal is to be “a great old game” rather than “a mediocre modern game”.
  • New features should be fun and recognize the comical aspects of the game. Features should be carefully considered before being incorporated, not just added arbitrarily and thoughtlessly.

There is something in all this that I feel a lot of software could learn from – not just vintage games. I appreciated Howard being thoughtful about growing Sopwith without forgetting its roots, but also with understanding that some things have changed since 1984. You could imagine remixing “The goal is to be a great old game rather than a mediocre modern game” to something like:

Better be a great focused app than a mediocre sprawling app.

Lastly, how did I learn about Sopwith? Howard shared this charming installation visual with me:

Frozen in time

A few readers wrote in response to me sharing Panic’s blog to say that they witnessed online publications doing the same.

Here’s a 1993 essay by William Langewiesche from The Atlantic Online (sic!) that’s still on the web – which, by the way, you should read because it’s really great writing – juxtaposed with a screenshot of a 2026 Atlantic essay on the same machine:

Likewise, here is a BBC News article from 1997, and another one just from today:

I do see those as something different, though. The old articles here are basically preserved as they were, which you can tell by the tiny images, pixel fonts, narrow widths, and so on. They’re likely the output of contemporaneous CMS frozen in time, functionally equivalent to a “Save As…” command.

This is better than those articles disappearing altogether, and better still than them being carelessly converted in bulk to a more modern CMS, resulting in formatting mistakes, broken images, and missing context. But what I appreciated about Panic’s approach is that it felt unified with the rest of the blog. In a way, it was less like preservation “as is” and more like “remastering” – ask any Star Wars fan about the difference – with slight updates to fonts, more thorough integration, and thinking about readability on smartphones that didn’t exist in the 1990s.

Of course, compounding the difficulty of online preservation, “as is” in the computer realm doesn’t really exist; even The Atlantic Online’s 33-year-old HTML is served using modern fonts via crisp and tiny pixels 1993 would die for – but even if it’s increasingly more and more possible, you also probably wouldn’t want to emulate an old, flickering CRT and Internet Explorer 3 to read it. On the web, just like elsewhere in computing, you truly can’t go home again.

Thanks to Phil Gyford for a few examples.

“Don’t entangle emulators in infringement events that are visible from space.”

A funny and occasionally spicy 15-minute video by Nerrel from October 2024 about some of the nuances and legal fights surrounding Nintendo’s fight with community-made emulators:

The video paints Nintendo in the harsh light, highlighting their double standards and willingness to throw their corporate legal weight around just to squash the challenges before they go to court, despite court precedents ruling against them.

The video also talks about software preservation – this is the part that feels very important to me – and I also learned things about piracy, DCMA, and modern video game encryption.

Just to highlight the versatile value of emulation, in another corner of the emulation universe, I found this fascinating project: a web page called Yes we scan, made by George MacKerron, that promises scanning directly from the browser – for example if you have an old scanner unsupported by your modern OS.

And… it actually works! It combines WebUSB with an interesting technique:

Your web browser emulates a whole PC running Linux with open-source scanning software (SANE). It connects that to your scanner via WebUSB.

If you are interested, the details page has more… well, details. MacKerron also wrote Printervertion that allows you to print directly from web, too, even if your operating system abandoned your vintage printer. The way I understand this, both efforts basically invite an alternative operating system that might be more supportive to take a stab at scanning or printing, and do it in a friendly and sleek way through emulation. It’s kind of incredible this is even possible.

“They even thanked the coders for giving them such a difficult challenge.”

A 12-minute video from Tech Rules about how the 2000 PlayStation game Spyro: Year of the Dragon dealt with software piracy:

The video extends upon a 2001 Game Developer article by Gavin Dodd, but Tech Rules adds a good intro about PlayStation’s modchips, and then actually shows the piracy protection in action.

I’m not going to spoil the surprise. Am I fully supportive of the approach? Not sure. PlayStation’s region protection complicates my feelings, and any sort of DRM-esque approach eventually backfires when it comes to software preservation. But you can’t deny what Spyro developers did is a really fascinating and weird approach.

The quote in the title of this post refers to the hackers who eventually did conquer the Spyro’s copy protection system. I guess – and I apologize in advance – game recognize game.