Postmortem Asteroids
Inhaltsverzeichnis
Postmortem: Asteroids
Vorwort
Herzlich willkommen zu diesem Postmortem zu der Entwicklung von Asteroids. In folgendem Artikel möchte ich genauer darauf eingehen, mit welcher Einstellung ich an das Projekt heran gegangen bin, wo ich auf Probleme gestoßen bin, bzw. was einwandfrei funktioniert hat. Letzten Endes möchte ich noch darauf eingehen, was ich aus diesem Projekt gelernt habe, und was ich beim nächsten Mal anders machen würde.
Die ersten Schritte oder der Urschleim
Wie wohl die meisten Programmierer träumte und träume ich auch heute noch, von dem eigenen DOOM3. In meinem jugendlichen Übermut begann ich also einen kleinen 3D-Weltraumshooter zu schreiben. Soweit lief alles wunderbar. Irgendwann sah ich mich jedoch mit dem Problem konfrontiert, dass man weder gegen eine halbwegs intelligente KI, noch im Netzwerkmodus gegen andere Spieler antreten konnte. Was hilft einem also ein Shooter mit tollster Grafik, wenn man keine Gegner hat? Nun ja! Ich will nicht übertreiben. Auch grafisch war das Spiel kein Hammer, denn ich bin kein Künstler und so fehlte es mir an guten Modellen und Texturen. So entschied ich mich, das Projekt vorerst einzufrieren. Ich kam zu dem Entschluss, ein Spiel zu schreiben, bei dem sowohl die Künstliche Intelligenz als auch ein Netzwerkmodus einfacher zu realisieren sind. Außerdem sollte sich der Bedarf an Modellen und Grafiken in Grenzen halten. Daher kam es zu dem radikalen Umschwung von 3D auf 2D. Die Wahl fiel auf Asteroids, weil ich hier auch einige Codeschnipsel aus dem Shooter verwenden konnte.
Die Erkenntnis
Die Grundeinstellung, mit der ich an das Projekt heran ging, lässt sich ganz einfach beschreiben: Schreibe ein Spiel, welches spielbar ist und in absehbarer Zeit fertig wird. Aus diesem Grund erstellte ich eine genaue Projektplanung. Zuerst wollte ich mich auf das Spielerische konzentrieren. Und damit meine ich nicht etwa, welche Asteroidentypen oder verschiedenen Spielmodi es später im Spiel geben sollte, sondern das simple Herumfliegen, Schießen, Explodieren und Spawnen. An der Grafik könnte ich später immer noch feilen. Diese Einstellung hat sich bei mir bewährt, und sie ist es, mit der ich an jedes neue Projekt heran gehe.
Gelernt, wie man ein solches Spiel am Besten aufbaut, habe ich aus dem Bomberman-Tutorial von Sascha Willems. Ich versuchte den Code so flexibel wie möglich aufzubauen. So wurde z.B. eine Grundklasse erstellt, von welcher ich alle anderen Klassen für z.B. Spieler oder Asteroiden ableiten konnte. Dies hat Änderungen jederzeit effizient möglich gemacht. Außerdem konnte ich auf diverse Manager zurückgreifen, die ich bereits vorher entworfen hatte. Dazu zählt u.a. ein Texturenmanager, Fontmanager, Modelmanager und ein Soundmanager.
Auf diese Art und Weise verlief die Entwicklung sehr schnell und problemlos. Nach knapp 5 Tagen hatte ich bereits die erste spielbare Version fertig gestellt. Zwei weitere Tage habe ich benötigt, um mich um den Augenschmaus wie z.B. Licht- oder Partikeleffekte zu kümmern. Angetrieben durch den Feedback, denn ich aus dem Forum erhielt integrierte ich mehrere Spielmodi, die das Spiel interessanter und vielseitiger gestalten sollten.
Das bissel Drumherum
Als ich begann mich um die Menüs zu kümmern musste ich schnell feststellen, dass Menüs wohl zu den Dingen gehören, die ich vom Aufwand her unterschätzt hatte. Ein Hauptmenü mit ein paar Buttons lässt sich noch relativ leicht realisieren. Da ich aber auch Dinge wie Tastaturbelegung und Bildschirmeinstellungen über die Menüs regelbar machen wollte, reichten Buttons allein nicht aus. Durch den Menümanager, der sich mit der Zeit entwickelte, konnten später Dinge wie eine Highscore oder ein einfaches Menü zum Ändern der Steuerung relativ einfach implementiert werden. Alles in allem hat die Entwicklung der Menüs und selbstverständlicher Features wie die Änderung der Bildschirmeinstellungen weit mehr Zeit in Anspruch genommen, als die Entwicklung des Spiels selbst. Aber auch hier konnte ich mich nicht beklagen, denn die Entwicklung ging sichtlich voran. Dies kann unheimlich motivierend sein. Nichts ist demotivierender als an etwas zu basteln, ohne einen Fortschritt erkennen zu können.
Am Rande der Verzweiflung
Das größte Problem war jedoch der Netzwerkmodus. Da ich mich mit diesem Thema bisher nicht weiter auseinander gesetzt hatte, versuchte ich mich mit den Indykomponenten. Das Problem, vor dem ich mich schnell stehen sah, war das der Synchronisation. Mit den Indykomponenten traten immer wieder Fehler auf, auf die ich keinen Rat wusste. Letzten Endes stieg ich völlig entnervt, dank dem Tipp von Sascha Willems, auf die Windows Sockets um. Diese erlaubten mir eine vereinfachte Fehlersuche und damit gelang letztendlich auch der Durchbruch. Trotzdem waren Wochen vergangen, bis ich einen halbwegs funktionierenden Netzwerkcode hatte, bei dem der Nutzer des ein Clients, das selbe Spiel spielte, wie der Nutzer eines anderen.
Hinzu kam, dass ich den Code des Spieles ständig umstrukturieren musste, da ich ihn trotz allen Überlegungen viel zu unflexibel gestaltet hatte. Merke: Erst, wenn man bei all den eigenen Prozeduren und Funktionen den Überblick verliert, hat man einen wirklich flexiblen Code. Im Ernst! Man sollte den Code in so viele kleine Prozeduren und Funktionen unterteilen, wie möglich. Erst wenn der gesamte Spielablauf theoretisch über eine Konsole gesteuert werden kann, hat man ganze Arbeit geleistet.
Nachwort
Ich hoffe, dass Ihr aus diesem Postmortem etwas gelernt habt, was euch bei künftigen Projekten hilfreich sein könnte. Weiterhin hoffe ich, Euch hiermit zu neuen Projekten angespornt zu haben. Nehmt Euch lieber erst einmal ein kleines Projekt vor, welches Ihr aber fertig stellen könnt. Mit all dem Wissen, welches Ihr dabei erwerbt, könnt Ihr Euch dann auch an ein größeres wagen. Außerdem habt Ihr mit dem kleinen Projekt zumeist bereits eine kleine Codebasis geschaffen, die in weiteren Projekten zum Einsatz kommen kann.
Euer
Magellan
