The Enemy of Art
On N64 programming, EULAs, digital media ownership, modern game design, the Analogue 3D and ModRetro M64, and constraints.
I grew up playing many well-known classics on the Nintendo 64: Super Mario 64, The Legend of Zelda: Ocarina of Time, Super Smash Bros., Goldeneye, Paper Mario, and several others. The N64 was a bit before my time; I was born in 1998, so by the time I was playing games at all, the GameCube (which I also later enjoyed) was already out. But I still had a number of years playing the N64 thanks to being the youngest of four, with older siblings who grew up with it.
The N64 shipped with the NEC VR4300: a single core, in-order execution, 93.75 MHz CPU. It was paired with the “Reality Co-Processor” (RCP), running at 62.5 MHz, for acceleration of audio and graphics computations. It supported 4 MB of RAM (later expanded to 8 MB with the Expansion Pak). Game cartridges for the N64 were, at most, 64 MB.
By today’s standards, this is incomprehensibly underpowered. You, the reader, in your pocket—or perhaps in your hand, while you read this—likely have at least four out-of-order execution cores, running somewhere from 2 GHz to 4 GHz. That’s something like 20-40 times more cycles per second than the N64’s VR4300, spread across 2-4 more cores. Each core is vastly more capable of higher throughput in doing useful work, given their out-of-order execution, deeper pipelines, new caching layers, and numerous other hardware optimizations that I’m not qualified to even attempt to explain. This magical device in your pocket also has 8 GB of RAM—three orders of magnitude more than what the N64 offered. It also can have something like 32, 64, 128, 256, 1024 GB of cold storage—several thousands of times larger than the N64 cartridge size.
Needless to say, computing technology has progressed in countless ways since the 1996 release of the N64. But the belief in the constant of progress over time is a privilege unique to modern civilization, and this belief can blind to concrete examples of regress over time.
Despite the aforementioned mind-boggling computing hardware advancements, there remains enormous love for the N64, and other old computing devices. The Analogue 3D, an FPGA implementation of original N64 hardware, released in 2025. Similarly, the ModRetro M64 (another such implementation) released in 2026.
It isn’t just the games—your pocket magic science fiction device, as well as your backpack and desk science fiction devices that I didn’t mention, have been capable of nearly accurate N64 software emulation for decades. And yet, people love the N64 so much that they recreated it, almost 30 years later!
I hope I’ve made clear that there is not much of a technical mandate for this. So why?!
Is it simply profiteering off nostalgia? That might be too cynical—somewhat more charitably, maybe Analogue and ModRetro themselves are indulging in nostalgia, and sharing that with their customers, who are doing the same.
There is truth to that. Everyone has fond memories from their childhood; nostalgia has a big advantage in commanding the heart. I, for one, am not immune to this.
But is it just that? I’d argue this is still too cynical and simplistic. It isn’t just nostalgia. Not all childhoods are equal. Maybe something of value was truly lost, and this is an example of people trying to revive and preserve it.
So, what was lost? Everyone’s essay on their love for their childhood console will be different. My feelings are best explained through contrast to modern systems. Or, in other words, perhaps I can explain my love by juxtaposing it with my hatred.
Regressions In Personal Computing & Gaming
Nobody Knows What They Program Anymore
I opened this post with a few characteristics of N64 hardware. I’d love to be as specific about your phone, laptop, or desktop, but I can’t. Neither can developers of software you’d like to run on those devices. Poor personal computing platform stewardship has led to platform heterogeneity. Users move around, and so developers must too—the market share cost of platform dependence has increased.
As a consequence, no developer wants to be tethered to, say, Microsoft, or to Apple, and so there is greater and greater pressure to build layers abstractly, such that they can be mapped to an x64 Windows computer, and also an Apple Silicon macOS computer, and also an ARM64 Linux computer, and also an Apple Silicon iOS phone.
This is, of course, possible, but not free. The cost is often estimated to be zero. It isn’t. Developers are more removed from hardware than ever, but the intervening layers—responsible for mapping an abstract program to a concrete platform—do not magically make the software performant, or well-designed, or, generally, good. In fact, developers caring about such layers less has seemed to result in precisely the opposite. Most developers no longer pay any attention to concrete characteristics of how their code will run, and on what—it is simply not economical to do so. The environments in which software is tested are largely unrelated to those in which the software will run for customers. So, those critical details simply fall into a state of disrepair.
Occasionally, extremely high-percentile teams will do an excellent job despite the additional constraints forced by platform abstraction. But because many software tasks are difficult problems, and because these constraints make those problems even more difficult, the population of programmers that do this has become proportionally smaller, meaning it happens much less often.
This has led to the strange contradiction of extraordinarily powerful computer hardware, yet extraordinarily slow and unreliable software—usually dramatically slower, and sometimes even less reliable than the equivalents several decades prior, running on vastly less powerful hardware.
PC game development provides several excellent examples. Because every hardware component on PC can vary, developers must contend with a combinatoric explosion of possibilities. This manifests technologically. For example, developers do not ship builds for every possible GPU. Instead, they translate high-level GPU shader bytecode into native low-level GPU bytecode on the user’s machine.
As a consequence, for many titles, the first time the player opens the game, they need to first wait for 20 minutes while shaders compile. Developers also can’t perfectly balance visuals and performance for every possible case—thus, the player often must also spend 20-30 minutes tweaking their game settings before they play anything.
They can do this while shaders are compiling if they’re lucky—the menus will only stutter and flicker. If they’re not lucky, the menus for tweaking settings will be unusable altogether.
This is an unacceptable experience.
To be clear, I don’t intend to blame application developers. Economic reality has led to this state. I only mean to point to negative characteristics of modern personal computing device development.
Nobody Owns Digital Media Anymore
Before the player has the exhilarating opportunity to download 100 GB and wait an hour before they can play a game, they first must quickly scroll through hundreds of lines of legalese, and click a box which claims that they read it all.
They don’t read it. I don’t read it. Nobody reads it.
What do these mysterious blocks of text actually say? Here are some examples:
Oh! I suppose if I had read those before playing, the taste it’d leave in my mouth would’ve made it a bit harder to have fun. That is, if I were going to have fun at all, because…
Many Modern Game Developers Hate Games And Their Customers
After spending several hours “buying” a game, downloading it, installing it, patching it, compiling shaders for it, and tweaking settings so that it works acceptably, the player finally has the opportunity to jump in and play—and by “play”, I mean sit through another hour of condescending tutorials and cutscenes—and by “cutscenes,” I mean lectures.
Congratulations on making it through the (first) humiliation ritual, player—now you have the opportunity to enter a strange and magical world—one where you can slowly follow an NPC around while they explain the plot’s exposition, and press buttons in a predefined sequence!
Don’t worry—if you wander off the path and press buttons in a non-predefined sequence, it will be super visually obvious how you can get back on track—maybe with a trail of glowing dots, or yellow paint, or some other completely inorganic visual detail. After all, how else will you hear more of the plot’s exposition?
If you’re really lucky, the plot will be a super relatable allegory about social issues! It’s a game, a film, and a historical and political lesson, all in one!
We’ll also make sure that any gameplay elements that we do have in the 100 GB you downloaded are carefully outlined in painstaking detail in a tutorial—we don’t expect you to discover such mechanics on your own, and that’s okay.
These tutorials are somehow ubiquitous, despite that the actual set of unique gameplay mechanics has grown smaller over time. Modern game production is done by hiring an enormous number of artists and script programmers, rather than engineers doing custom engine programming for a custom game design. Through art and scripting, prefab gameplay mechanics provided by enormous pre-built engines are visually or audially reskinned, but they remain—in terms of interactive value—identical.
This pattern of game design isn’t a pattern of game design. Put simply: games are about interactive systems—ones where the input sequence is not predefined. But modern “game” design often produces non-interactive experiences: charge the user for an experience where they hit exactly the sequence of inputs that we want them to. That is no longer interaction between player and game, but rather a predefined sequence with the “player” as a middleman, merely so that they might be manipulated in one way or another.
There is an apparent belief that players are too stupid to think critically or discover—so much so that much of the terrible written dialogue in a game is that of the player’s character internal monologue, obviously intended to tell the player what they should be thinking!
It feels as though many modern game developers are more interested in building marginally-interactive films than games. Unfortunately, while these “game” developers are not good game developers, they are not good film developers either, because they even ignore the classic film rule to “show, don’t tell”. Games are fantastic mediums for showing, and yet trivialities are communicated via cutscene dialogue.
This results, ultimately, in an insulting and uninteresting experience.
Everyone Is Online, Always
Internet connectivity has become nearly ubiquitous. While this is an incredible technological advancement with positive downstream effects, it has allowed game and software development culture to ignore local-first design altogether. As mentioned, this near-ubiquitous connectivity is used to restrict ownership (or, rather, enforce non-ownership) of games or software. Even for many single player games, a connection with a non-self-hosted server must be made.
In-person multiplayer experiences (local multiplayer on a console, like the N64, or LAN parties as two examples) have been deprioritized (if not abandoned) in favor of connection to centrally owned and operated—and eventually decommissioned—servers.
This connectivity is also used to update games without the player actively deciding to do so. It is common to hear players lament the passing of “seasons” in games they play—even if they preferred an old experience provided by an online game, that experience is indefinitely lost. Games have become ephemeral.
This means a player will pay for a specific experience, and it will be changed or eliminated. This is why the aforementioned hundreds of lines of legalese are required by these companies, because if they didn’t include them, they’d be transacting with most customers under false pretenses. The English word for this business practice is “fraud”.
Given that almost all customers don’t read nor understand the legalese, I’m not sure what’s happening is much better than that.
Furthermore, because companies can update game copies remotely, the standards for game releases have drastically dropped. A physical game release with no update path was final—players bought a disk or cartridge with the game contents, and those could never be updated. As a result, engineering and design standards for those game contents were extremely high—this also meant that they produced superior, lasting results, because once the cartridges were flashed, or the disks burned, there was no going back.
Reanimating A Simpler Time
While nostalgia is of course a factor, these regressions in computing and gaming are why I look back on the N64 fondly, and why I’m excited for the Analogue 3D and ModRetro M64. They’re reminders, and reanimations, of an era where:
Programmers knew what they programmed. Hardware was predictable and well-defined. Programmers were familiar with what their software would run on. Their local testing environments were representative of customer environments.
Players owned their digital media. Players physically owned cartridges, flashed with a final, immutable copy of a game. It couldn’t be arbitrarily modified or updated. They couldn’t have their access revoked.
Developers didn’t hate games nor their customers. Games included tutorials, cinematics, and plot, but didn’t insult players. They handheld players far less. Players were encouraged to explore and discover on their own. Gameplay mechanics were often experimental, unique, handcoded, and creative.
Local-first and offline experiences were prioritized. There was no Internet connectivity to the console, so multiplayer experiences were in-person. Games always ran locally, and were practically permanent.
For me, one of the most exciting aspects of the M64 is that, as part of its release, they’ve also partnered with developers and physically released new original cartridge games for the N64. I had a blast playing one of them recently on stream, Xibalba 64:
Dominic Szablewski, the developer, has an excellent blog post on technical details of the creation of the game. I highly recommend checking it out.
The Enemy of Art
The major downside to building for the N64 first in “current year” is, of course, that the aforementioned technological advancements are not available. A game must work within a much more constrained space.
But as soon as I put it in those terms, the famous Orson Welles quote springs to mind:
The enemy of art is the absence of limitation.
I can’t help but feel that computing power often acts like a carrot on a stick, luring developers, even if the experiences they want can exist on a simple and comparatively less powerful system, and with much less complexity.
And, as Welles’ quote suggests, perhaps the elimination of computing limitations is harmful for the creative process. Perhaps it causes analysis paralysis. Perhaps it diverts resources toward bottomless pits, which are unrelated to the main idea of a project—as an example, mindless investment into high-fidelity photo-realistic rendering in games, or into the production of decorative art assets, at the expense of gameplay development. In fact, it seems that high-fidelity photo-realistic rendering and decorative art assets would serve to calcify game designs, rather than harmlessly complement them.
It also seems that the most durable and permanent designs will be in this more constrained space. DOOM has been ported to a smart toothbrush!
Look no further than the retro development communities or the demoscene to confirm that the space of possibilities—even for, by today’s standards, extremely limited sizes, speeds, and hardware—is nowhere near fully explored.
As one example, earlier this year, a developer and Digital Grove community member known as Meese posted an impressive demo of his high-performance voxel engine, used to implement a Minecraft clone, running on the 1998 Sega Dreamcast.
Peter Schmidt-Nielsen responded:
This exchange and all of my surrounding thoughts have stuck with and inspired me.
We find ourselves in an age where the computing and gaming industries seem to be most interested in throwing money and millions of lines of code at problems, without regard for the first principles of what they’re doing. I’d posit that many high value things—things that most people won’t find—will be in unexpected places. They’ll require far fewer lines of code, far slower CPUs, and far less memory than expected.
I’ll certainly be looking.
If you enjoyed this post, please consider subscribing. Thanks for reading.
-Ryan
Been waiting for this one