Glider

F: Wie groß ist Ihr Team und wie lange haben Sie gebraucht, Glider zu entwickeln? Was hat am meisten Zeit in Anspruch genommen?

A: Die REVOgames GbR hat 5 Mitglieder: 1) André Weinhold, Managing Director, 2) Dennis Kühn, Product Director, 3) Markus Pfeiffer, Technical Director, 4) Jürgen Rabe, Creative Director, 5) Dirk Rosenlöcher, freier Mitarbeiter.

Das Team konzentriert sich hauptsächlich auf die Fertigstellung unseres ersten Projektes Glider – collect’n kill, das der Grundstein für weitere Ideen und Aufgaben sein soll. Glider wurde in Deutschland am 10. Oktober 2005 veröffentlicht und hat großartige Kritiken bekommen. Die Entwicklungszeit war recht lang, aber das war notwendig, um unser erstes Spiel mit Erfolg abzuschließen.

Die zeitaufwändigste Aufgabe ist die Übersetzung, weil wir nicht in einem Büro oder so arbeiten. Außerdem wurde Glider – collect’n kill nur in unserer Freizeit entwickelt, also an Wochenenden und nach der Schule. Wir sind stolz darauf, dass Projekt fertiggestellt zu haben und das Team hat nun mehr Erfahrung, damit wir beim nächsten Mal besser vorbereitet sind.

F: Ich hörte, dass Sie noch einen Publisher suchen; wie gut kam Glider in den Medien an?

A: Anfangs glaubte uns niemand und niemand hatte je etwas von Glider oder REVOgames gehört. Dies alles änderte sich erst mit der Games Convention 2004; einige der deutschen Publisher warfen ein Auge auf uns, obwohl Glider – collect’n kill ein Gelegenheits- und ein Budgetspiel ist. Auf der Quo Vadis 2005 wurde die Qualität unseres Projektes dann erkannt und von da an lief alles sehr glatt. Wir haben ein Fernsehinterview auf RTL II gegeben und viele Zeitschriften haben Artikel und Reviews über REVOgames und unseren Erfolg veröffentlicht.

F: Wie groß ist der Code für ein Spiel wie Glider?

A: Momentan haben wir über 11 MB Code für alle Tools und Mechaniken. Ein Teil des Codes besteht aus WDL-Dateien und der Rest ist die game.dll, die einige Teile des Level Managers und die gesamte KI enthält.

F: Beschreiben Sie bitte eines der größten Probleme, mit dem Sie konfrontiert wurden und wie Sie es gelöst haben.

A: Das größte Problem war das Fehlen einiger Engine Features, die es nur in Beta Versionen gab. Wir mussten eigenen Code schreiben und manchmal auch zu anderen Lösungen und “dirty hacks” greifen. Es ist viel besser, ein Spiel mit der offiziellen Engineversion zu entwickeln als mit der Beta. Das ist einer der Gründe für die 6-jährige Entwicklungszeit von Glider.

Das Bot Konzept von Glider hat sich mit der Zeit auch geändert. Anfangs haben wir ziemlich lange nachgedacht wie wir die KI angehen wollen, weil wir alle Neulinge auf dem Gebiet waren und das Problem etwas unterschätzten. Wir wollten, dass die Bots eine Herausforderung darstellen, realistisch flogen und auch auf langsamer Hardware funktionierten. Was muss ein guter, intelligenter Bot können? Er muss durch die Spielwelt navigieren, seine Umgebung wahrnehmen, insbesondere Feindbewegungen und den eigenen Status und er muss Entscheidungen treffen wie er sich verhalten soll. Um die Bewegungen der Bots möglichst realistische zu gestalten, verwenden diese denselben Lenkmechanismus wie ein menschlicher Spieler, sie simulieren also Mausbewegungen und Kommandos zum Feuern bzw. Waffe wechseln.

Das erste Problem, das wir angehen wollten war die Navigation. Wie sich jeder Spieldesigner vorstellen kann ist freie Bewegung im dreidimensionalen Raum eine ziemliche Herausforderung. 2003 dachten wir also über Quadtrees und echte Bewegungsfreiheit nach. Es dauerte fast ein Jahr bis wir akzeptieren, dass dieses Konzept für uns nicht funktioniert. Es war einfach zu langsam und es gab zu viele Probleme. In dieser Zeit haben wir etliche Algorithmen entwickelt, die zwar in den ersten Levels gut funktionierten, aber in den größeren absolut fehlschlugen, weil die Möglichkeiten unseres Node Compilers von der Acknex Engine begrenzt wurden.

Schließlich entschieden wir uns für einen Ansatz, der Wegpunkte nutzt; der Leveldesigners positioniert diese und sie werden automatisch verbunden. Der Suchalgorithmus ist dann wie immer eine leicht abgewandelte Version des A* Algorithmus. Wir hatten nun erheblich weniger Wegpunkte in den Levels und haben außerdem jedes Item mit einem Knotenpunkt versehen, so dass die Suche nach Items leichter wurde.

Anfangs haben wir ein schickes selbstgeschriebens Format für die Leveldaten benutzt, das die Nodes, KI, Items etc. enthalten sollte. Das wurde von den Unix Parser Tools fle x und yacc ermöglicht. Später lernte ich dann mehr über XML und wollte das überall verwenden. Aber wie es manchmal ist, es gab keine Zeit das gesamte Ressourcen Management System neu zu implementieren.

F: Benutzen Sie Technicken, mit denen auch die Besitzer eines bescheideneren Systems glücklich sein können? Falls ja, bitte teilen Sie uns diese mit.

A: Glider läuft auch auf “alten” Rechnern mit hoher Framerate. Um das zu erreichen mussten wir viele Optionen anbieten, z.B. die Möglichkeit, Partikeleffekte ein oder auszuschalten. Außer der direkten Grafikprogrammierung sind auch interne Tricks verwendet worden. Zum Beispiel führt jedes Schiff in Glider nur einen Trace pro Frame aus und stellt die Ergebnisse den anderen Schiffen zur Verfügung. Wir benutzen auch nicht jedes Mal c_move; wir haben einen eigenen Codeteil entworfen, der zwischen dem alten (schnelleren) Movement Code und dem neuen entscheidet, so dass wir polygongenaue Kollisionserkennung bei großer Geschwindigkeit haben. Dieses System kommt auch beim Netzwerk zum Einsatz, damit der Spieler ein ruckelfreies Spielerlebnis hat. Außerdem verwenden wir einen LOD; so gelingt es uns, die Skript-Zeit auch auf langsameren Rechnern gering zu halten.

F: Was ist die typische Verzögerung in einem regulären LAN Multiplayer Spiel?

A: Ein Wert von 10 – 15 ms ist normal.

F: Geben Sie uns bitte einige Tipps für Anfänger.

A: Entwickeln Sie Ihr Spiel in Modulen und fügen Sie diese zusammen, nachdem sie allein getestet wurden!

Vielen Dank, André.