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.
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.
Anzeige
Romero beim Programmieren, 1996.
Commander Keen: Anfang von id Software
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.
Romero feierte in den 90ern Erfolge und programmierte mit einem kleinen Team Spiele in Rekordzeit.
(Bild: mfi)
Turbo-Modus ohne Burn-Out
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.
Erfolglosigkeit und World of Warcraft
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.
In diesem Zimmer entstand Commander Keen in Rekordzeit.
Die Programmierprinzipien nach John Romero:
Anzeige
(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)
Exklusive Tests, Ratgeber & Hintergründe. Unbegrenzter Zugriff auf alle heise+ Beiträge inkl. allen Digital-Magazinen.Exklusive Tests, Ratgeber & Hintergründe. Unbegrenzter Zugriff auf alle heise+ Beiträge inkl. allen Digital-Magazinen.