GDC

John Romero: Von id Softwares Anfängen und World-of-Warcraft-Sucht

John Romero ist eine Entwicklerlegende und einer der Köpfe hinter Wolfenstein, Doom und Quake. Auf der Game Developers Conference enthüllte er die Programmierregeln aus den frühen Zeiten von id Software.

In Pocket speichern vorlesen Druckansicht 192 Kommentare lesen
John Romero: Von id Software und World-of-Warcraft-Sucht

Team um John Romero und John Carmack.

Lesezeit: 4 Min.
Inhaltsverzeichnis

Eines der Highlights auf der Game Developers Conference Europe war der Vortrag von Industrie-Urgestein John Romero, seines Zeichens Mitbegründer von id Software und einer der Köpfe hinter Wolfenstein, Doom und Quake – also all jenen Spielen, die das Genre der First-Person-Shooter begründet und entscheidend geprägt haben. Romero, der selbst seit Jahren keinen Hit mehr landen konnte, konzentrierte sich in seiner Präsentation auf die frühen Zeiten des Entwicklerstudios id Software und gab vor den anwesenden Entwicklern unter anderem id's Programmierregeln preis.

Romero erzählte, dass seine Faszination für Videospiele von Spielautomaten kam, folgend brachte er sich auf dem Apple II selbst programmieren bei und schrieb erste Spiele. Schließlich gründete er zusammen mit John Carmack, Adrian Carmack und Tom Hall die Firma id Software. John Carmack stellte sich schnell als extrem talentierter Programmierer heraus und entwickelte einen Smooth-Scrolling-Algorithmus, der schließlich in den Commander-Keen-Spielen zur Anwendung kam. Die ersten drei Teile von Commander Keen programmierte das kleine id-Software-Team in nur drei Monaten – und zwar weil Nintendo ihren Super-Mario-Klon mit der Technik ablehnte.

id Software war trotz der wenigen Mitarbeiter überaus produktiv. Allein 1991 habe man Romero zufolge 12 Spiele programmiert, "in einer Zeit, in der es keinerlei APIs gab". Romero beschrieb die Zeiten als pure Arbeit: Er habe sich sogar geärgert, das Programmieren für Toilettengänge unterbrechen zu müssen. Trotz der fanatischen Arbeitsweise und 16-Stunden-Tage habe es kein Burn-Out gegeben, da in der Arbeit ihr ganzes Herzblut steckte. Es folgten die Shooter-Meilensteine Wolfenstein, Doom und Quake, die ein ganzes Genre definierten. Innerhalb von fünfeinhalb Jahren programmierte ein Team von weniger als 10 Entwicklern 28 Spiele. Diesem "Turbo Mode" lagen elf Programmierprinzipien zu Grunde, die Romero während des Vortrags präsentierte.

Nachdem Romero id Software verließ, blieb der Erfolg für ihn aus. Auf diese Zeit und die möglichen Gründe für die Erfolglosigkeit ging der Entwickler nicht ein. Eine Zuschauerfrage nach seinem Lieblingsspiel könnte aber einen möglichen Hinweis liefern – zumindest für eine bestimmte Periode. Romero erwähnte nämlich World of Warcraft, was er jahrelang exzessiv spielte; nach eigenen Angaben werktäglich mindestens sechs Stunden und am Wochenende jeweils 12 Stunden – und das über Jahre.

id Software: Eindruck aus der Anfangszeit (5 Bilder)

In diesem Zimmer entstand Commander Keen in Rekordzeit.

(1) No prototypes. Just make the game. polish as you go. Don't depend on polish happening later. Always maintain constantly shippable code.

(2) It is incredibly important that your game can always be run by your team. Bulletproof your engine by providing defaults upon load failure.

(3) Keep your code absolutely simple. Keep looking at your functions and figure out how you can simplify further.

(4) Great tools help make great games. Spend as much time on tools as possible.

(5) We are our own best testing team and should never allow anyone else to experience bugs or see the game crash. Don't waste others' time. Test thoroughly before checking in your code.

(6) As soon as you see a bug, you fix it. Do not continue on. If you don't fix your bugs your new code will be built on a buggy codebase and ensure an unstable foundation.

(7) Use a superior system than your target.

(8) Write your code for this game only – not for a future game. You're going to be writing new code later because you'll be smarter.

(9) Encapsulate functionality to ensure design consistency. This minimizes mistakes and saves design time.

(10) Try to code transparently. Tell your lead and peers exactly how you are going to solve your current task and get feedback and advice. Do not treat game programming like each coder is a black box. The project could go off the rails and cause delays.

(11) Programming is a creative art form based in logic. Every programmer is different and will code differently. It's the output that matters. (mfi)