Path of Enlightenment

Gordon Tackett ist in diesem Monat unser Gast und er gibt uns nützliche Informationen.

F: Ich würde sagen, dass Path of Enlightenment ein gutes Beispiel für ein Gelegenheitsspiel ist. Wie groß ist Ihr Team und wieviel Zeit steckt in der Entwicklung des Spiels?

A: Für die Entwicklung war ich allein verantwortlich. Ich habe die Grafiken in Paint Shop Pro X2 erstellt und dabei oft das Programmierungsinterface genutzt, um die Bausteine gut hinzubekommen. Die Entwicklungszeit betrug nur etwa vier Monate.

F: Wie haben Sie das "golden path" System implementiert, welches den Pfad zwischen der Startposition und dem Ziel behält?

A: Dafür habe ich mehrdimensionale Arrays aus lite-C benutzt. Um zu verstehen wie das System funktioniert, braucht man ein wenig Hintergrund. Die achteckigen Teile auf dem Bildschirm sind geschichtete Panels. Die einzelnen Schichten sind der Hintergrund des Feldes, der Pfad, das Medallion in der Mitte, die Farbe und das blockierende Objekt. Was man auf dem Bildschirm sieht ist also eher ein dreidimensionales Array von Panels. Ein Kontrollarray beinhaltet den aktuellen Typ des Feldes, die Ausrichtung, den Zustand und die Zahl der Klicks. Ein Feldarray speichert die Pfaddaten für die einzelnen Felder. Es gibt ähnliche Arrays für die quadratischen Felder. Mit Hilfe einer rekursiven Funktion folge ich den Pfaden von der Oberseite des Feldes ausgehend im Uhrzeigersinn um zu sehen, ob es Verbindungen zu anderen Feldern gibt. Falls ja folge ich dem Pfad bis ich alle Verbindungen gefunden habe. Unterwegs wird die jeweilige Farbe geändert.

Falls ich irgendwann das Zielfeld erreiche, arbeite ich mich wieder zurück durch die rekursiven Aufrufe und schalte die Teile des Pfades ab, die nicht Teil des Zielpfades sind. Mit Hilfe des Flare Flags werden alle Panels markiert, die bearbeitet wurden. Dieses Flag wird am Schluss wieder für alle Panels deaktiviert. Falls das Zielfeld nicht erreicht wird, starte ich dort erneut und mache dasselbe, aber die Farbe ändert sich auf andere Art. Dies ist vielleicht der komplexeste Teil des Spiels. Es wird zwischen den Frames ausgeführt und der Code musste sehr kompakt sein. Deshalb habe ich so viele Arrays, um die Daten so weit wie möglich im Vorfeld berechnen zu können.

F: Wie merken Sie, welche Blöcke zerstört sind und auf welche Weise werden die neuen Blöcke erstellt, die dann auf ihre Position rutschen?

A: Zunächst werden die zerstörten Blöcke unsichtbar gemacht. Dann startet jeder Block, der nachrutschen muss eine Prozedur, die diesen von A nach B rutschen lässt. In dieser wird der Block auf Position B kopiert und die Panels bei A werden verborgen. Die Panels an Punkt B werden dann durch Änderung von pos_y auf den Ort von A gesetzt und dann wird dieser pos_y Wert langsam geändert, damit sich der Block bewegt. Die Prozedur endet, wenn er an der Anfangsposition ist. Neue Blocks kommen ebenso hinzu. Das sind nur einige einfache Zuweisungen und Schleifen.

F: Wie haben Sie das 60 Minuten Demo System implementiert?

A: Das war einer der einfachsten Teile. Ich musste nur einen Zähler alle paar Sekunden hochzählen und diesen in der Registry zu speichern. Es ist vielleicht ein wenig komplizierter, aber nur deshalb, weil ich den Namen des Käufers und den Zugangscode mit verschlüssele. Mit einigen einfachen Verschlüsselungstechniken konnte ich so mein Ziel erreichen.

F: Was haben Sie bei der Entwicklung gelernt?

A: Die erste Sache die ich gelernt habe (für den Gelegenheitsspielmarkt) ist, dass man eine Idee schnell umsetzen muss wenn man sie hat. Die Spielidee für dieses Spiel kam vor über anderthalb Jahren auf. Wenn ich das Spiel dann programmiert hätte, wäre es bestimmt von einem oder mehreren der großen 4 in diesem Bereich übernommen worden.

Zweitens habe ich gelernt, dass Panels mächtiger sind als man denkt. Ich habe auch die Erfahrung gemacht, dass Knöpfe für Menü Items eine ziemliche Einschränkung sind. Ich arbeite derzeit an einem voll funktionierenden Menüsystem. Ich arbeite ebenfalls an einer Bibliothek für Paneleffekte. Diese Bilbiotheken werden auf unserer Website -  http://www.westmarch.com - separat erhältlich sein. Ich biete einen Rabatt auf das Spiel an und lege die Bibliotheken bei, exklusiv für die Leser dieses Magazins. Wenn Sie das Spiel bestellen, verwenden Sie den Promo Code aum80reader für einen Rabatt von 40% und Sie erhalten die Bibliotheken kostenlos.

F: Wie planen Sie, Werbung für Ihr Spiel zu machen?

A: Zur Zeit muss ich mich darauf beschränken, selbst Werbung zu machen. Die Spielmechanik (Felder drehen um einen Pfad zu bilden) verkauft sich angeblich nicht mehr gut, zumindest wenn man den Publishern glauben darf, die mir Feedback gaben. Meine eigene Werbung bringt Verkäufe, aber natürlich nicht in dem Umfang, wie ich es mit einem Publisher erreicht hätte, wäre ich mit dem Spiel eher da gewesen. Meine Lehre daraus ist "Kopf hoch und weiter".

F: Können Sie uns einige Tipps für Anfänger geben?

A: Sobald Sie eine gute Idee für ein Gelegenheitsspiel haben, schreiben Sie eine Story und starten Sie die Programmierung. Verwenden Sie einfache Grafiken in der richtigen Größe, um loszulegen. Sobald der Code funktioniert, verschönern Sie die Grafiken, passen Sie diese an die Story an und vollenden Sie das Spiel. Falls Sie sich nicht besonders gut mit Musik und Soundeffekten auskennen, können Sie gute Beispiele für wenig Geld bekommen (http://www.shockwave-sound.com). Sie können auch kostenlose Sounds im Internet finden, Sie müssen nur sicherstellen, dass diese frei verfügbar sind. Auf diese Art können Sie auch Grafiken finden. Oder Sie verwenden echte Objekte für Grafiken. Der Rahmen im Optionsmenü ist ein Foto eines Bilderrahmens, der $5 gekostet hat. Für diesen Markt ist es die Programmierung und die Grafik, die das Spiel verkaufen wird.

F: Was können Sie uns über DogMaster sagen? Was ist das und wie hilft es der 3DGS Gemeinschaft?

A: Als dieses Spiel wuchs wurde es schwerer, die Übersicht zu behalten, welche Funktion was tat und welche Parameter jeweils nötig waren (TPoE hat etwa 10.000 Codezeilen und 4.000 Zeilen Dokumentation in etwa 20 Dateien). Ständig alle Quelltextdateien offen zu haben um zu sehen, was eine Funktion braucht oder nach einer Funktion zu suchen, die das Gewünschte leistet, hat viel Zeit gekostet. Ich habe DocMaster entwickelt, um die Dokumentation aus dem Quelltext herauszuhalten und sie leichter zu finden. Nur die Dokumentation ohne den Code zu haben hat meine Produktivität sehr erhöht.

Vielen Dank, Gordon.

Gordon Tackett <gt@westmarch.com>

Owner, Westmarch Studios