Von Patrick Wyatt (2012)
*Übersetzung: Chris „Eredalis“ Vogler
Ich habe über die frühe Entwicklung von Warcraft geschrieben, aber ein kürzlich gelesener Blogbeitrag hat mich dazu veranlasst, wie wild drauf loszuschreiben und das Ergebnis ist dieser Artikel über die Entwicklung von StarCraft, zusammen mit meinen Gedanken zum Schreiben von zuverlässigerem Spielcode.
– Patrick Wyatt
Warum StarCraft während der Entwicklung häufig abstürzte
Die Anfänge von StarCraft
Während der Entwicklung von StarCraft, einer zweieinhalbjährigen Plackerei mit über einem Jahr Crunch-Zeit vor der Veröffentlichung, war das Spiel so fehlerhaft wie ein Termitennest. Während seine Vorgänger (Warcraft I und II) weitaus zuverlässiger waren als andere Spiele der Branche, stürzte StarCraft so häufig ab, dass das Testen bis zur Veröffentlichung schwierig war und das Spiel auch nach dem Start weiterhin ständig gepatcht werden musste.
Warum? Dafür gab es sooooo viele Gründe.
Orcs im Weltraum
StarCraft war ursprünglich als Spiel mit bescheidenen Zielen konzipiert, das in einen einjährigen Entwicklungszyklus passen sollte, damit es zu Weihnachten 1996 veröffentlicht werden konnte.
Die Projektleitung bestand aus denselben Leuten, die Shattered Nations ins Leben gerufen hatten, ein rundenbasiertes Strategiespiel nach dem Vorbild von X-COM, das Blizzard im Mai 1995 angekündigt, aber einige Monate später wieder eingestellt hatte.
Die Teammitglieder wurden neu zusammengestellt, um etwas zu entwickeln, das schnell auf den Markt kommen konnte, damit Blizzard keine lange Pause zwischen den Spielveröffentlichungen hatte.
- 4. Quartal 1994 – Warcraft
- 4. Quartal 1995 – Warcraft II
- 4. Quartal 1996 – geplanter Veröffentlichungstermin für StarCraft
- 2. Quartal 1998 – tatsächlicher Veröffentlichungstermin für StarCraft
Die Entscheidung, die Entwicklung des Spiels zu beschleunigen, erscheint im Nachhinein lächerlich, aber Allen Adham, der Präsident des Unternehmens, stand unter dem Druck, den Umsatz zu steigern. Die frühen Spiele von Blizzard waren zwar weitaus erfolgreicher als erwartet, aber das steigerte nur die Erwartungen an das zukünftige Wachstum.
Angesichts des kurzen Zeitrahmens und der begrenzten Mitarbeiterzahl war es das Ziel des StarCraft-Teams, ein bescheidenes Spiel zu entwickeln – etwas, das man am besten als „Orcs im Weltraum” beschreiben könnte. Ein Bild aus der Zeit der E3-Spielemesse im 2. Quartal 1996 zeigt den Weg, den das Spieleteam ursprünglich eingeschlagen hatte:
Ja – ich würde es auch nicht spielen.
Aber ein Projekt mit höherer Priorität überschattete StarCraft und stahl ihm nach und nach seine Entwickler. Diablo, ein Rollenspiel, das von Condor Studios in Redwood City, Kalifornien, entwickelt wurde, benötigte zusätzliche Hilfe. Condor, ein Unternehmen, das von Dave Brevik zusammen mit Max Schaefer und seinem Bruder Erich Schaefer gegründet wurde, erhielt ein Budget von nur 1,2 Millionen Dollar – selbst für damalige Verhältnisse lächerlich wenig.
Das Condor-Team hatte keine Hoffnung, das Spiel zu entwickeln, das es sich vorgenommen hatte, aber es leistete so bahnbrechende Arbeit bei der Entwicklung von etwas Unterhaltsamem, dass es für Blizzard sinnvoll war, Condor zu übernehmen, es in Blizzard North umzubenennen und das Geld und das Personal zu investieren, das das Spiel wirklich verdiente.
Zunächst flogen Collin Murray, ein Programmierer von StarCraft, und ich nach Redwood City, um zu helfen, während andere Entwickler im „Hauptquartier” von Blizzard in Irvine, Kalifornien, an Netzwerk-„Providern” für Battle.net, Modem- und LAN-Spielen sowie an den Benutzeroberflächen (bei Blizzard als „Glue Screens” bekannt) arbeiteten, die die Charaktererstellung, den Beitritt zum Spiel und andere Meta-Spielfunktionen übernahmen.
Als Diablo immer mehr an Umfang gewann, arbeiteten schließlich alle im Hauptquartier von Blizzard – Grafiker, Programmierer, Designer, Tontechniker, Tester – an dem Spiel, bis bei StarCraft niemand mehr für das Projekt übrig war. Sogar der Projektleiter wurde hinzugezogen, um den Spiel-Installer fertigzustellen, den ich zur Hälfte geschrieben hatte, aber aus Zeitgründen nicht fertigstellen konnte.
Nach der Veröffentlichung von Diablo Ende 1996 wurde die Entwicklung von StarCraft wieder aufgenommen, und alle hatten die Möglichkeit zu sehen, in welche Richtung sich das Spiel entwickelte, und das war nicht schön. Das Spiel war veraltet und nicht im Entferntesten beeindruckend, insbesondere im Vergleich zu Projekten wie Dominion Storm, das sechs Monate zuvor in Demos auf der E3 großartig aussah.
Der enorme Erfolg von Diablo setzte neue Maßstäbe für die Erwartungen an Blizzard: StarCraft wurde zu dem Spiel, das Blizzards Strategie definierte, Spiele erst zu veröffentlichen, wenn sie wirklich fertig waren. Aber um diese Strategie zu beweisen, mussten wir einige schmerzhafte Erfahrungen machen.
Etwas zu beweisen
Da alle StarCraft kritisch betrachteten, war klar, dass das Projekt weitaus ambitionierter sein musste als unsere bisherigen bahnbrechenden Bemühungen, mit den ersten beiden Warcraft-Spielen die Zukunft des Echtzeit-Strategie-Genres (RTS) zu definieren.
Zum Zeitpunkt des Neustarts von StarCraft befanden sich laut Johnny Wilson, dem damaligen Chefredakteur von Computer Gaming World, dem damals größten Gaming-Magazin, über achtzig (80!!) RTS-Spiele in der Entwicklung. Mit so vielen Konkurrenten im Nacken, darunter Westwood Studios, das Unternehmen, das den modernen RTS-Spielstil begründet hatte, mussten wir etwas entwickeln, das alle anderen in den Schatten stellte.
Und wir waren nicht mehr die Underdogs: Angesichts der anhaltenden Erfolge von Warcraft und Diablo, über die in den Medien berichtet wurde, konnten wir uns keine Nachlässigkeit gegenüber den Spielern oder der Spielepresse leisten. In der Welt der Spiele ist man nur so gut wie sein letztes Spiel. Wir mussten weit über das hinausgehen, was wir bisher erreicht hatten, und dafür mussten wir Risiken eingehen.
Neue Gesichter
Warcraft II hatte nur sechs Kernprogrammierer und zwei Support-Programmierer; das war zu wenig für den größeren Umfang von StarCraft, also wurde das Entwicklerteam um eine Gruppe neuer und unerprobter Spieleprogrammierer erweitert, die ohne viel Anleitung lernen mussten, wie man Spielecode schreibt.
Unsere Programmierleitung war schwach: Wir hatten noch nicht gelernt, wie wichtig es ist, weniger erfahrenen Entwicklern frühzeitig im Projekt Anleitung zu geben, damit sie die dringend benötigten Lektionen vor der Veröffentlichung des Spiels lernen. Für die neuen Padawane war es also eine Frage von „Friss oder stirb“. Ein großer Teil des Problems war, dass wir personell sehr dünn besetzt waren – jeder Programmierer programmierte wie verrückt, um die Ziele zu erreichen, ohne Zeit für Überprüfungen, Code-Audits oder Schulungen zu haben.
Und es gab nicht nur unerfahrene Nachwuchskräfte im Team, sondern auch der Leiter der StarCraft-Programmierung hatte noch nie eine Spiel-Engine für den Markt entwickelt. Bob Fitch programmierte seit mehreren Jahren Spiele mit großartigen Ergebnissen, aber seine bisherigen Arbeiten waren Spieleports, bei denen er mit einer bestehenden Engine arbeitete, und Feature-Programmierung für Warcraft I und II, was keine groß angelegte Engine-Entwicklung erforderte. Und obwohl er Erfahrung als technischer Leiter für Shattered Nations hatte, wurde dieses Projekt eingestellt, sodass keine Validierung der architektonischen Entscheidungen möglich war.
Das Team war unglaublich engagiert und unternahm beispiellose Anstrengungen, um das Projekt abzuschließen, wobei es seine persönliche Gesundheit und sein Familienleben opferte. Ich habe noch nie an einem Projekt gearbeitet, bei dem alle Mitglieder so hart gearbeitet haben. Aber einige wichtige Entscheidungen bezüglich der Programmierung, auf die ich gleich noch näher eingehen werde, sollten das Programmierteam für den Rest des Projekts verfolgen.
Einige Dinge haben sich geändert
Nachdem ich monatelang an der Veröffentlichung von Diablo gearbeitet hatte und danach weitere Monate mit Aufräumarbeiten und Patches verbracht hatte, kehrte ich zurück, um beim Neustart von StarCraft zu helfen. Ich hatte keine Lust, mich wieder in ein Bug-Fest zu stürzen, aber genau das passierte dann auch.
Ich dachte, es würde mir leicht fallen, wieder in das Projekt einzusteigen, da ich den Warcraft-Code so gut kannte – ich hatte buchstäblich an jeder Komponente gearbeitet. Stattdessen stellte ich mit Entsetzen fest, dass viele Komponenten der Engine verworfen und teilweise neu geschrieben worden waren.
Die Einheitenklassen des Spiels wurden gerade von Grund auf neu geschrieben, und der Einheiten-Dispatcher war weggeworfen worden. Der Dispatcher ist der Mechanismus, den ich entwickelt habe, um sicherzustellen, dass jede Spiel-Einheit Zeit hat, zu planen, was sie tun möchte. Jede Einheit fragt regelmäßig: „Was soll ich jetzt tun, nachdem ich mein aktuelles Verhalten beendet habe?“, „Sollte ich den Weg zu meinem Ziel neu bewerten?“, „Gibt es eine bessere Einheit zum Angreifen als die, auf die ich gerade ziele?“, „Hat mir der Benutzer einen neuen Befehl gegeben?“, „Ich bin tot, wie räume ich hinter mir auf?“ und so weiter.
Es gibt gute Gründe, warum Code neu geschrieben werden muss, aber das Entfernen von altem Code birgt auch Risiken. Joel Spolsky hat dies in Things You Should Never Do, Part I sehr eloquent ausgedrückt:
Es ist wichtig, sich daran zu erinnern, dass es beim Neuanfang absolut keinen Grund gibt, anzunehmen, dass man es besser machen wird als beim ersten Mal. Zunächst einmal hat man wahrscheinlich nicht einmal mehr dasselbe Programmierteam, das an der ersten Version gearbeitet hat, sodass man eigentlich gar nicht „mehr Erfahrung“ hat. Man wird einfach die meisten alten Fehler wiederholen und einige neue Probleme einführen, die in der ursprünglichen Version nicht vorhanden waren.
Die Warcraft-Engine hatte monatelange Programmierarbeit gekostet, um sie richtig hinzubekommen, und obwohl sie für neue Gameplay-Funktionen überarbeitet werden musste, würde ein neues Programmierteam nun viel Zeit damit verbringen, neu zu lernen, wie und warum die Engine ursprünglich so aufgebaut war.
Architektur der Spiel-Engine
Ich habe die ursprüngliche Warcraft-Engine für Microsoft DOS in C mit dem Watcom-Compiler geschrieben. Mit der Umstellung auf Microsoft Windows entschied sich Bob für den Visual Studio-Compiler und gestaltete die Spiel-Engine in C++ neu. Beides waren vernünftige Entscheidungen, aber zu diesem Zeitpunkt hatten nur wenige Entwickler im Team Erfahrung mit der Sprache und insbesondere mit ihren vielen Fallstricken.
C++ hat zwar seine Stärken, kann aber leicht falsch verwendet werden. Wie Bjarne Stroustrup, der Erfinder der Sprache, so treffend sagte: „Mit C kann man sich leicht selbst ins Bein schießen; mit C++ ist es schwieriger, aber wenn man es schafft, verliert man das ganze Bein.“
Die Geschichte lehrt uns, dass Programmierer sich gezwungen fühlen, beim ersten Projekt alle Funktionen ihrer neuen Sprache auszuprobieren, und so war es auch mit der Klassenvererbung in StarCraft. Erfahrene Programmierer werden erschaudern, wenn sie die Vererbungskette sehen, die für die Einheiten des Spiels entworfen wurde:
CUnit < CDoodad < CFlingy < CThingyCThingy-Objekte waren Sprites, die überall auf der Spielkarte erscheinen konnten, sich aber nicht bewegten und kein Verhalten hatten, während CFlingys zur Erzeugung von Partikeln verwendet wurden; wenn eine Explosion stattfand, drehten sich mehrere von ihnen in zufällige Richtungen. CDoodad – nach 14 Jahren glaube ich, dass dies der Klassenname ist – war eine nicht instanziierte Klasse, die dennoch wichtige Verhaltensweisen aufwies, die für das ordnungsgemäße Funktionieren der abgeleiteten Klassen erforderlich waren. Und CUnit war darüber geschichtet. Das Verhalten der Einheiten war über diese verschiedenen Module verstreut, und es erforderte ein Verständnis jeder Klasse, um etwas erreichen zu können.
Und abgesehen vom Schrecken der Klassenhierarchie war die CUnit-Klasse selbst ein unheiliges Durcheinander, das über mehrere Header-Dateien definiert war:
class CUnit ... { #include „header_1.h“ #include „header_2.h“ #include „header_3.h“ #include „header_4.h“};Jeder dieser Header umfasste mehrere hundert Zeilen, was zu einer Gesamtklassendefinition führte, die man bestenfalls als amüsant bezeichnen konnte.
Erst viele Jahre später gewann das Mantra „Komposition vor Vererbung” unter Programmierern an Glaubwürdigkeit, aber diejenigen, die an StarCraft arbeiteten, hatten dies schon viel früher auf die harte Tour gelernt.
Nur noch zwei Monate bis zur Veröffentlichung
Aufgrund der schwierigen Anfangsphase stand das Entwicklungsteam nach dem Neustart unter Druck, das Projekt fertigzustellen, und so wurden Zeitpläne herumgereicht, die zeigten, dass das Spiel in zwei Monaten veröffentlicht werden könnte.
Angesichts der Anzahl der Spielelemente und Verhaltensweisen, die hinzugefügt werden mussten, der notwendigen Änderungen für den Wechsel von Top-Down- zu isometrischen Grafiken, eines komplett neuen Karteneditors und der Hinzufügung des Internet-Spiels über Battle.net war es unvorstellbar, dass das Spiel tatsächlich in dieser Zeit ausgeliefert werden könnte, selbst wenn man davon ausging, dass das Grafikteam, die Designer, die Tontechniker, die Spielebalancer und die Tester ihren Teil der Vereinbarung erfüllen könnten. Aber das Programmierteam arbeitete in den folgenden vierzehn Monaten unermüdlich daran, das Spiel in nur zwei Monaten auf den Markt zu bringen!
Das gesamte Team arbeitete viele Stunden, wobei Bob Fitch 40, 42 und sogar 48 Stunden am Stück programmierte. Soweit ich mich erinnere, versuchte niemand sonst solche masochistischen Unternehmungen, obwohl alle unglaublich viele Stunden arbeiteten.
Meine Erfahrungen bei der Entwicklung von Warcraft, wo ich oft die ganze Nacht programmierte, und später bei Diablo, wo ich wochenlang sieben Tage die Woche mehr als vierzehn Stunden am Tag programmierte, lehrten mich, dass es keinen Sinn machte, die ganze Nacht durchzuarbeiten. Jeder Code, der nach einer bestimmten Uhrzeit am Abend eingereicht wurde [ha! was für ein passendes Wort], wurde am nächsten Tag im klaren Licht des Tages nur bereut und neu geschrieben.
Die langen Arbeitszeiten machten die Leute müde, und das ist schlecht, wenn man wissensbasierte Aufgaben zu erledigen hat, die ein Höchstmaß an Kreativität erfordern. Daher sollte es keine Überraschung sein, dass es zu Fehlern, Fehlfunktionen und regelrechten Bugs kam.
Übrigens waren diese verrückten Arbeitszeiten nicht vorgeschrieben – wir haben das einfach gemacht, weil wir großartige Spiele entwickeln wollten. Rückblickend war das dumm – wir hätten mit vernünftigeren Anstrengungen bessere Arbeit leisten können.
Eine meiner stolzesten Errungenschaften war es, vier Guild Wars-Kampagnen innerhalb von zwei Jahren zu veröffentlichen, ohne das Entwicklungsteam auf diesen dunklen Pfad zu führen.
Die häufigste Ursache für Abstürze im Spiel StarCraft
Ich habe zwar einige wichtige Funktionen in StarCraft implementiert, darunter Fog of War, Sichtlinie, Flugwegabweisung für Einheiten, Voice-Chat, KI-Verstärkungspunkte und andere, aber meine Hauptaufgabe bestand darin, Fehler zu beheben.
Moment mal: Voice-Chat! Im Jahr 1998?!? Ja, ich hatte das Ganze bereits im Dezember 1997 zum Laufen gebracht. Ich verwendete einen Voice-to-Phoneme-Kompressor eines Drittanbieters und schrieb den Code, um die Phoneme über das Netzwerk zu senden, sie zu dekomprimieren und dann auf den Computern der anderen sieben Spieler wiederzugeben.
Aber jede einzelne Soundkarte in unseren Büros erforderte ein Treiber-Upgrade, damit sie funktionierte, sofern die Soundkarte überhaupt Full-Duplex-Sound (gleichzeitige Aufnahme und Wiedergabe von Sounds) unterstützte, sodass ich leider die Empfehlung aussprach, die Idee zu verwerfen. Der Aufwand für den technischen Support wäre so hoch gewesen, dass wir mehr Geld für den Support des Spiels ausgegeben hätten, als wir mit dem Verkauf des Spiels eingenommen hätten.
Wie auch immer, ich habe viele Fehler behoben. Einige davon waren natürlich meine eigenen, aber die meisten waren schwer zu findende Fehler, die von anderen müden Programmierern geschrieben worden waren. Eines der besten Komplimente, das ich je erhalten habe, kam vor ein paar Monaten, als Brian Fitzgerald, einer der beiden besten Programmierer, mit denen ich je zusammengearbeitet habe, eine Code-Überprüfung von StarCraft erwähnte; sie waren überwältigt von der Anzahl der Änderungen und Korrekturen, die ich am gesamten Code vorgenommen hatte. Zumindest habe ich etwas Anerkennung für meine Bemühungen bekommen, wenn auch erst lange nach der Tat!
Angesichts all der Probleme, mit denen das Team zu kämpfen hatte, könnte man meinen, es sei schwierig gewesen, eine einzige große Fehlerquelle zu identifizieren, aber nach meiner Erfahrung lagen die größten Probleme in StarCraft im Zusammenhang mit der Verwendung von doppelt verknüpften Verknüpfungslisten.
Verknüpfte Listen wurden in der Engine ausgiebig verwendet, um Einheiten mit gemeinsamem Verhalten zu verfolgen. Mit doppelt so vielen Einheiten wie sein Vorgänger – StarCraft hatte maximal 1600, gegenüber 800 in Warcraft 2 – wurde es unerlässlich, die Suche nach Einheiten bestimmter Typen zu optimieren, indem man sie in Listen miteinander verknüpfte.
Wenn ich mich recht erinnere, gab es Listen für die Einheiten und Gebäude jedes Spielers, Listen für die „stromerzeugenden” Gebäude jedes Spielers, eine Liste für die Kampfdrohnen jedes Trägers und viele, viele andere.
Alle diese Listen waren doppelt verknüpft, um das Hinzufügen und Entfernen von Elementen aus der Liste in konstanter Zeit – O(1) – zu ermöglichen, ohne dass die Liste nach dem zu entfernenden Element durchsucht werden musste – O(N).
Leider wurde jede Liste „von Hand gepflegt” – es gab keine gemeinsamen Funktionen zum Verknüpfen und Entfernen von Elementen aus diesen Listen; die Programmierer fügten das Verknüpfungs- und Entfernungsverhalten einfach manuell an jeder erforderlichen Stelle ein. Und handgeschriebener Code ist weitaus fehleranfälliger als die Verwendung einer bereits debuggten Routine.
Einige der Verknüpfungsfelder wurden von mehreren Listen gemeinsam genutzt, sodass man genau wissen musste, mit welcher Liste ein Objekt verknüpft war, um es sicher zu trennen. Und einige Verknüpfungsfelder wurden sogar in C-Unions mit anderen Datentypen gespeichert, um die Speichernutzung auf ein Minimum zu reduzieren.
Das Spiel stürzte also ständig ab. Ständig.
Aber warum haben Sie das so gemacht?
Leider gab es keinen Grund für diese Probleme mit verknüpften Listen. Mike O’Brien, der zusammen mit Jeff Strain und mir ArenaNet gegründet hat, schrieb eine Bibliothek namens Storm.DLL, die mit Diablo ausgeliefert wurde. Neben vielen anderen Funktionen enthielt Storm eine hervorragende Implementierung doppelt verknüpfter Listen unter Verwendung von Vorlagen in C++.
Während der ersten Entwicklungsphase von StarCraft wurde diese Bibliothek verwendet. Aber schon früh in der Entwicklung hat das Team den Code herausgenommen und die verketteten Listen von Hand geschrieben, insbesondere um das Schreiben von Spielstanddateien zu vereinfachen.
Lassen Sie mich kurz auf Spielstände eingehen, um das Ganze zu verdeutlichen.
Spielstände
Viele Spiele, die ich vor der Entwicklung von Warcraft gespielt habe, hatten eine miserable Spielstandfunktion. Gamer, die jemals ein Spiel von Origin gespielt haben, werden sich daran erinnern, wie laaaaaange es gedauert hat, Spielstanddateien zu schreiben. Sicher, sie wurden von langsamen Mikroprozessoren auf Festplatten geschrieben, die – nach heutigen Maßstäben – so unterschiedlich sind wie Dreiräder und Rennwagen. Aber es gab keinen Grund, warum sie so schlecht sein mussten, und ich war entschlossen, dass Warcraft diese Probleme nicht haben würde.
Also hat Warcraft einige Tricks angewendet, um große Speicherblöcke in einem Stück auf die Festplatte zu schreiben, anstatt sich durch den Speicher zu schlängeln und hier und da ein bisschen zu schreiben. Das gesamte Einheiten-Array (600 Einheiten mal ein paar hundert Bytes pro Einheit) konnte in einem Stück auf die Festplatte geschrieben werden. Und alle nicht pointerbasierten globalen Variablen konnten ebenfalls in einem Stück geschrieben werden, ebenso wie jede der Spielgelände- und Fog-of-War-Karten.
Seltsamerweise war diese Möglichkeit, die Einheiten in einem Stück auf die Festplatte zu schreiben, für die Geschwindigkeit beim Schreiben von Spielstanddateien nicht entscheidend, obwohl sie den Code drastisch vereinfachte. Aber es funktionierte vor allem deshalb, weil Warcraft-Einheiten keine „Zeiger”-Daten enthielten.
StarCraft-Einheiten, die, wie bereits erwähnt, Unmengen von Zeigern in den Feldern für verknüpfte Listen enthielten, waren eine ganz andere Sache. Es war notwendig, alle Link-Zeiger zu korrigieren (unter besonderer Berücksichtigung der vereinigten Zeigerfelder), damit alle 1600 Einheiten auf einmal geschrieben werden konnten. Und dann mussten die Link-Zeiger wieder rückgängig gemacht werden, um weiterspielen zu können. Igitt.
Zurückwechseln!
Nachdem ich also viele, viele Fehler in den verknüpften Listen behoben hatte, argumentierte ich vehement, dass wir wieder zu den verknüpften Listen von Storm zurückkehren sollten, auch wenn das den Code zum Speichern des Spiels komplizierter machte. Wenn ich „vehement argumentiert” sage, sollte ich erwähnen, dass das mehr oder weniger die einzige Art war, wie wir bei Blizzard zu argumentieren wussten – mit unserer jugendlichen Dreistigkeit und arroganten Überheblichkeit gab es kein Argument, das nicht vehement war, es sei denn, es ging um das Mittagessen an diesem Tag, worüber niemand wirklich entscheiden wollte.
Ich habe diese Diskussion nicht gewonnen. Da wir nur noch „zwei Monate“ bis zur Veröffentlichung hatten, wurden Verbesserungen an der Engine regelmäßig zugunsten von Notlösungen für bestehende, aber suboptimale Lösungen zurückgestellt, was zu vielen Monaten des Leidens führte, so sehr, dass es seitdem meine Herangehensweise an das Programmieren (zum Besseren) beeinflusst hat.
Weitere Notlösungen: Wegfindung in StarCraft
Ich möchte noch ein weiteres Beispiel für das Überdecken von Fehlern anstelle der Behebung des zugrunde liegenden Problems anführen: Als StarCraft von Top-Down-Grafiken auf isometrische Grafiken umgestellt wurde, blieb die Rendering-Engine für die Hintergrundkachelgrafiken, die auf Code zurückging, den ich 1993/94 geschrieben hatte, unverändert.
Das Rendern von isometrisch aussehenden Kacheln mit einer Engine für quadratische Kacheln ist nicht schwer, allerdings gibt es Schwierigkeiten, Dinge wie Karteneditoren richtig zum Laufen zu bringen, da das Ablegen einer Kartenkachel auf einer anderen viele „Kantenkorrekturen” erfordert, da der Karteneditor versucht, diagonal geformte Bilder, die in quadratischen Kacheln gezeichnet sind, zu platzieren.
Während das Rendern nicht so schlimm ist, war die isometrische Wegfindung auf quadratischen Kacheln sehr schwierig. Anstelle von großen (32×32 Pixel) diagonalen Kacheln, die entweder passierbar oder unpassierbar waren, musste die Karte in winzige 8×8-Pixel-Kacheln unterteilt werden – was die Anzahl der Wegsuchvorgänge um das 16-fache erhöhte und Schwierigkeiten für größere Einheiten verursachte, die sich nicht durch einen schmalen Weg quetschen konnten.
Wäre Brian Fitzgerald nicht ein hervorragender Programmierer gewesen, hätte das Problem der Wegfindung die Veröffentlichung des Spiels auf unbestimmte Zeit verhindert. Tatsächlich war die Wegfindung eines der Probleme, die erst am Ende des Projekts endgültig gelöst wurden. Ich habe vor, mehr über die Wegfindung in StarCraft zu schreiben, da es viele interessante technische und gestalterische Aspekte gibt.
Ende von Teil 1
Sie haben mich also ein wenig darüber jammern hören, wie schwierig es war, StarCraft zu entwickeln, was vor allem auf schlechte Entscheidungen auf allen Ebenen des Unternehmens hinsichtlich der Ausrichtung, der Technologie und des Designs des Spiels zurückzuführen war.
Wir hatten das Glück, ein tollkühnes, aber tapferes Team zu sein, und unsere Scharfsichtigkeit hat uns zum Erfolg verholfen. Am Ende haben wir uns zusammengerissen und lange genug durchgehalten keine neuen Funktionen mehr hinzuzufügen, um das Spiel auf den Markt zu bringen, und die Spieler haben nie etwas von dem Chaos hinter den Kulissen mitbekommen. Vielleicht ist das ein weiterer Vorteil von kompilierten Sprachen gegenüber Skriptsprachen wie JavaScript – Endbenutzer sehen nie das Desaster!
Im zweiten Teil dieses Artikels werde ich noch technischer werden und darüber sprechen, warum die meisten Programmierer verknüpfte Listen falsch verstehen, und dann eine alternative Lösung vorschlagen, die erfolgreich für Diablo, Battle.net und Guild Wars verwendet wurde.
Und selbst wenn Sie keine verketteten Listen verwenden, lassen sich dieselben Lösungen auf komplexere Datenstrukturen wie Hash-Tabellen, B-Bäume und Prioritätswarteschlangen übertragen. Darüber hinaus glaube ich, dass sich die zugrunde liegenden Ideen gut auf die gesamte Programmierung übertragen lassen. Aber wir wollen nicht zu weit vorgreifen; das ist ein Thema für einen anderen Artikel.
Vielen Dank, dass Sie bis hierher gelesen haben, und entschuldigen Sie bitte, dass ich noch nicht herausgefunden habe, wie man prägnant schreibt.
Quellenangaben:
- Artikel: Code of Honor – Tough times on the road to Starcraft (englisch)
- Autor: Patrick Wyatt
- Software: DeepL