Why adventure games from 1990 to 2010 still work

Two claims get made about old adventure games, and only one of them is a matter of taste.

The first claim is “the graphics are bad, so why bother”. The second is “they still run”. The second is the interesting one, because it is not about nostalgia — it is a statement about how the games were built and what kind of skill they asked for. Both have explanations you can check.

Reason one: the content was stored as data, not as video

A 1990s point-and-click adventure is mostly a driver for two things: a story graph and a set of 2D backgrounds with clickable regions. Scenes are images, dialogue is text, and the logic between them is a script. That structure is why the genre survived an entire change of operating system.

The most visible proof is ScummVM, a project that reimplements the engines these games ran on so the original data files play on modern machines. Its games page lists supported titles and a documented set of freeware games that are downloadable with the rights holders’ permission, and its compatibility page tracks which titles are known to work at the current release. A reimplementation of the engine, rather than an emulation of the whole computer, is only possible because the game and the engine were separable.

Compare that with a game whose content is baked into a platform-specific executable, or which depended on hardware that no longer exists. Those are the ones that need a full-machine emulator such as DOSBox — a perfectly good solution, but a heavier one, and one that reproduces the whole environment rather than just the engine.

Reason two: the skill being tested does not expire

The genre’s core loop is: read, look, try something, learn from the response. Progress is gated by understanding a puzzle, not by reaction time. That is why a player in 2026 can pick up a 1994 game and be genuinely competent within an hour: nothing in the loop degrades with age.

The Wikipedia overview of the adventure genre puts the design shift in historical terms — the genre’s Western popularity peaked in the late 1980s and mid-1990s, declined as first-person shooters took the audience, and saw a resurgence through indie development, crowdfunding and digital distribution. Read that as a statement about the market, not about the games’ mechanics. The mechanics did not stop working; the audience moved.

What actually does break

Being honest about the failure modes is what makes the “still work” claim useful:

• Resolution and aspect ratio. A 320×200 game on a 4K display needs integer scaling and a sensible filter, or it looks worse than it did.
• Audio. MIDI soundtracks depended on the listener’s sound card, so the same game can sound different depending on how it is played today.
• Controls. A game designed for a mouse and a verb list can be awkward on a trackpad, and some modern re-releases handle this better than others.
• Availability. The biggest one. Working engines do not give you the game files. Whether you can legally obtain a given title depends on the title — some are sold, some were released as freeware by their rights holders, and some have no route at all.

How to test the claim cheaply

Do not start with a 40-hour classic. Start with something short, taken from a source that tells you the legal status plainly:

1. Pick a freeware title that the rights holder released for public download, so availability is settled.
2. Run it through the engine that supports it, following that project’s own documentation.
3. Give it two hours. If the loop of read-look-try does not appeal, that is a real preference and worth knowing before spending money.

That is the honest version of “they still work”: the design and the data survived, the availability did not, and the fix differs per game.

Sources

• SCUMMVM — supported games list — the titles that remain playable and what keeps them running.
• SCUMMVM — compatibility list — the compatibility status of the older catalogue.
• DOSBox — the emulation layer that keeps DOS-era releases executable.