Emulation Basics: How Browser Games Preserve Gaming History
Console games have been kept alive by dedicated emulator projects for decades. Browser games face a similar threat of obsolescence — and similar projects are rising to meet it. Here is how emulation works and what is at stake.
Every time a technology platform dies, it takes its native software with it unless someone intervenes. When the Atari 2600 stopped selling in 1992, the games made for it became unplayable for most people within years — the hardware aged and failed, and the television connections changed. Emulator projects in the 1990s and 2000s ensured that those games survived in playable form, running on modern hardware that could pretend to be an Atari 2600 well enough to fool the software.
Flash games face the same problem, accelerated by a particular feature of the web: unlike physical cartridges, Flash game files exist on web servers whose owners might stop paying hosting fees at any moment. The obsolescence of the Flash Player plugin is only half the threat. The other half is link rot.
What emulation actually does
Emulation is the process of making one computing system behave like another. An emulator is a program that runs on modern hardware but presents a virtual machine that original software believes is the hardware it was designed for. When an NES emulator runs a Super Mario Bros. ROM file, the emulator intercepts the game’s instructions — instructions that assume a 1983 NES processor and graphics hardware — and translates them in real time into instructions that a modern CPU and GPU can execute, producing output that looks and sounds like the original.
The translation process is demanding in terms of software complexity but typically light in terms of modern hardware requirements. Emulating a system from 1983 is trivial for a 2020s processor running at thousands of times the original clock speed. Emulating a system from 2005 (like the PlayStation 2) requires more sophisticated techniques but is still very achievable on consumer hardware.
How Flash emulation works differently
Ruffle, the main Flash emulator, takes a different approach from traditional console emulators because Flash is not a fixed hardware architecture — it is a runtime environment with its own scripting language and rendering model. Ruffle does not emulate specific Flash Player hardware. Instead, it reimplements the Flash Player runtime in a new programming language (Rust), compiles it to WebAssembly so it runs in browsers, and then runs Flash .swf files against this reimplemented runtime.
WebAssembly is a binary instruction format that modern browsers can execute at near-native speed. By compiling Ruffle to WebAssembly, the developers made it possible to run Flash content in any modern browser without a plugin — the emulator itself runs as a web application, and the Flash game runs inside the emulator.
This is genuinely clever engineering, but it creates specific challenges. Ruffle has to correctly implement the ActionScript virtual machine, the Flash rendering model, the audio subsystem, and the file format — all from clean-room engineering by reading specifications and reverse-engineering behaviour. Each version of ActionScript (1, 2, and 3) has different characteristics, and the later versions are significantly more complex. This is why ActionScript 1 and 2 games work well in Ruffle today, while ActionScript 3 support is still developing.
The preservation challenge beyond the plugin
Even if every Flash game could be emulated perfectly, a large portion of them would still be at risk because the files themselves are disappearing. Flash game portals from the 2000s have been shutting down as their operators move on. When a portal closes without archiving its content, the .swf files go with it. If no one made a copy, the game is gone.
The Internet Archive has been aggressively archiving web content for decades, including crawling game portals and archiving .swf files. The Flashpoint project (maintained by BlueMaxima) has assembled an offline archive of over 100,000 Flash games and animations specifically for preservation purposes. These are not just playing experiences — they are cultural archives of a creative period that would otherwise be lost.
Why Flash game preservation matters culturally
The argument for game preservation sometimes gets dismissed as nostalgia. But the history of cultural output that gets preserved tends to be what subsequent creators learn from, reference, and build upon. The people who made the indie game explosion of the 2010s often cite Flash-era games as formative influences. The designers who built mobile gaming’s casual game genre came through Flash. The puzzle mechanics, the art styles, the design thinking of an entire creative period lived in those .swf files.
Losing them is not just a matter of players being unable to revisit childhood memories. It is a matter of cultural record. The same argument applies to any art form: we preserve films from the 1920s not because everyone wants to watch them tonight but because they are part of the record of what human creativity produced, and future creators will draw on that record in ways we cannot predict.
What you can do
If you have old Flash games on a computer somewhere — downloaded .swf files, a browser cache from a decade ago, games you saved for offline play — consider uploading them to the Internet Archive. The Archive accepts public-domain and freely shared digital content for preservation. Contributing .swf files that are not already in the collection is a direct contribution to the historical record of a creative period that deserves to survive.