Bobby Prince, the man who scored Doom's E1M1, has died

What happened

Robert C. 'Bobby' Prince III, the composer behind the soundtracks to Doom, Doom II, Wolfenstein 3D, Duke Nukem 3D, and Commander Keen, has died. The news surfaced via a Legacy.com obituary that hit the front page of Hacker News at 273 points, with hundreds of comments from developers who grew up with his work humming out of OPL2 chips and Sound Blaster cards.

Prince was a lawyer by training who switched to game audio in his 40s after meeting Tom Hall and the early id Software crew through Apogee. He worked as a contractor, not a staff composer, and the catalog he built between roughly 1990 and 1996 is the soundtrack to the entire shareware-era FPS boom. If you can hum 'At Doom's Gate' (E1M1) without thinking, that is Bobby Prince's work, written on a deadline against a Roland SC-55 with Cakewalk on a 386.

The details that surfaced in the HN thread are the kind practitioners care about. Prince composed the Doom soundtrack in roughly six weeks. He delivered MIDI files — not audio — because the game had to render them through whatever sound card the player owned: AdLib, Sound Blaster, Gravis Ultrasound, or the high-end SC-55 he composed on. The infamous similarity between several Doom tracks and Slayer, Pantera, and Alice in Chains riffs was, by his own later admission, intentional 'in the style of' work — id's Bobby Prince and John Romero both wanted thrash energy, and licensing was not on the table.

Why it matters

There is a generation of developers — broadly, anyone who shipped code before 2005 — for whom Prince's music is not nostalgia. It is the operating environment they wrote software in. The Doom soundtrack is the most-listened-to piece of background audio in the history of the programming profession, and that is not hyperbole.

But the technical story is more interesting than the cultural one. Prince was working under constraints that no modern game composer faces, and the constraints shaped the sound. The total size budget for all of Doom's music was a few hundred kilobytes of MIDI. There were no streamed audio tracks, no Wwise, no FMOD, no adaptive layering. The synthesis happened on the player's machine, in real time, on chips that cost the OEM under a dollar. Prince's job was to write music that would sound coherent both on a $40 Sound Blaster 2.0 — running Yamaha OPL2 FM synthesis with a handful of operators — and on a $500 Roland SC-55 with proper sample-based wavetables. That is a much harder constraint than 'make it sound good,' and most modern audio middleware exists precisely so nobody has to think about it again.

The HN comments reflect this. The top thread is not about Doom the cultural artifact; it's developers swapping notes on MIDI patch banks, the General MIDI 1 spec, the GUS's patch-loading workflow, and how Prince's choice of program numbers shaped how the music degraded gracefully across hardware tiers. One commenter notes that Prince explicitly avoided drum patches above GM channel 10 because of inconsistent mapping on lower-end cards. Another points out that the Doom MUS format (a stripped variant of MIDI) was authored partly around Prince's compositional habits — id's audio engineers and Prince co-designed the file format and the music together.

Product Hunt energy and modern indie-game pitches tend to treat 'constraints breed creativity' as a marketing line. The Prince catalog is the boring version of the same thesis. Six weeks, a MIDI sequencer, a 1MB ROM-sample synth, and a brief from John Romero produced a soundtrack that has outlived three console generations and is still being covered on YouTube weekly in 2026. No middleware. No iteration loop with a creative director. Ship the .MUS files, move on.

What this means for your stack

Probably nothing direct — unless you work on audio, in which case the lesson is sharper than the obituaries suggest. The Doom approach (deterministic synthesis from a tiny score file, rendered on-device) is quietly making a comeback in web and embedded contexts where shipping 40MB of streamed audio is a non-starter. The web-audio world has been rediscovering tracker formats, Soundfont rendering, and tiny synth engines for the same bandwidth reasons that drove the original constraint.

If you maintain a retro engine, a source port (GZDoom, Chocolate Doom, EDuke32), or anything that touches MUS/MIDI playback, Prince's compositional choices are encoded directly into the assumptions your code makes about channel allocation, patch numbers, and tempo ranges. The 'sounds wrong on my synth' bug reports that ports get every year are usually downstream of decisions Prince made in 1993 to dodge a specific AdLib quirk. Worth a re-read of the source ports' MIDI handling code if you're shipping one — the original author of the data is no longer reachable for clarification.

For everyone else, the takeaway is mundane and useful: the highest-leverage individual contributors in software history were often contractors with a narrow brief, a short deadline, and total ownership of one slice of the stack. Prince was not on id's cap table. He was a freelancer who took a check, delivered .MID files, and left. The output outlived the company structure that produced it.

Looking ahead

The Doom soundtrack is in an unusual legal state — id has historically been permissive about source-port use, but the music's licensing has been quietly murky for decades, partly because of the 'in the style of' question. Prince's death will likely force some clarity there, either through estate action or a formal release. In the meantime, the back catalog will keep playing on every Doom port, every speedrun stream, and every retro-FPS YouTube essay — which is the rare case of a software artifact whose half-life genuinely measures in decades.