Von Patrick Wyatt(2012)
*Übersetzung: Chris „Eredalis“ Vogler
Vor langer, langer Zeit, als PC-Spiele noch für das Betriebssystem DOS geschrieben wurden, durfte ich an einem Spiel namens Warcraft mitarbeiten.
Ich durfte ein Projekt leiten!
Ich hatte zwar mehrere PC-Spiele, ein paar Mac-Spiele und sieben Konsolentitel für Super Nintendo und Sega Genesis entwickelt, aber entweder hatte ich bei diesen Projekten nur eine untergeordnete Rolle inne, oder es handelte sich eher um „Portierungen” als um originäre Entwicklungsarbeit. Eine „Portierung” ist der Prozess, bei dem ein Spiel von einer Plattform, wie beispielsweise Amiga, auf eine andere, wie beispielsweise Nintendo, übertragen wird, wobei der Code, das Design, die Grafiken und andere Spielelemente so umgewandelt werden, dass sie auf der neuen Plattform funktionieren.
Meine Rolle umfasste zwei Aufgaben: die Leitung des Entwicklungsteams als Produzent – ein Begriff aus der Spielebranche für Projektmanager, Designer, Evangelist und „Katzenhirte“ – und das Schreiben des Großteils des Spielcodes als leitender Programmierer. Damals, als ein Spielprojekt vielleicht zehn oder zwanzig Entwickler beschäftigte, war das vielleicht weniger einschüchternd als heute, wo Entwicklungsteams mit zweihundert oder mehr Entwicklern die Waage kippen.
Der Ursprung von Warcraft
Die Entwickler des Start-up-Unternehmens, für das ich arbeitete – damals noch unter dem Namen Silicon & Synapse, später jedoch in Anlehnung an unsere stürmische Entwicklungsmethodik in Blizzard umbenannt – spielten in ihrer Freizeit sehr viele Spiele. Und aus diesem Spielen entstand die Idee, Warcraft zu entwickeln.
Wir wurden dazu inspiriert, Warcraft zu entwickeln, nachdem wir ein Spiel namens Dune 2 von Westwood Studios gespielt (und wieder und wieder gespielt) hatten. Dune 2 war wohl das erste moderne Echtzeit-Strategiespiel (RTS) mit einer scrollbaren Weltkarte, Echtzeit-Einheitenbau und -bewegung sowie Einzelkämpfen. Es unterscheidet sich in seinem Design nicht wesentlich von einem modernen RTS wie Starcraft 2, abgesehen vielleicht von einer gewissen Größe und Grafikqualität.
Sein Vorgänger, Dune 1 – selbst ein sehr sehenswertes Spiel – hatte einige der gleichen Elemente, aber sein Semi-Echtzeit-Einheitenkampf war in ein Abenteuerspiel eingebettet. Dune 2 verzichtete auf die Idee seines Vorgängers, dass der Spieler einen Charakter innerhalb der Spielwelt darstellt, und konzentrierte sich ausschließlich auf die modernen RTS-Mechaniken: Ressourcen sammeln, eine Basis aufbauen, weitere Ressourcen sammeln, eine Armee aufbauen und schließlich den Feind finden und besiegen.
Zusammen mit den anderen Mitarbeitern von Blizzard spielte ich Dune 2 ausgiebig in den Mittagspausen und nach der Arbeit, wobei ich jede der drei konkurrierenden Rassen spielte, um ihre Stärken und Schwächen zu ermitteln, und anschließend Spielstile, Strategien und Taktiken mit anderen im Büro verglich.
Das Spiel machte zwar großen Spaß, litt jedoch unter einigen offensichtlichen Mängeln, die dringend behoben werden mussten. Vor allem konnten meine Freunde und ich das Spiel nur gegen den Computer spielen. Es war offensichtlich, dass dieser Spielstil ideal für ein Multiplayer-Spiel wäre. Im Gegensatz zu rundenbasierten Spielen, bei denen jeder Spieler warten muss, bis alle Gegner ihre Befehle zur Bewegung der Einheiten erteilt haben, würde ein Echtzeit-Spiel es allen Spielern ermöglichen, gleichzeitig Befehle zu erteilen, wodurch schnelle, entschlossene taktische Bewegungen gegenüber langwierigen strategischen Planungen im Vordergrund stehen würden.
Mit diesem einzigen Ziel vor Augen begann die Entwicklung des Spiels, ohne dass ernsthafte Anstrengungen unternommen wurden, das Spieldesign zu planen, die technischen Anforderungen zu bewerten, einen Zeitplan zu erstellen oder das Budget für das erforderliche Personal zu kalkulieren. Nicht einmal auf einer Serviette. Bei Blizzard nannten wir dies den „Businessplan du jour”, was unsere Standardarbeitsmethode war.
Anfängliche Entwicklung
Als einziger Entwickler des Projekts und ohne Art-Team in der Anfangsphase habe ich Screenshots der Grafiken von Dune 2 gemacht, um sie so lange zu verwenden, bis mein Fortschritt ein oder zwei Grafiker rechtfertigte. Die Grafiker waren mit einer Reihe anderer dringender Termine beschäftigt und brauchten zu diesem Zeitpunkt keine Ablenkung – wir standen immer unter Zeitdruck.
Zu meinen ersten Programmierarbeiten zur Entwicklung der Spiel-Engine gehörten die Erstellung eines kachelbasierten Scroll-Map-Renderers, eines Sprite-Renderers zum Zeichnen von Spiel-Einheiten und anderen Bitmaps, einer Sprite-Sequencing-Engine zur Animation von Spiel-Einheiten, eines Event-Dispatchers zum Posten von Maus- und Tastaturereignissen, eines Game-Dispatchers zur Steuerung des Verhaltens der Einheiten und einer Vielzahl von Benutzeroberflächen-Codes zur Steuerung des Anwendungsverhaltens. Nachdem dieser Teil des Projekts in den ersten Wochen abgeschlossen war, konnte man bereits ein Solo-Spiel „spielen“, obwohl ich die Einheitskonstruktion erst etwas später implementierte; zu Beginn musste man noch Befehle eingeben, um Einheiten auf dem Bildschirm zu erzeugen.
Jeden Tag baute ich organisch auf den bisherigen Bemühungen auf. Ohne Zeitplan oder externe Triebkräfte für das Projekt befand ich mich in der beneidenswerten Lage, selbst entscheiden zu können, welche Funktionen als Nächstes entwickelt werden sollten, was mich unglaublich motivierte. Ich hatte bereits Spaß an der Spieleentwicklung, und diese Greenfield-Programmierung war wie eine Droge für mich. Selbst jetzt, rund 22 Jahre nach meinem Einstieg in die Spieleindustrie, liebe ich noch immer die kreativen Aspekte der Programmierung.
Die erste einzigartige Funktion: Auswahl mehrerer Einheiten
Eine Funktion, auf die ich besonders stolz war, war die Auswahl von Einheiten. Im Gegensatz zu Dune 2, bei dem der Benutzer jeweils nur eine Einheit auswählen konnte und hektisches Mausklicken erforderlich war, um taktische Kämpfe mit mehreren Einheiten zu initiieren, war es offensichtlich, dass die Möglichkeit, mehr als eine Einheit auszuwählen, den Einsatz von Task Forces beschleunigen und den Kampf im Spiel dramatisch verbessern würde.
Bevor ich in der Spieleindustrie anfing, hatte ich intensiv mit mehreren Low-End-CAD-Programmen (Computer Assisted Design) wie MacDraw und MacDraft gearbeitet, um Weinkeller für das Weinkellergeschäft meines Vaters zu entwerfen. Daher erschien es mir nur natürlich, die „Klick-und-Ziehen”-Metapher für die Auswahl von Rechtecken zu verwenden, um eine Gruppe von Einheiten für den Befehl zusammenzustellen.
Ich glaube, dass Warcraft das erste Spiel war, das diese Benutzeroberflächenmetapher verwendete. Als ich die Funktion zum ersten Mal implementierte, war es möglich, eine große Anzahl von Einheiten gleichzeitig auszuwählen und zu steuern; es gab keine Obergrenze für die Anzahl der Einheiten, die ausgewählt werden konnten.
Die Auswahl und Steuerung von hundert Einheiten gleichzeitig zeigte zwar die gravierenden Schwächen des einfachen Wegfindungsalgorithmus, den ich implementiert hatte, aber nachdem ich die grundlegenden Algorithmen zum Laufen gebracht hatte, verbrachte ich dennoch Stunden damit, Einheiten auszuwählen und Spielfiguren an Ziele auf der Karte zu entsenden, anstatt weiteren Code zu schreiben; es war die coolste Funktion, die ich bis dahin in meiner Programmierkarriere entwickelt hatte!
Später im Entwicklungsprozess und nach vielen Design-Diskussionen zwischen den Teammitgliedern beschlossen wir, den Spielern zu erlauben, nur vier Einheiten gleichzeitig auszuwählen, basierend auf der Idee, dass die Benutzer auf ihre taktischen Einsätze achten müssten, anstatt einfach eine Meute zusammenzutrommeln und sie alle auf einmal in die Schlacht zu schicken. Später erhöhten wir diese Zahl in Warcraft II auf neun. Command and Conquer, der geistige Nachfolger von Dune 2, hatte keine Obergrenze für die Anzahl der Einheiten, die ausgewählt werden konnten. Es lohnt sich auf jeden Fall, in einem weiteren Artikel über die Auswirkungen auf das Design zu sprechen.
Abgesehen von der Möglichkeit, mehrere Einheiten gleichzeitig zu steuern, ähnelte Warcraft in dieser Phase nichts so sehr wie einer abgespeckten Version von Dune 2, sodass ich defensiv scherzte, dass Warcraft zwar sicherlich von Dune 2 inspiriert war, sich das Spiel jedoch radikal unterschied – unsere Radar-Minikarte befand sich in der oberen linken Ecke des Bildschirms, während sich die von Dune 2 in der unteren rechten Ecke befand.
Die Gründung der Gemeinschaft
Anfang 1994 hatte ich genug Fortschritte gemacht, um zusätzliche Hilfe für das Projekt zu rechtfertigen. Zu mir gesellten sich Ron Millar, Sam Didier, Stu Rose, Bob Fitch, Jesse McReynolds, Mike Morhaime, Mickey Neilson und andere. Viele dieser Leute begannen mit der Arbeit an dem Spiel, nachdem unser Unternehmen im Februar 1994 von Davidson & Associates übernommen worden war.
Ron Millar, der mit seinen langen blonden Haaren und seiner kräftigen Statur offensichtlich ein Nachfahre der Wikinger-Krieger war. Er wurde ursprünglich aufgrund seiner Fähigkeiten als Grafiker für Gameboy-Titel bei Virgin Games eingestellt, aber seine erstaunliche Kreativität und sein Gespür für Design führten dazu, dass er bei vielen Blizzard-Projekten eine Designrolle übernahm, und er übernahm eine ähnliche Rolle bei Warcraft.
Sam Didier, ein kräftiger, stämmiger und standhafter Charakter, der nichts so sehr ähnelte wie einem auf menschliche Proportionen verkleinerten Bären, und dessen heroische Figuren und epische Zeichnungen heute den definitiven Kunststil der Blizzard-Spiele prägen, hatte seine Fähigkeiten im Zeichnen am Computer bei 16-Bit-Konsolentiteln verfeinert, aber seine Vorliebe für das Zeichnen von Fantasy-Kunstwerken während Besprechungen und in jeder anderen freien Minute zeigte seine Fähigkeit, die künstlerische Leitung für diesen neuen Titel zu übernehmen.
Stu Rose, dessen Hintergrund als Illustrator zum Entwurf des noch heute verwendeten Blizzard-Logos führte, trug zunächst zur Gestaltung der Hintergrundkachelkarten bei, übernahm aber später eine entscheidende Rolle beim endgültigen Design von Warcraft. Stu ist als Synchronsprecher in der Rolle des menschlichen Peon Peasant unvergesslich, wo seine Darstellung eines unterdrückten Rohlings komödiantisches Genie war.
Bob Fitch hatte zur gleichen Zeit, als ich mit der Entwicklung von Warcraft begann, als Programmierer und Projektleiter an einem anderen Titel gearbeitet. Allen Adham, der Präsident von Blizzard, hatte Bob mit der Entwicklung eines Wortspiels namens „Games People Play” beauftragt, das Kreuzworträtsel, Scramble, Boggle und andere ähnliche Spiele umfassen sollte. Bobs auffälliger Mangel an Begeisterung für das Projekt führte dazu, dass er viele Monate lang kaum Fortschritte machte. Als sich Warcraft als erfolgreich erwies, wurde Bob freigestellt, um mir zu helfen, und seine Begeisterung für das Spiel trug dazu bei, das Projekt schneller voranzubringen.
Jesse, ein Absolvent des Caltech, begann mit der Entwicklung eines Netzwerktreibers für das IPX-Netzwerkprotokoll, damit das Spiel in einem lokalen Netzwerk (LAN) gespielt werden konnte. Mike Morhaime, einer der beiden Mitbegründer von Blizzard, übernahm später die wesentlich schwierigere Aufgabe, einen „Mixed-Mode”-Modemtreiber zu schreiben. Während Warcraft ein DOS-Spiel im „geschützten Modus” war, konnte der Modemtreiber aufgrund von Eigenheiten des DOS-Betriebssystems und der 80386-Chiparchitektur, auf der es lief, sowohl aus dem geschützten Modus als auch aus dem Realmodus aufgerufen werden. Daher saß er regelmäßig in seinem Büro und starrte auf Bildschirme voller Diagnosewerte, während er sich mit den komplizierten Timing-Problemen im Zusammenhang mit reentrantem Code beschäftigte. Am Ende des Tages war der Modemcode absolut stabil, was angesichts der primitiven Tools, die uns damals zur Verfügung standen, eine beachtliche Leistung war.
Warcraft-Grafik
Allen Adham hoffte, eine Lizenz für das Warhammer-Universum zu erhalten, um durch die Markenbekanntheit den Umsatz zu steigern. Warhammer war eine große Inspiration für den Grafikstil von Warcraft, aber eine Kombination aus verschiedenen Faktoren, darunter mangelnde Attraktivität in geschäftlicher Hinsicht und der starke Wunsch praktisch aller anderen Mitglieder des Entwicklungsteams (mich eingeschlossen), unser eigenes Universum zu kontrollieren, machte einen Deal unmöglich. Wir hatten bereits schlechte Erfahrungen mit DC Comics bei „Death and Return of Superman“ und „Justice League Task Force“ gemacht und wollten keine ähnlichen Probleme für unser neues Spiel.
Es ist heute überraschend, darüber nachzudenken, was passiert wäre, wenn Blizzard nicht die Rechte am geistigen Eigentum für das Warcraft-Universum kontrolliert hätte – es ist höchst unwahrscheinlich, dass Blizzard heute ein so dominanter Akteur in der Spielebranche wäre.
Jahre nach der Veröffentlichung von Warcraft schenkte mir mein Vater nach seiner Rückkehr von einer Asienreise ein Set Warhammer-Miniaturen in Form eines Skelett-Wagenlenkers und Pferden mit dem Kommentar: „Ich habe diese coolen Spielzeuge auf meiner Reise gefunden und sie haben mich sehr an dein Spiel erinnert; vielleicht solltest du deine Rechtsabteilung kontaktieren, denn ich glaube, sie kopieren dich.“ Hmmm!
Hindernisse bei der Spieleentwicklung
Eine interessante Facette des frühen Entwicklungsprozesses war, dass ich zwar ein Spiel entwickelte, das über Modems oder ein lokales Netzwerk gespielt werden konnte, das Unternehmen jedoch über kein LAN im Büro verfügte. Da wir Konsolentitel entwickelten, die problemlos auf eine Diskette passten, war dies nicht notwendig, obwohl es die Erstellung von Backups sicherlich vereinfacht hätte.
Als ich also begann, mit anderen Künstlern und Programmierern zusammenzuarbeiten, nutzten wir das „Sneaker-Netzwerk“ und trugen Disketten zwischen den Büros hin und her, um Quellcode-Revisionen und Grafiken zu integrieren.
Bob Fitch war der zweite Programmierer des Projekts, und er und ich kopierten regelmäßig Dateien und Code-Änderungen hin und her. Von Zeit zu Zeit machten wir Integrationsfehler, und ein Fehler, den wir behoben hatten, tauchte wieder auf. Wir verfolgten ihn zurück und stellten fest, dass wir beim Kopieren der Dateien während der Integration der Änderungen versehentlich die Fehlerbehebung überschrieben hatten und uns nun daran erinnern mussten, wie wir den Fehler zuvor behoben hatten.
Dies passierte mehr als nur ein paar Mal, da wir den Code sehr schnell entwickelten und keine anderen Prozesse zur Code-Integration hatten als uns zu „merken”, an welchen Dateien wir gearbeitet hatten. In dieser Hinsicht hatte ich etwas mehr Glück, da mein Computer das „Master“-System war, auf dem wir alle Integrationen durchführten, sodass meine Änderungen weniger leicht verloren gingen. Heutzutage verwenden wir Quellcodeverwaltung, um solche Dummheiten zu vermeiden, aber damals wussten wir noch nicht einmal, was das war!
Mit mehr Programmierern, Designern und Künstlern, die an dem Titel arbeiteten, schritt die Entwicklung erheblich voran, aber wir entdeckten auch ein großes Hindernis für unseren Fortschritt. Das Spiel wurde ursprünglich im DOS-„Real Mode“ entwickelt, was bedeutete, dass nur 640 KB Speicher zur Verfügung standen, abzüglich etwa 120 KB für das Betriebssystem. Können Sie sich vorstellen, wie schlecht die Computer damals waren?
Als das Grafikteam begann, Spielelemente, Hintergründe und Grafiken für die Benutzeroberfläche zu erstellen, war der Speicher schnell erschöpft und wir suchten nach Alternativen. Ein erster Lösungsversuch bestand darin, EMS-„Paged Memory” Mapping zu verwenden und die Grafikressourcen „oberhalb” der 640-KB-Speichergrenze zu speichern.
Die Geschichten, die Programmierer über EMS-Speicher erzählen, ähneln denen, die ältere Menschen über den Schulweg erzählen, den sie barfuß durch den Schnee zurücklegen mussten, nur dass die EMS-Geschichten noch schrecklicher sind und tatsächlich wahr sind.
Glücklicherweise funktionierte die EMS-Lösung nicht, denn es gab eine bessere Lösung. Eine Firma namens Watcom brachte einen C-Compiler auf den Markt, der einen „Extender” für den DOS-Modus enthielt, mit dem Programme im „Protected Mode” geschrieben werden konnten und Zugriff auf linearen 32-Bit-Speicher hatten – etwas, das heute für jeden Programmierer selbstverständlich ist, wenn er 32-Bit- (oder sogar 64-Bit-)Anwendungen schreibt. Die Aktualisierung des Quellcodes dauerte zwar ein paar Tage, aber der DOS-Modus-Extender funktionierte einwandfrei, und wir konnten unsere Arbeit wieder aufnehmen, nun mit Zugriff auf wesentlich mehr Speicher.
Das ist noch nicht das Ende
Im nächsten Artikel dieser Reihe werde ich über Stu Rose und den Design-Coup, das erste Multiplayer-Spiel von Warcraft, den Bug, der das Multiplayer-Spiel fast zerstört hätte, darüber sprechen, wie Bill Roper Warcraft großartig gemacht hat, wie das Spiel auf Disketten passte, die Reaktion von Westwood Studio auf unser Spiel und andere Kleinode, die ich aus einem Spiel hervorholen kann, an dem ich und die anderen Mitglieder des Entwicklungsteams vor achtzehn (!) Jahren gearbeitet haben.
Quellenangaben:
- Artikel: Code of Honor – Part 1 (englisch)
- Autor: Patrick Wyatt
- Software: DeepL