🕹️ DigiLiner Retro-Dossier: Diese Rezension ist Teil unseres zentralen MS-DOS-Archivs im Retro-Spiele-Katalog.
10. Dezember 1993. Mitternacht. Dallas, Texas.
In den Büros von id Software versuchten Jay Wilbur und John Romero verzweifelt, eine Verbindung zu einem FTP-Server der University of Wisconsin-Parkside (ftp.uwp.edu) aufzubauen [1]. In jener eiskalten Winternacht, als das öffentliche Internet noch in den Kinderschuhen steckte, saßen Tausende von Studenten und Systemadministratoren gebannt vor flimmernden Röhrenmonitoren und hämmerten ungeduldig auf die F5-Taste. Der Datenverkehr war derart gewaltig, dass der Administrator verbundene Benutzer zwangsweise trennen musste, um den Server vor dem totalen Zusammenbruch zu bewahren.
Pünktlich um 00:00 Uhr wurde ein komprimiertes Archiv von 2,39 Megabyte über die Datenleitung übertragen: 1doom1_0.zip [1][2]. Innerhalb weniger Minuten war die externe Bandbreite des Universitätsknotens restlos erschöpft. Das Campus-Netzwerk kollabierte vollständig.
In jener Nacht wurde nicht bloß ein neues Computerspiel veröffentlicht. Der triste, beigefarbene Bürorechner, der bislang brav in der Zimmerecke Rechnungen kalkulierte und Texte verwaltete, wurde mitten ins Wohnzimmer geschleudert – verwandelt in ein unbarmherziges Arcade-Monster.
⚡ DOOM (1993) Archiv-Steckbrief & Verifizierte Daten
Erste Wendung: Es war kein 3D; es war ein 13 Jahre alter mathematischer Trick
Anfang der 1990er Jahre erlagen alle, die DOOM zum ersten Mal sahen, derselben visuellen Täuschung: Sie glaubten, in eine echte dreidimensionale Welt zu blicken. Die Spielfigur sprintete, tauchte in Tunnel ab, stieg Stufen hinauf und bog um enge Winkel.
Doch was über den Monitor flimmerte, war kein echter dreidimensionaler Raum. Technisch betrachtet war DOOM eine kompromisslose 2.5D-sektorale Illusion [2].
In der Architektur der Engine konnte man keinen Raum direkt über einen anderen bauen ("Room-over-Room" war ausgeschlossen). Die gesamte Karte bestand im Grunde aus einem zweidimensionalen Grundriss. Jedem Sektor wurden eine Deckenhöhe, eine Bodenhöhe und eine Beleuchtungsstärke zugewiesen. Eine echte Z-Achse wurde nicht berechnet; eine zweidimensionale Zeichnung wurde lediglich vertikal nach oben und unten gestreckt [2][5].
Wie aber gelang es einem damaligen 486-Prozessor mit 33 MHz Taktrate, diese anspruchsvolle Szene mit konstanten 35 Bildern pro Sekunde zu berechnen?
Damalige Heimcomputer besaßen keine Hardware zur Tiefenberechnung von Pixeln (ein Z-Buffer existierte im PC-Bereich nicht). Die Speicherbandbreite war derart eng, dass das zweifache Zeichnen desselben Pixels (Overdraw) den Hauptprozessor augenblicklich blockierte [2]. Anstatt mit roher Rechengewalt gegen die Hardware-Grenzen anzukämpfen, vertiefte sich John Carmack in mathematische Abhandlungen.
Den Durchbruch fand er in einer wissenschaftlichen Arbeit von Bruce Naylor aus dem Jahr 1980: BSP (Binary Space Partitioning – Binäre Raumunterteilung) [5].
Carmack entwickelte eine binäre Baumstruktur, die die Karte bereits vor dem Spielstart in Hälften, Viertel und Achtel aufteilte. Bewegte sich der Spieler durch den Korridor, rasterte die Engine die Geometrie nicht von hinten nach vorn, sondern von vorn nach hinten. Sobald eine Wandspalte im Vordergrund gezeichnet war, wurden ihre vertikalen Pixel gesperrt; dahinterliegende Räume oder Gegner wurden vom Prozessor gar nicht erst berechnet [2].
Die Rechenkomplexität sank auf (O(N)). Auf einer NeXTstation-Workstation unter Objective-C von Carmack entwickelt, verlieh dieser Algorithmus einem gewöhnlichen 4-MB-DOS-Rechner die Leistungsfähigkeit einer professionellen Grafikstation.
Zweite Wendung: Das Zerschlagen der "Doom-Bibel" und der Konflikt der zwei Johns
Die Entstehungsgeschichte von DOOM war von einer tiefgreifenden weltanschaulichen Debatte innerhalb des id-Software-Teams geprägt.
Mitgründer Tom Hall hatte ein detailliertes, 120 Seiten starkes Spieldesign-Dokument verfasst: "The Doom Bible" [1]. Halls Entwurf sah vier wählbare Militärcharaktere namens Teague, Dimitri, Lorelei und Thi vor, angereichert mit umfangreichen Dialogen, Funksprüchen mit Stationspersonal und zu rettenden Forschern.
John Carmack legte den Entwurf kühl beiseite und sprach jenen Satz aus, der zur berühmtesten Anekdote der Branche werden sollte:
"Die Geschichte in einem Spiel ist wie die Geschichte in einem Pornofilm: Man erwartet, dass sie da ist, aber im Grunde interessiert sie niemanden." [1]
John Romero teilte Carmacks Ansicht vollkommen. Romero verlangte keine narrativen Briefings; er wollte James Camerons Aliens mit dem Splatter von Sam Raimis Evil Dead II verschmelzen, angetrieben von donnernden Heavy-Metal-Gitarrenriffs [1][3].
Tom Halls gemächliche, dialoglastige Konzeption wurde über Nacht verworfen. Tief enttäuscht verließ Hall das Studio und wechselte zu Apogee.
Nur noch zehn Wochen blieben bis zum anberaumten Veröffentlichungstermin, und die Hälfte der Level war unbrauchbar geworden. In dieser Notlage stieß Sandy Petersen – renommierter Autor des Pen-and-Paper-Rollenspiels Call of Cthulhu – zum Team [1]. In jenen verbleibenden zehn Wochen entwarf Petersen 19 legendäre Karten von Grund auf neu, während Romero den unvergesslichen Eröffnungslevel E1M1: Hangar modellierte [3].
Die optische Wucht des Spiels entsprang einem ähnlich greifbaren Handwerk. Statt Gegnerfiguren am Monitor mühsam zu zeichnen, bauten Adrian Carmack und Kevin Cloud Miniatur-Skulpturen aus Latex, Modelliermasse und Stahldraht (Spider Mastermind, Cyberdemon, Baron of Hell) [1].
Auf einem Drehteller montiert, wurden diese Modelle mit einer Videokamera aus acht Winkeln digitalisiert. Kevin Cloud scannte seine eigenen behaarten Unterarme und Schnittwunden für die Schlaganimationen des Doom Marine ein; die markante Schrotflinte war das Foto eines günstigen Spielzeugs der Marke TootsieToy aus dem örtlichen Kaufhaus [1][3].
Dritte Wendung: 2,39 MB legen Firmennetzwerke lahm und Port 666
Die Ausbreitungsgeschwindigkeit von DOOM spottete jeder klassischen Marketingplanung. id Software setzte auf das Shareware-Prinzip: Die erste Episode (9 Level von Knee-Deep in the Dead) war vollkommen kostenlos [1]. Den Spielern wurde geraten: "Kopiert dieses Spiel, gebt es Freunden weiter, ladet es auf Mailbox-Systeme (BBS)."
Zur eigentlichen Feuersbrunst wurde jedoch der von John Romero geprägte Modus: "Deathmatch" [1][3].
DOOM erlaubte es bis zu vier Spielern über ein lokales Netzwerk (LAN) oder zwei Spielern via Modem/Nullmodem, sich gegenseitig zu bekämpfen. Bis dahin waren Computerspiele einsame Gefechte gegen statische Algorithmen gewesen. Mit DOOM wandelte sich das Bild radikal: Der Gegner war keine vorhersehbare KI mehr, sondern der Studienkollege am Nachbartisch oder der Kollege am Ende des Büroflurs.
Die Konsequenzen in der Unternehmenswelt waren drastisch. Der Netzwerkcode des frühen DOOM übertrug IPX-Pakete unkontrolliert als Broadcast über das gesamte lokale Subnetzwerk [2]. Sobald vier Mitarbeiter ein Match starteten, fluteten die Datenpakete die Ethernet-Leitungen und brachten den regulären Geschäftsbetrieb zum Erliegen.
Konzerne wie Intel, Lotus Development sowie Universitäten wie Carnegie Mellon und Texas A&M verhängten strikte Spielverbote während der Dienstzeiten [1]. Systemadministratoren schrieben automatische Überwachungsskripte namens "Doom-Busters", die verdächtigen Datenverkehr aufspürten, Prozesse abbrachen und Netzwerkports sperrten.
Die Lage nahm solche Ausmaße an, dass sich John Carmack im Mai 1994 offiziell an die Internet-Standardisierungsbehörde (IANA) wandte. Jon Postel, einer der Pioniere der Netzarchitektur, prüfte den Antrag und wies DOOM einen dauerhaften, offiziellen Netzwerkport zu: Port 666 [4].
Wer heute auf einem modernen Linux-, macOS- oder FreeBSD-System ein Terminal öffnet und die Datei /etc/services aufschlägt, findet diese Registrierung bis heute unverändert vor [4]:
doom 666/tcp # DOOM Id Software doom 666/udp # DOOM Id Software
Hardware-Architektur-Vergleich (Standards von 1993 vs. 1994)
| Hardware-Komponente | Minimale Anforderung (1993) | Empfohlenes Idealsystem | Technische Funktion & Architektur-Rolle |
|---|---|---|---|
| Prozessor (CPU) | Intel 80386SX (25/33 MHz) | Intel 80486DX (33/66 MHz) | 32-Bit-Arithmetik und BSP-Baumabtastung verlangten den 386-Protected-Mode [2]. |
| Arbeitsspeicher (RAM) | 4 MB | 8 MB | DOS/4GW-Extender durchbrach die 640-KB-Grenze zur Zwischenspeicherung aktiver WAD-Daten [2]. |
| Grafikstandard | VGA 320x200 (Mode 13h) | VGA 320x200 (Mode 13h) | Lineare 64.000-Byte-Adressierung ermöglichte flüssige 35 FPS [2][5]. |
| Soundkarte | PC-Speaker / AdLib FM | Sound Blaster 16 / Roland SC-55 | Bobby Princes General-MIDI-Kompositionen erklangen auf Roland-Geräten in Studioqualität [1][3]. |
| Massenspeicher | 15 MB freier Festplattenspeicher | 30 MB freier Festplattenspeicher | Monolithische Archivdatei-Architektur (DOOM.WAD) [2][6]. |
WAD-Architektur und das moderne Erbe
John Carmacks weitsichtigste Entscheidung bestand wohl darin, das Spiel zweizuteilen: in DOOM.EXE (die kompilierte Engine-Logik) und DOOM.WAD ("Where's All the Data?" – Level, Texturen, Audio und Sprites) [2][6].
Carmack ermutigte Spieler ausdrücklich dazu, eigene Karten und Grafikpakete zu entwerfen. Diese offene Architektur begründete das erste massenhafte Modding-Ökosystem der Spielegeschichte. Innerhalb weniger Monate kursierten auf Universitätsrechnern privat gestaltete Star Wars-, Aliens- oder Simpsons-WADs.
Im Dezember 1997 stellte id Software den Quelltext der Engine unter die GNU General Public License (GPL) und sicherte dem Werk digitale Unsterblichkeit [6]. Heute läuft DOOM auf nahezu jedem Objekt mit Mikroprozessor – von intelligenten Kühlschränken und Digitalkameras bis hin zu Taschenrechnern und Monochrom-Displays ("Can it run Doom?").
Für Retro-Enthusiasten, die diesen Meilenstein heute in Reinform erleben möchten, bieten sich zwei bewährte Wege an:
- Das unverfälschte MS-DOS-Erlebnis: Ausführen der originalen
DOOM.EXE v1.9unterDOSBox-Staging. Vollständige 320x200-Pixelauflösung, CRT-Scanline-Filter und OPL3 Sound Blaster FM-Synthese. - Moderne Source Ports: Nutzung der originalen WAD-Spieldateien mit moderner 60+-FPS-Wiedergabe, Breitbildformat und präziser Maussteuerung über
Chocolate Doom(für exakte historische Wiedergabetreue) oderGZDoom(für moderne Beleuchtung und fortgeschrittene Mod-Unterstützung).
Vielleicht liegt die wahre Brillanz einer Engine-Architektur nicht darin, Hardware für das zu überfordern, was sie nicht kann, sondern jenen mathematischen Kunstgriff zu finden, der das, was sie kann, wie pure Magie erscheinen lässt.
Haben Sie Ihre ersten DOOM-Schritte mit den Pfeiltasten der Tastatur unternommen oder in jener Übergangszeit, als Sie zum ersten Mal die Maussteuerung konfigurierten? Und weckt das einsetzende Riff von E1M1 noch immer denselben beklemmenden Mars-Schauer, den moderne Multimillionen-Dollar-Grafiken kaum mehr erreichen?
📚 Verifizierte Quellen & Archiv-Referenzen
- David Kushner, Masters of Doom, Random House, 2003. (ISBN: 0-375-50524-5) — Die Gründertage von id Software, die Wisconsin-FTP-Mitternacht und Tom Halls Abschied.
- Fabien Sanglard, Game Engine Black Book: DOOM, 2018. (ISBN: 978-1099882319) — 2.5D-Architektur, Mode 13h VGA-Analyse und BSP-Baumoptimierung.
- John Romero, Doom Guy: Life in First Person, Abrams Press, 2023. — Entstehung des Begriffs Deathmatch, E1M1-Leveldesign und Bobby Princes Musik.
- IANA (Internet Assigned Numbers Authority), Service Name and Transport Protocol Port Number Registry — Offizielle Registrierung von Port 666 (TCP/UDP).
- Bruce Naylor, A Hash-based Method for Generating Multiresolution Spline Representations / BSP Trees, ACM SIGGRAPH. — Carmacks adaptierter binärer Raumunterteilungs-Algorithmus.
- id Software, DOOM Source Code Release (GNU General Public License v2), 1997 / 1999. — WAD-Paketstruktur und originale C-Quellcodes.
- MobyGames, DOOM (1993) Technical Specifications, Credits & Release History. — Verifizierte Mitwirkende und Distributionshistorie.
- The Doom Wiki & id Software Archive, The Doom Bible (Tom Hall Original Design Document, 1992). — Charakterkonzepte und verworfene Handlungsskripte.