Aller Anfang ist leicht

Als wir beschlossen hatten, mit der Entwicklung eines Spiels zu beginnen, machten wir uns zunächst viel zu lang Gedanken darüber, was für ein Spiel es denn sein sollte, sowie dass die Idee ausgefallen und die Story packend sein müsste. In einem Anflug von Weisheit entschieden wir uns aber dann für die simple Variante eines kleinen Zombie-Shooters, um uns nicht in einer Komplexität zu verzetteln und erst einmal die Grundlagen zu lernen.

unityEditorNachdem wir uns ein wenig nach Engines umgesehen hatten, fiel die Wahl erst einmal auf Unity. Wir haben auch diskutiert, ob wir nicht eine offenere Variante nehmen sollten, in der wir tiefere Eingriffsmöglichkeiten hätten, denn als Informatiker hat man das natürliche Bedürfnis, auch an der letzten Schraube zu drehen und zudem auch den Ehrgeiz, Problemstellungen selbst zu lösen und keine Funktionalität von der Stange zu verwenden (fühlt sich ein bischen wie cheaten an). Aber letztlich entschieden wir uns dagegen; denn es verhält sich ja so: Natürlich kann man einen Textparser selber schreiben, natürlich kann man einen Szeneneditor selber schreiben, aber damit gehen die Monate ins Land und das eigentliche Kernstück des Spiels, das Gameplay, findet in dieser Zeit keine Beachtung. Und seien wir ehrlich: in fast jeder Sprache oder Engine wird man auf fertige Bibliotheken zurückgreifen, denn wer möchte sich antun, beispielsweise einen FBX-Importer selbst zu verfassen?

Als nächstes versuchten wir uns zu organisieren. Da wir keine klassische Kombo von Programmierer und Grafiker darstellen, war klar, dass sich Arbeitsbereiche überschneiden würden. Und da wir zudem an verschiedenen Standorten tätig sind, brauchten wir eine Möglichkeit der zentralen Ablage, der Versionierung und ggf. Zusammenführung von Arbeitsständen. Hierbei entschieden wir uns aufgrund von Erfahrung für BitBucket (https://bitbucket.org/). Dadurch erhält man eine kostenlose Online-Ablage für seine Aufgaben und seine Daten, auf die dann mittels eines Clientprogramms zugegriffen werden kann. Bei diesem haben wir uns für SourceTree vom gleichen Anbieter entschieden (https://www.sourcetreeapp.com/). Durch diese Konfiguration ist es nun möglich, lokal vor sich hin zu werkeln und einzelne Versionsstände zu sichern und zu einem beliebigen Zeitpunkt mit der Online-Ablage abzugleichen. So kommt man wieder auf den selben Stand wie die Mitstreiter und stellt die eigenen Änderungen den anderen zur Verfügung. Dies hat bislang ganz gut funktioniert, man sollte sich jedoch trotzdem ein wenig absprechen: Wenn zwei Personen an der gleichen Datei arbeiten, besteht immer die Gefahr, dass nicht beide Änderungen übernommen werden. Das funktioniert generell auch nur für textbasierte Dateien und nicht beispielsweise für Bilder oder 3D-Modelle. In Unity selbst lässt sich z. B. auch einstellen, dass Projekt- und Szenendateien textbasiert gespeichert werden.

Nun wollten wir ja mit unserem ersten Projekt alle Arbeitsschritte kennen lernen. Dennoch haben wir die Konzeptphase, ein Design-Dokument oder Styleguides mal komplett übersprungen und haben erst mal drauflos probiert. Im Nachhinein ist das auch nicht unbedingt ein schlechter Ansatz, denn so konnten wir Unity anhand eines eigenen Beispiels kennenlernen und neues Wissen gleich integrieren und verfestigen. Beim nächsten Projekt wird das selbstverständlich ganz anders werden ;). Nach und nach bauten wir also einen Testlevel auf, modellierten Gegenstände, schrieben C#-Skripte, versuchten uns an der Animation der Spielfigur, lernten die Physik-Engine und Ragdolls (Juhuu!) kennen und fügten immer neue Ideen ein. Übertrieben gesagt fragten wir nicht: Wie kann Unity unsere Anforderungen erfüllen? Sondern: Wie können wir dieses und jenes Feature von Unity für uns nutzen? Meiner Erfahrung nach ist das Lernen in dieser Art und Weise deutlich effektiver als reines Lesen oder Schauen von Tutorials auf Youtube. Diese sind aber dennoch nicht weg zu denken, sei es als Inspiration oder auch um Probleme zu lösen, über die man im Verlauf seines Projekts stolpert (einen Youtube-Kanal möchte ich an dieser Stelle noch erwähnen, der mir nach viel Herumprobieren letztlich am besten den Einstieg in Unity ermöglicht hat: quill18creates).

Der Nachteil dieser Herangehensweise ist uns natürlich auch klar geworden, insbesondere die Skripte mussten immer wieder umgebaut werden und gleichen mittlerweile einem Flickenteppich. Auch sind spätere Skripte anders geschrieben als frühere und somit etwas inkonsistent (Beispiel: Awake() oder Start() nutzen? Komponenten per getComponent() suchen oder im Editor verdrahten?). Das kann natürlich auch Frust erzeugen, aber unser Vorgehen hatte doch den großen Vorteil, dass wir schnell Fortschritte gesehen haben und so die Motivation aufrecht erhalten werden konnte.

Lässt sich also festhalten, dass uns die Wahl von Unity, das überschaubare Szenario und ein nur halb-geplantes Vorgehen schnell haben starten und lernen lassen. Für den Einstieg ist das eine schöne Sache, man sollte sich nur im Klaren sein, dass eben dieses erste Projekt vermutlich kein großer Wurf werden wird. Daher sollte man auch nicht gleich mit seinem lang gehegten Traumprojekt loslegen, sonst wird man letztlich nur enttäuscht sein.