Von Patrick Wyatt(2012)
*Übersetzung: Chris „Eredalis“ Vogler
Das allererste Multiplayer-Spiel von Warcraft war gleichzeitig ein erdrückender Sieg, eine demütigende Niederlage und ein Unentschieden. Moment mal, wie ist das möglich? Nun, dahinter steckt eine ganze Geschichte. Diese Geschichte entwickelte sich während des Schreibens organisch weiter und umfasst nun auch die Spiel-KI, die Ökonomie des Spielegeschäfts, den Nebel des Krieges und vieles mehr. Lesen Sie weiter, wenn Sie viel Zeit haben!
Nach sechs Monaten Entwicklungszeit, die im September 1993 begann, wurde Warcraft: Orcs vs. Humans, das erste Produkt der späteren Warcraft-Reihe, endlich zu einem Spiel und nicht mehr nur zu einer erweiterten Tech-Demo.
Mehrere Monate lang war ich der einzige Vollzeitmitarbeiter an diesem Projekt, was die Entwicklungsgeschwindigkeit einschränkte. Ich hatte das Glück, von anderen Mitarbeitern unterstützt zu werden, darunter Ron Millar, Stu Rose und andere, die an der Gestaltung des Projekts mitarbeiteten. Und mehrere Künstler steuerten Prototyp-Grafiken bei, wenn sie zwischen den Meilensteinen anderer Projekte Zeit dafür fanden.
Das Team war personell dünn besetzt, da die Entwicklung von Warcraft vom Unternehmen selbst finanziert wurde, aus Einnahmen, die es durch die Entwicklung von Titeln für Spielehersteller wie Interplay und SunSoft erzielt hatte, und die Kassen des Unternehmens nicht besonders gut gefüllt waren.
Zu dieser Zeit entwickelten wir vier 16-Bit-Konsolentitel: The Lost Vikings 2 (die Fortsetzung unseres von Kritikern gelobten, aber wenig verkauften Side-Scrolling-„Run-and-Jump”-Puzzlespiels), Blackthorne (ein Side-Scrolling-„Run-and-Jump”-Spiel, in dem die Hauptfigur mit einer Schrotflinte zu tun hat), Justice League Task Force (ein Street Fighter-Klon, der im DC Comics-Universum spielt) und Death and Return of Superman (ein Side-Scrolling-Beat-em-up, das auf der gleichnamigen Comic-Serie aus dem DC-Universum basiert).
Mit dem Geld, das wir für die Entwicklung dieser Spiele und andere Gelegenheitsjobs erhielten, konnte das Unternehmen die anfänglichen Entwicklungskosten bezahlen.
Wirtschaftlichkeit der Spieleentwicklung
Während des größten Teils der Geschichte der Spieleindustrie finanzierten unabhängige Spieleentwicklungsstudios – also Studios, die nicht im Besitz eines Spieleherstellers waren – ihre Projekte in der Regel durch Verträge mit diesen Herstellern. Die Hersteller „vorschossen“ Geld für die Entwicklung des Projekts. Zusätzlich zu den Vorauszahlungen für die Entwicklung waren die Hersteller für Werbung, Marketing, Herstellung, Vertrieb, Kundensupport usw. verantwortlich.
Anfang der 90er Jahre gab es noch viel mehr Spielehersteller als heute, aber die steigenden Kosten für die Entwicklung und insbesondere für die Veröffentlichung von Spielen führten aufgrund von Insolvenzen und Übernahmen zu einer massiven Konsolidierung der Branche. Wenn man heute an einen Spielehersteller denkt, fallen einem wahrscheinlich eher Activision-Blizzard, EA oder Ubisoft ein als die unzähligen mittelständischen Unternehmen, die es vor zwanzig Jahren gab.
Wie in allen Branchen sind die Vertragsbedingungen so gestaltet, dass sie stark zugunsten derjenigen sind, die das Geld haben. Das ist die andere goldene Regel: „Wer das Geld hat, macht die Regeln“. Theoretisch sind diese Vereinbarungen so strukturiert, dass der Spieleentwickler belohnt wird, wenn sich ein Spiel gut verkauft, aber wie in der Musik- und Filmindustrie erhalten die Publisher den Großteil der Gewinne, während die Entwickler gerade genug Geld erhalten, um zu überleben und einen weiteren Vertrag zu unterschreiben – wenn sie Glück haben.
Wenn ich von „Vorschüssen“ spreche, die vom Publisher gezahlt werden, ist der korrektere Begriff „Vorschüsse auf Lizenzgebühren“, wobei der Entwickler effektiv ein erlassbares Darlehen erhält, das aus den Lizenzgebühren für den Verkauf des Spiels zurückgezahlt wird. Das klingt großartig: ein Spiel entwickeln und für jedes verkaufte Exemplar bezahlt werden. Aber die Mechanismen funktionieren so, dass die überwiegende Mehrheit der Spieletitel nie genug Geld einbringt, um die Vorschüsse zurückzuzahlen. Da Entwicklungsstudios oft die Rechte an ihrem Titel und den Fortsetzungen abtreten mussten, handelt es sich bei diesen Verträgen oft um kaum verhüllte Werkverträge.
Um bessere Vertragsbedingungen zu erzielen, war es eine gängige Strategie der Entwicklungsstudios, einen ersten Spielprototyp selbst zu finanzieren und diesen dann zu nutzen, um den Verlagen einen Entwicklungsvertrag „anzubieten”. Je länger ein Entwickler in der Lage war, die Spielentwicklung selbst zu finanzieren, desto besser waren letztendlich die Vertragsbedingungen.
Das vielleicht beste Beispiel für diese Strategie ist Valve Software, wo Gabe Newell sein bei Microsoft verdientes Vermögen nutzte, um die Entwicklung von Half Life zu finanzieren und damit eine gewisse Kontrolle über den Veröffentlichungstermin des Spiels zu erlangen – das Spiel wurde erst veröffentlicht, als es ein qualitativ hochwertiges Produkt war, anstatt es überstürzt auf den Markt zu bringen, um die von Sierra Entertainment (dem Publisher des Spiels) gewünschten Quartalsumsatzziele zu erreichen. Noch wichtiger war, dass Gabe dank seiner finanziellen Mittel Valve die Online-Vertriebsrechte für Half Life sichern konnte, gerade als digitale Downloads zu einer rentablen Strategie für den Verkauf von Spielen wurden, was später zu den enormen Erfolgen des Studios führte.
Der Nachteil der Eigenfinanzierung eines Prototyps ist das Risiko, das der Entwickler eingeht, falls das Spielprojekt nicht von einem Publisher unter Vertrag genommen wird – was oft zum Ende des Studios führt.
Das Unternehmen, für das ich arbeitete – damals unter dem Namen Silicon and Synapse – finanzierte Warcraft aus eigenen Mitteln, zusammen mit einem anderen Projekt namens Games People Play, das Kreuzworträtsel, Boggle und ähnliche Spiele umfasste, die in den Regalen von Flughafenbuchhandlungen zu finden sind, um gestrandete Reisende zu unterhalten.
Durch die Entwicklung von zwei Spielen, die sich an völlig unterschiedliche Zielgruppen richteten, hofften die Eigentümer des Unternehmens, mehrere Einnahmequellen zu schaffen, die wirtschaftlich stabiler wären, als wenn sie alle Aussichten des Unternehmens auf den Kernmarkt der Unterhaltungsindustrie (d. h. „Hardcore“-Gamer wie Sie und ich) gesetzt hätten.
Natürlich birgt die Streuung der Einsätze auf verschiedene Spielgenres auch Risiken, da die Marke eines Unternehmens durch die Entwicklung von Produkten, die nicht den Wünschen des Publikums entsprechen, verwässert werden kann. Eine der großen Stärken der Marke Blizzard ist heute, dass die Nutzer ihre Spiele kaufen, ohne sie vorher gesehen zu haben, weil sie an die Vision und den Ruf des Unternehmens glauben. Dieser Ruf wäre schwieriger aufzubauen gewesen, wenn das Unternehmen sowohl Low-Budget-Casual-Titel als auch High-Budget-AAA+-Spiele veröffentlicht hätte, wie es Sierra Entertainment getan hat, das nach wiederholten Schwierigkeiten, ein Publikum zu finden, inzwischen aus dem Geschäft ausgestiegen ist.
Auf jeden Fall erwies sich die Entwicklung von „Games People Play” als Fehltritt, da die Entwicklung eines Casual-Entertainment-Produkts für den leitenden Programmierer so demoralisierend war, dass das Projekt nie ausgereift wurde und später eingestellt wurde. Oder vielleicht war es doch kein Fehler, denn die Kombination aus „Warcraft” und „Games People Play” überzeugte „Davidson & Associates”, damals das zweitgrößte Unternehmen für Lernsoftware weltweit, „Silicon & Synapse” zu kaufen.
Unsere neuen Oberherren
Davidson & Associates, gegründet von Jan Davidson und später ergänzt durch ihren Ehemann Bob, war ein diversifiziertes Unternehmen für Lernsoftware, dessen Wachstum auf dem Erfolg eines Titels namens Math Blaster beruhte, in dem der Spieler mathematische Aufgaben lösen muss, um herannahende Asteroiden zu sprengen, bevor sie das Schiff des Spielers zerstören. Es war eine clevere Verbindung von Bildung und Unterhaltung, und das Unternehmen profitierte enorm von der Veröffentlichung.
Nebenbei bemerkt: Als Lernspiel hatte Math Blaster vielleicht einen gewissen Wert, wenn es richtig eingesetzt wurde, aber ich hatte Gelegenheit, zu sehen, wie es unsinnig eingesetzt wurde. In meinem Journalismusunterricht in der High School schrieben wir Artikel für unsere Schulzeitung in einem Computerraum, den wir uns mit der Förderklasse teilten; meine Mitschüler und ich sahen mit Entsetzen zu, wie die Förderklasse der Zwölftklässler Math Blaster mit Taschenrechnern spielte. Wenn Asteroiden mit Ausdrücken wie „3 + 5“ und „2 * 3“ näher kamen, tippten diese Schüler schnell die Gleichungen in ihre Taschenrechner ein und gaben dann die Ergebnisse ein, um die Asteroiden zu zerstören. Man könnte argumentieren, dass sie etwas gelernt haben, da sie ihre Lehrer überlistet haben, aber ich bin mir nicht sicher, ob das die beste Nutzung ihrer Zeit war, da sie kurz vor dem Eintritt ins Berufsleben standen.
Mit guter Unternehmensführung und aggressivem Management expandierte Davidson & Associates in die Spieleproduktion (Entwicklung und Verpackung der Verkaufsverpackungen), den Spielevertrieb (Versand der Verpackungen an Einzelhändler und Zwischenhändler) und den Direktvertrieb von Lernmaterialien an Schulen. Das Unternehmen sah eine Chance, in die Unterhaltungsbranche zu expandieren, aber seine frühen Bemühungen, intern Unterhaltungstitel zu entwickeln, überzeugten es davon, dass es sinnvoller wäre, ein erfahrenes Spielentwicklungsstudio zu kaufen, anstatt weiterhin eigene Spiele mit Mitarbeitern zu entwickeln, die sich besser mit frühkindlicher Bildung als mit Schwertern und Zauberei auskannten.
Und so wurden die Cashflow-Probleme, die das Wachstum des Warcraft-Entwicklungsteams verhindert hatten, durch die Übernahme des Unternehmens auf einen Schlag gelöst. Mit der finanziellen Unterstützung von Davidson war es Silicon & Synapse (das nach dem Verkauf in Blizzard umbenannt wurde) nun möglich, sich auf seine eigenen Titel zu konzentrieren, anstatt sich auf wenig profitable Geschäfte mit anderen Spieleherstellern einzulassen. Und diese waren sehr gering – selbst als das Unternehmen 1993 zwei hoch bewertete Spiele entwickelte, die ihm den Titel „Nintendo Developer of the Year” einbrachten, erhielt es keine Lizenzgebühren.
Mit den durch die Übernahme gewonnenen finanziellen Mitteln konnten neue Mitarbeiter eingestellt und bestehende Mitarbeiter für das Projekt gewonnen werden, wodurch sich die Entwicklung von Warcraft dramatisch beschleunigte.
Der „Entwurfsprozess”
Die Herangehensweise an das Entwerfen und Entwickeln von Spielen bei Blizzard in den Anfangsjahren lässt sich am besten als „organisch” beschreiben. Es war ein chaotischer Prozess, der während formeller Entwurfssitzungen, aber häufiger noch bei spontanen Treffen auf dem Flur oder beim Essen stattfand.
Einige Features stammten aus Design-Dokumenten, während andere von einzelnen Programmierern nach Lust und Laune hinzugefügt wurden. Einige Spielgrafiken wurden methodisch geplant, terminiert und ausgeführt, während andere Arbeiten spät in der Nacht entstanden, weil ein Grafiker eine großartige Idee hatte oder einfach etwas Neues ausprobieren wollte. Andere Elemente wurden ähnlich improvisiert; die Geschichte und die Hintergrundgeschichte von Warcraft entstanden erst in den letzten Monaten vor der Veröffentlichung.
Der Prozess war zwar unvorhersehbar, aber die Ergebnisse waren spektakulär. Da das Team aus Computerspiel-Fanatikern bestand, entwickelten sich unsere Spiele im Laufe ihrer Entwicklung zu etwas, das die Spieler immer wieder spielen wollten. Und Warcraft, unser erstes eigenes Spiel für den IBM-PC, war ein Beispiel für das Beste (und manchmal auch das Schlechteste) dieses Prozesses und führte letztendlich zu einem Spiel, das – zumindest für seine Zeit – vorbildlich war.
Wie das System zur Erstellung von Einheiten in Warcraft entstand
Wie Biologen wissen, gibt es im Evolutionsprozess Fehlstarts, bei denen ganze Zweige des Evolutionsbaums ausgelöscht werden, und so war es auch bei unseren Entwicklungsbemühungen. Da wir keine Spezifikationen hatten, an denen wir uns orientieren konnten, experimentierten wir stattdessen und sortierten die Dinge aus, die nicht funktionierten. Ich würde gerne sagen, dass dies in jedem Fall ein wohlüberlegter, bewusster Prozess war, aber oft entstand er aus Zufällen, Auseinandersetzungen und Persönlichkeitskonflikten.
Ein Ereignis, an das ich mich besonders erinnere, stand im Zusammenhang mit der Erstellung von Spiel-Einheiten. In der frühen Phase der Entwicklung wurden Einheiten mit „Cheat“-Befehlen, die in die Konsole eingegeben wurden, ins Leben gerufen, da es keinen anderen Mechanismus in der Benutzeroberfläche gab, um sie zu erstellen. Als wir überlegten, wie man Einheiten am besten erstellen könnte, wurden verschiedene Ideen vorgeschlagen.
Ron Millar, ein Künstler, der einen Großteil der Ideen und des Designs für die frühen Blizzard-Spiele lieferte, schlug vor, dass die Spieler Bauernhäuser bauen sollten und dass diese Bauernhöfe – wie im Spiel Populous – in regelmäßigen Abständen einfache Arbeitereinheiten hervorbringen sollten, die als (menschliche) Bauern und (Ork-)Peons bekannt waren. Der Spieler könnte diese Einheiten direkt für den Goldabbau, die Holzgewinnung und den Bau von Gebäuden einsetzen, aber als Kämpfer wären sie nicht besonders geeignet.
Die „Peons“, die nicht anderweitig beschäftigt waren, konnten vom Spieler zu einer militärischen Ausbildung in Kasernen geschickt werden, wo sie für eine Weile von der Karte verschwanden und schließlich als erfahrene Kämpfer zurückkehrten. Andere Ausbildungsbereiche würden für die Schaffung fortgeschrittenerer Militäreinheiten wie Katapultteams und Zauberer genutzt werden.
Die Idee war noch nicht vollständig „ausgereift”, was einer der häufigsten Mängel unseres Designprozesses war: Dem Endergebnis des Designprozesses fehlte die Formalität, um zu dokumentieren, wie eine Idee umgesetzt werden sollte. Daher wurde die Idee innerhalb des informellen Designteams (d. h. dem Großteil des Unternehmens) hin und her diskutiert, bevor wir mit der Codierung (Programmierung) der Umsetzung begannen.
Bevor wir mit der Arbeit am Code begannen, reiste Ron zusammen mit Allen Adham, dem Präsidenten des Unternehmens, zu einer Messe (wahrscheinlich der Winter CES – Consumer Electronics Show). Während ihrer Abwesenheit ereignete sich etwas, das die Richtung für die gesamte Warcraft-Reihe vorgab, ein Ereignis, das ich als „Warcraft-Design-Coup” bezeichne.
Stu Rose, ein weiterer Künstler/Designer, der früh zum Unternehmen kam (ich glaube, er war Mitarbeiter Nr. 6), kam eines Nachmittags spät in mein Büro, um für einen anderen Ansatz zu plädieren. Stu war der Meinung, dass der von Ron vorgeschlagene Mechanismus zur Erstellung von Einheiten zu viele noch ungelöste Komplexitäten bei der Umsetzung mit sich brachte und darüber hinaus im Widerspruch zu der Art von Kontrolle stand, die wir den Spielern in einem Echtzeit-Strategiespiel (RTS) geben sollten.
In diesem neuen RTS-Genre waren die Anforderungen an die Spieler viel höher als in anderen Genres, und die Aufmerksamkeit der Spieler konnte aufgrund der vielen konkurrierenden Anforderungen nicht lange auf einen Punkt konzentriert werden: den Aufbau-/Upgrade-Baum planen, wirtschaftliche Aktivitäten vorantreiben, Einheiten erstellen, Gebäude platzieren, die Karte erkunden, den Kampf überwachen und die Fähigkeiten einzelner Einheiten im Detail verwalten. In einem RTS ist die Aufmerksamkeit der Spieler die begrenzteste Ressource. Eine zusätzliche kognitive Belastung durch einen indirekten Mechanismus zur Erstellung von Einheiten würde das Aufmerksamkeitsdefizit vergrößern und den Schwierigkeitsgrad des Spiels erhöhen.
Um „Grunts”, die grundlegende Kampfeinheit, zu erstellen, wäre es notwendig, untätige Bauern oder solche, die an Aufgaben mit niedrigerer Priorität arbeiten, zusammenzutreiben, um sie auszubilden, was (nach Stus Ansicht) den Schwierigkeitsgrad des Spiels unnötig erhöht.
Ich war ein aufgeschlossenes Publikum für seinen Vorschlag, da ich ähnliche (wenn auch weniger gut durchdachte) Bedenken hatte und nicht der Meinung war, dass die Erstellung von Einheiten ein Bereich war, in dem wir mutige Änderungen vornehmen mussten. Dune II, das Spiel, von dem das Design von Warcraft abgeleitet war, hatte einen viel einfacheren Mechanismus für die Erstellung von Einheiten: Man musste nur auf eine Schaltfläche auf dem Bedienfeld einer Fabrik klicken, und die Einheit erschien kurze Zeit später. Das war nichts Neues – die Idee war aus noch früheren Spielen kopiert –, aber es funktionierte einfach.
Stu argumentierte, dass wir diesen Ansatz verfolgen und anstelle weiterer Debatten das Projekt einfach umsetzen sollten. Also schrieb ich in den nächsten Tagen und Nächten den für die Implementierung der Einheitenerstellung erforderlichen Code für das Spiel und die Benutzeroberfläche, und die Designentscheidung wurde zur vollendeten Tatsache. Als Ron und Allen zurückkamen, war das Spiel im Einzelspielermodus bereits ansatzweise spielbar, nur die KI des gegnerischen Computers war noch Monate von der Fertigstellung entfernt.
Warcraft war nun ein echtes Spiel, das einfach zu spielen war und – was noch wichtiger war – Spaß machte. Wir haben nie zurückgeschaut.
Das erste Multiplayer-Spiel von Warcraft
Im Juni 1994, nach zehn Monaten Entwicklungszeit, war die Spiel-Engine fast bereit für den Multiplayer-Modus. Mit wachsender Begeisterung integrierte ich die Codeänderungen, die es ermöglichen würden, das erste Multiplayer-Spiel von Warcraft zu spielen. Während ich damit beschäftigt war, die Kernlogik des Spiels (Ereignisschleife, Unit-Dispatcher, Wegfindung, taktische Unit-KI, Statusleiste, In-Game-Benutzeroberfläche, hochrangiger Netzwerkcode) zu entwickeln, arbeiteten andere Programmierer an den Komponenten, die für die Erstellung eines Multiplayer-Spiels erforderlich waren.
Jesse McReynolds, ein Absolvent des Caltech, hatte die Programmierung einer Low-Level-Netzwerkbibliothek abgeschlossen, um IPX-Pakete über ein lokales Netzwerk zu senden. Der Code basierte auf Erkenntnissen aus dem Quellcode von Quake Doom, der vor kurzem von John Carmack bei id Software als Open Source veröffentlicht worden war. Die IPX-Schnittstellenschicht umfasste zwar nur einige hundert Zeilen C-Code, war jedoch der Teil des Codes, der mit dem Netzwerkkartentreiber kommunizierte, um sicherzustellen, dass die auf einem Spielclient erstellten Nachrichten an den anderen Spieler gesendet wurden.
Und Bob Fitch, der seinen Master-Abschluss an der Cal State Fullerton machte, entwickelte die ersten „Glue Screens”, mit denen Spieler Multiplayer-Spiele erstellen und daran teilnehmen konnten. Mein Büro lag direkt neben dem von Bob, was sehr praktisch war, da wir eng zusammenarbeiten mussten, um seine Logik zum Beitreten oder Erstellen von Spielen in meine Spiel-Ereignisschleife zu integrieren.
Nachdem ich die Änderungen integriert hatte, kompilierte ich den Spiel-Client und kopierte ihn auf ein Netzlaufwerk, während Bob zurück in sein Büro eilte, um dem Spiel beizutreten. Wie durch ein kleines Wunder funktionierte der von uns geschriebene Code tatsächlich und wir konnten das allererste Multiplayer-Spiel von Warcraft starten.
Als wir das Spiel starteten, verspürte ich eine größere Aufregung als jemals zuvor bei einem anderen Spiel. Ein Teil der Spannung lag darin, dass ich an der Entwicklung des Codes mitgewirkt hatte, aber noch mehr in zwei Faktoren, die ein Gefühl der Angst hervorriefen: dass ich gegen einen menschlichen Gegner statt gegen eine bloße Computer-KI spielte und vor allem, dass ich aufgrund des Nebels des Krieges nicht wusste, was er vorhatte.
Der Nebel des Krieges
Eine der Ideen, die aus früheren Spielen übernommen wurde, war, feindliche Einheiten vor den Augen des gegnerischen Spielers zu verbergen. Eine schwarze Grafiküberlagerung verbarg Bereiche der Spielkarte, bis eine verbündete Einheit das Gebiet erkundete. Dies sollte die unvollständigen Informationen nachahmen, die ein General in echten Schlachten über feindliche Operationen und Truppenbewegungen hat.
Empire, ein rundenbasiertes Multiplayer-Strategiespiel, das vor fast siebzehn Jahren vom brillanten Walter Bright (dem Schöpfer der Programmiersprache „D”) geschrieben wurde, nutzte den Nebel des Krieges für denselben Zweck. Sobald ein Bereich der Karte „entdeckt” (aufgedeckt) wurde, blieb er für immer sichtbar. Daher war es beim Spielen wichtig, frühzeitig einen Großteil der Karte zu erkunden, um frühzeitig vor feindlichen Truppenbewegungen gewarnt zu werden, bevor deren Einfälle kritische Infrastrukturen oder wirtschaftliche Kapazitäten beschädigen konnten.
Die psychologische Angst, die durch die Ungewissheit über die Absichten des Feindes entsteht, hat im Laufe der Geschichte schon viele Generäle zu Fall gebracht, und die Einbindung dieses Elements in das RTS-Genre ist eine großartige Möglichkeit, die Spannung (und Angst) zu steigern. Vielen Dank an Walter und die Leute von Westwood, die Dune II entwickelt haben, für ihre Genialität!
Computer-KI
Wie viele Spieler wissen, sind computergesteuerte „künstliche Intelligenz”-Spieler (KI) in Strategiespielen oft schwach. Es kommt häufig vor, dass menschliche Spieler Schwachstellen entdecken, gegen die die Computer-KI nicht programmiert ist, und die genutzt werden können, um die KI ohne große Schwierigkeiten zu zerstören. Daher verlassen sich Computer-KI-Spieler in der Regel auf einen zahlenmäßigen Truppenvorteil, einen Positionsvorteil oder „asymmetrische Regeln”, um den Spielern eine gute Herausforderung zu bieten.
In den meisten Warcraft-Missionen erhalten die gegnerischen Computer-Spieler zu Beginn des Kampfes gegen menschliche Spieler ganze Städte und Armeen. Darüber hinaus enthält Warcraft mehrere asymmetrische Regeln, die es dem KI-Spieler erleichtern, sich zu behaupten, obwohl diese Regeln von den meisten Spielern wohl als regelrechter Betrug bezeichnet würden.
Eine Regel, die wir zur Unterstützung der Computer-KI geschaffen haben, war die Reduzierung der aus Goldminen entnommenen Goldmenge, um zu verhindern, dass diese abgebaut werden. Wenn die Arbeiter eines menschlichen Spielers aus einer Goldmine kommen, entnehmen sie bei jedem Transport 100 Einheiten Erz aus der Mine und liefern es an das Rathaus des Spielers zurück, sodass die Goldmine durch diese Abbauarbeiten schließlich erschöpft ist. Wenn jedoch ein KI-gesteuerter Arbeiter denselben Transport durchführt, entnimmt er nur 8 Einheiten Erz aus der Mine, liefert aber dennoch 100 Einheiten an die KI-Kasse.
Diese asymmetrische Regel macht das Spiel in zweierlei Hinsicht tatsächlich unterhaltsamer: Sie verhindert, dass Menschen „turtlen”, d. h. eine uneinnehmbare Verteidigung aufbauen und ihre überlegenen strategischen Fähigkeiten einsetzen, um die Computer-KI zu überwinden. Turtling ist eine zum Scheitern verurteilte Strategie gegen Computer-KIs, da die Goldminen des menschlichen Spielers lange vor denen des Computers erschöpft sein werden.
Zweitens bleibt dem menschlichen Spieler, wenn er schließlich das Lager des Computers zerstört, immer noch Gold zum Abbauen übrig, was das Spiel schneller macht und mehr Spaß bringt, als sich mit begrenzten Ressourcen einen Sieg zu erkämpfen.
Die meisten Spieler sind sich einer schwerwiegenderen Verletzung des Fairnessprinzips bewusst: Die KI des Computers betrügt, weil sie durch den Nebel des Krieges hindurchsehen kann; die KI weiß genau, was der Spieler von Moment zu Moment tut. In der Praxis war dies kein großer Vorteil für den Computer und diente lediglich dazu, ihn nicht völlig dumm erscheinen zu lassen.
Interessanterweise hat sich angesichts der langjährigen Popularität von StarCraft (über 14 Jahre seit der Veröffentlichung und immer noch gespielt) eine Gruppe von KI-Programmierern der Herausforderung gestellt, nicht betrügerische KIs zu entwickeln. Mit Hilfe einer Bibliothek namens BWAPI schreiben diese Programmierer Code, der Befehle direkt in die StarCraft-Engine einspeisen kann, um das Spiel zu spielen. Die Programmierer lassen ihre KI-Spieler gegeneinander antreten, um den Sieger zu ermitteln. Diese BWAPI-KI-Spieler sind zwar gut, aber die besten von ihnen werden von erfahrenen menschlichen Gegnern mühelos geschlagen.
Gegen einen Menschen spielen
Als jemand, der vor der Entwicklung von Warcraft viele (wirklich viele) Strategiespiele gespielt hatte, war ich mir der Grenzen der damaligen Computer-KI sehr wohl bewusst. Obwohl ich gegen viele Computer-KIs gekämpft hatte, manchmal verloren, oft gewonnen, hatte ich nie Angst vor der KI-Intelligenz, selbst als ich gegen die schreckliche russische Offensive im Spiel „Eastern Front“ von Chris Crawford kämpfte, das ich auf dem Atari 800 eines Freundes spielte, bis die Audiokassette (!) mit dem Spiel schließlich so alt war, dass sie nicht mehr gelesen werden konnte.
Diese Spiele machten Spaß, waren spannend und auf jeden Fall herausfordernd, aber nicht beängstigend. Aber als ich das erste Multiplayer-Spiel von Warcraft spielte, änderte sich etwas.
Das Wissen, dass ich gegen einen fähigen menschlichen Spieler antrat – nicht nur in Bezug auf Geschicklichkeit und Strategie, sondern auch in Bezug auf die Geschwindigkeit der Befehlsausführung –, aber durch den Nebel des Krieges daran gehindert war, seine Aktionen zu sehen, war sowohl aufregend als auch beängstigend. In meiner gesamten Karriere habe ich mich noch nie so sehr für ein einzelnes Spiel begeistert wie bei dieser ersten Erfahrung mit „Warcraft“, bei der es unmöglich war zu wissen, ob ich gewann oder verlor.
Während mein Blut mit Adrenalin überschwemmt wurde, gab ich mein Bestes, um effizient Gold und Holz zu sammeln, Farmen und Kasernen zu bauen, Offensivfähigkeiten zu entwickeln, die Karte zu erkunden und – was am wichtigsten war – Bobs Armeen zu vernichten, bevor er dasselbe mit meinen tun konnte.
Dies war kein Testspiel, um die Funktionalität der Engine zu überprüfen; ich weiß, dass er denselben Wunsch verspürte, sich damit brüsten zu können, das allererste Multiplayer-Spiel von Warcraft gewonnen zu haben. Außerdem hatte ich mir bei Blizzard, als wir zusammen Doom gespielt hatten, einen gewissen Ruf erworben, weil Bob nach einem besonders heftigen Spiel so wütend auf mich war, dass ich ihn so oft mit einem Raketenwerfer getötet hatte, dass er schwor, nie wieder gegen mich zu spielen. Ich wusste, dass er auf Rache aus sein würde.
Als unsere Armeen aufeinander trafen, verdoppelten wir unsere Anstrengungen, mehr Einheiten zu bauen und sie in die Schlacht zu schicken. Als ich sein Lager entdeckt und angegriffen hatte, war ich hoffnungsvoller. Bobs Strategie schien unorganisiert und es sah so aus, als könnte ich seine Streitkräfte vernichten, aber ich wollte nichts dem Zufall überlassen und setzte meinen Angriff in rasendem Tempo fort, indem ich seine Einheiten und Gebäude angriff, wo immer ich sie finden konnte.
Und dann … Absturz:
Wie jeder Programmierer weiß, ist die Wahrscheinlichkeit, dass neuer Code auf Anhieb richtig funktioniert, nahezu null, und so sollte es keine Überraschung sein, dass das Spiel abgestürzt ist. Die Grafiken des Spiels scrollten aus dem oberen Bereich des Monitors heraus und wurden durch den blockartigen Text des DOS4GW-„Absturzbildschirms” ersetzt, der den Spielern aus der Zeit vor Windows-Spielen so vertraut ist. Heute gibt es den weitaus verbesserten Windows-Fehlerberichtsdialog, über den der Spieler einen Absturzbericht einreichen kann, obwohl Spieler gelegentlich den gefürchteten „Blue Screen of Death” sehen, der dem alten sehr ähnlich ist.
Nach dem Absturz sprang ich von meinem Stuhl auf, rannte in Bobs Büro und schrie: „Das war geeeeeil!” Unmittelbar darauf folgte: „… und ich habe dich fertiggemacht!” Ich war überrascht, als Bob sofort widersprach: Im Gegenteil, er hatte mich vernichtet.
Es dauerte ein paar Minuten, bis sich unsere aufgewühlten Nerven wieder beruhigt hatten, aber wir stellten schnell fest, dass wir nicht nur einen Absturzfehler hatten, sondern auch ein Problem mit der Synchronisation des Spielzustands, das ich als „Synchronisationsfehler“ bezeichnete: Die beiden Computer zeigten völlig unterschiedliche Schlachten, die zwar identisch begonnen hatten, sich aber zu zwei völlig unterschiedlichen Universen entwickelten.
Jemand, der noch nie an der Programmierung von Netzwerkcode gearbeitet hat, könnte annehmen, dass die beiden Warcraft-Spielclients während des Spiels in jeder Runde den gesamten Spielstatus hin und her senden würden. Das heißt, in jeder Runde würden die Computer die Positionen und Aktionen für jede Spielfigur senden. In einem langsamen Spiel mit nur wenigen Positionen auf dem Spielfeld, wie Schach oder Dame, wäre dies sicherlich möglich, aber in einem Spiel wie Warcraft, in dem bis zu 600 Einheiten gleichzeitig im Einsatz sind, war es unmöglich, diese Informationsmenge über das Netzwerk zu senden.
Wir gingen davon aus, dass viele Spieler Warcraft mit 2400-Baud-Modems spielen würden, die nur wenige hundert Zeichen pro Sekunde übertragen konnten. Jüngere Spieler, die noch nie ein Modem benutzt hatten, sollten sich die Zeit nehmen, sich über diese Technologie zu informieren, die kaum besser als Rauchzeichen und nur geringfügig fortschrittlicher als das Aneinanderschlagen von Steinen war. Denken Sie daran, dass dies vor Amazon, Google und Netflix war – wir sprechen hier von dem Mittelalter, Mann.
Da ich zuvor Battle Chess von DOS auf Windows „portiert” hatte, war ich mit der Kommunikation von Multiplayer-Spielen über Modems vertraut. Ich wusste, dass es aufgrund der begrenzten Bandbreite eines Modems unmöglich sein würde, den gesamten Spielstatus über das Netzwerk zu übertragen. Meine Lösung bestand daher darin, nur die Befehle jedes Spielers zu senden und beide Spieler diese Befehle gleichzeitig ausführen zu lassen.
Ich wusste, dass diese Lösung funktionieren würde, da Computer sehr gut darin sind, genau das zu tun, was man ihnen sagt. Leider stellte sich heraus, dass wir Menschen, die sie programmieren, oft nicht so gut darin sind, Computern genau zu sagen, was sie tun sollen, und das ist eine wichtige Ursache für Fehler. Wenn zwei Computer dasselbe tun sollen, sich aber aufgrund eines Fehlers nicht einig sind, ist das ein Problem.
Ein Synchronisationsfehler tritt auf, wenn die beiden Computer, die das Spiel simulieren, jeweils unterschiedliche Antworten auf dieselbe Frage wählen und sich von da an mit der Zeit immer weiter voneinander entfernen. Wie in Zeitreisefilmen wie „Zurück in die Zukunft“ führen kleine Veränderungen, die der Zeitreisende in der Vergangenheit vornimmt, zu völlig unterschiedlichen Zukünften; so kam es, dass auch die Spiele von „Warcraft“ ähnlich auseinanderliefen. Auf meinem Computer würde mein elfischer menschlicher Bogenschütze deinen orkischen Knecht sehen und angreifen, während auf deinem Computer der Knecht den Angriff nicht bemerken und weiterziehen würde, um Holz zu sammeln. Ohne einen Mechanismus, um solche Unstimmigkeiten zu entdecken oder zu beheben, würden unsere beiden Spiele bald völlig unterschiedlich sein.
So endete das erste Spiel von Warcraft unentschieden, aber gleichzeitig war es ein großer Sieg für das Spieleteam – es hat riesigen Spaß gemacht! Andere Teammitglieder im Büro spielten bald darauf Multiplayer und stellten fest, dass es wie Blue Sky war, das reine Crystal Meth, das Walter White in Breaking Bad herstellt. Sobald die Leute auf den Geschmack von Multiplayer Warcraft gekommen waren, gab es nichts Besseres mehr. Selbst mit regelmäßigen Spielabstürzen wussten wir, dass wir etwas Großes auf die Beine gestellt hatten.
Wir mussten nur noch das Spiel fertigstellen.
Tragischerweise machten wir bald eine noch schlimmere Entdeckung: Wir hatten nicht nur zahlreiche Synchronisationsfehler, sondern es gab auch viele verschiedene Ursachen für diese Synchronisationsfehler. Wenn alle Synchronisationsfehler ähnliche Ursachen gehabt hätten, hätten wir uns bemühen können, die einzelne Ursache zu beheben. Stattdessen stellte sich heraus, dass es zahlreiche verschiedene Arten von Problemen gab, von denen jedes eine andere Art von Synchronisationsfehler verursachte und jedes daher eine eigene Lösung erforderte.
Warum treten Synchronisationsfehler auf?
Bei der Entwicklung von Warcraft hatte ich eine Lösung entwickelt, um die über das Netzwerk zu übertragende Datenmenge zu minimieren, indem nur die Befehle gesendet wurden, die jeder Spieler initiierte, wie „Einheit 5 auswählen“, „zu 650, 1224 bewegen“ und „Einheit 53 angreifen“. Viele Programmierer haben unabhängig voneinander dasselbe System entwickelt; es ist eine naheliegende Lösung für das Problem, zwei Computer zu synchronisieren, ohne bei jedem Spielzug den gesamten Spielstatus zwischen ihnen zu übertragen.
Nebenbei bemerkt: Heutzutage gibt es wahrscheinlich mehrere Patente, die rückwirkend versuchen, die Urheberschaft für diesen Ansatz zu beanspruchen. Mit der Zeit bin ich zu der Überzeugung gelangt, dass Software nicht patentierbar sein sollte; fast jede Idee in der Softwareentwicklung ist etwas, das ein einigermaßen erfahrener Programmierer erfinden könnte, und die Definition von Patenten verlangt, dass Patente nicht offensichtlich sind. Genug gesagt.
Ich hatte noch keinen Mechanismus zur Überprüfung der Synchronisation zwischen den beiden Computern implementiert, sodass jeder Fehler im Spielcode, der dazu führte, dass diese Computer unterschiedliche Entscheidungen trafen, dazu führte, dass das Spiel „sich verzweigte“ – das heißt, es teilte sich in zwei lose gekoppelte Universen, die weiterhin kommunizierten, aber mit der Zeit immer schneller auseinander drifteten.
Die Entwicklung von Systemen zur Erkennung von Desynchronisationsproblemen war eindeutig die nächste Aufgabe auf meiner langen Liste von Dingen, die ich erledigen musste, um das Spiel auf den Markt zu bringen!
Auf lange Sicht
Sie kennen das Ende dieser Geschichte: Warcraft kam schließlich nur fünf Monate später auf den Markt. Es kam uns wie eine Ewigkeit vor, weil wir jeden Tag so viele Stunden arbeiteten, so viele Hindernisse überwanden, so viele Herausforderungen meisterten und etwas schufen, das uns so sehr am Herzen lag. Ich werde in zukünftigen Blog-Artikeln weiter auf diese verbleibenden Monate eingehen, aber in dieser Zeit ist so viel passiert, dass es unmöglich ist, diese Erinnerungen in diesen ohnehin schon zu langen Beitrag zu packen!
Quellenangaben:
- Artikel: Code of Honor – Part 3 (englisch)
- Autor: Patrick Wyatt
- Software: DeepL