Das dritte Semester meines Studiums verbrachte ich in Kopenhagen, an der København Erhvervsakademi. Anders als die HTW legt diese den Schwerpunkt ihres Multimediadesign-Studiums nicht auf Videoproduktion (Angesichts der vielen grossen dänischen Filmschulen wäre dies wohl irgendwie überflüssig), sondern auf das Web. So kam ich im dritten Teil des Semesters (Fächer werden konsekutiv belegt) in den Genuss des Kurses «Casual Games», wo ich unter Anleitung zweier junger Programmierer grundlegende Theorie zum Thema und praktische Entwicklung mit Javascript kennen lernten. Zurück an der HTW musste durfte ich mich wieder mit Digezzprojekten beschäftigen. Da ich schon am Anfang meiner Digezzkarriere über die Entwicklung eines HTW-geprägten Spiels nachgedacht hatte, sah ich meine Stunde dank der erhaltenen Fähigkeiten nun gekommen.
Eitschpii II als Protagonist
In der Nachbarschaft der HTW wirken relativ viele Mähroboter, so auch vor unserer Cafeteria. Eigenschaften wie die Charakterhaftigkeit eines Roboters als Protagonist, die geradlinigen Bewegung auf einer zweidimensionalen Fläche und die Begrenztheit jener, die natürlichen Prinzipien des Robotertods (und somit Spielverlusts) und die Verbundenheit zur HTW Chur machten Eitschpii zum klaren Hauptcharakter. Daneben bietet Eitschpii aber weitere interessante Eigenschaften: Eitschpii hat ein etwas drolliges Verhalten (Das ziellose Rollen) und trägt wortwörtlich einen Namen. Dazu kommt etwas das wie Augen aussieht und ein natürliches Habitat. Er bzw. sie besitzt also eine Art der Persönlichkeit, womit eine Historie einhergeht. Dieses Abstrahieren von lokalen Eigenheiten, und das Andichten von nicht bekannten Fakten zwecks dem Erzählen einer Geschichte halte ich, in Massen, für eine extrem spannende Weise, regionale, nicht-journalistische Welten und eine Art Marke zu kreieren.
Storytelling
Geschichten zu spinnen und zu erzählen gehört zu den Kernfähigkeiten des Multimediaproduzenten, Brandmanagers, Filmkonzeptionisten und so weiter. Viele Alltagsgegenstände lassen sich so in Storys verwandeln: Woher kommen die solarbetriebenen Abfalleimer vor dem Hauptgebäude? Warum sind die „Münder“ der normalen Eimer plötzlich zugetapet? Waren das die Neuen? Sind sie Bösartig? Ist hier eine Invasion epischen Ausmasses im Gange? Wird irgendwer versuchen zurückzuschlagen?
Oder: Warum gibt es am Kaffeautomaten immernoch diese Milkshakes, obwohl niemand mehr als einmal so einen kauft? Wo kommt die toxische Brühe überhaupt her, und warum leuchtet sie so rosa?
Ich nenne diese beiden Beispiele aus einem guten Grund: Beide waren an einer Stelle in der Entwicklung Teil des Spiels. Jedoch haben die Eimer alle „features“ seitlich und sind von oben betrachtet nur Quadrate, passen also nicht in ein Spiel aus der Vogelperspektive. Und wer nie an einem der Kaffeautomaten war, hat neben einem noch intakten Verdauungstrakt keine Ahnung von der Surrealität der angesprochenen Shakes. Ausserdem ist es nachvollziebarer, dass ein Rasenmäher durch Steine beschädigt wird, als durch einen Becher rosa Zeugs, seine Batterie eher bei einem Blitz aufgeladen wird als bei einem Kaffee, etc.
Wie die Charaktere wechselte das Setting mehrmals im Verlauf der Produktion. Angedacht war ein typisches Casual-Games-Szenario: Zombiepflanzen greifen an, und der elektrische Kerberos wächst über sich hinaus und muss den Angriff abwehren.
Es folgten eine Wildwest-Umgebung, danach eine schnelle, futuristische Technowelt. Bevor ich die finale Story über das Spiel legte war „Ich muss das Ding bis Abgabeschluss fertig haben“ die Devise (LL1). Mit dem Untergrund das gleiche: Je nach Setting brauchte ich etwas passendes, für die finale Story wollte ich den Mensagarten einsetzen. Dies passte jedoch nicht zum Stil, Eitschpii schien zu schweben, und so wich dieser einem schnöden Balkonteppich. Dies führt zum Thema Visuals.
Visuelle Elemente
Während der Arbeit geriet ich an viele Aspekte meines Studiums. Ich fotografierte Eitschpii ausgiebig und collagierte aus den Bildern den fertigen Protagonisten, zeichnete die Story als Vektorgrafik in Illustrator, bearbeitete mit Audition Sounds um sie passend(er) zu machen. Das alles war sehr viel Arbeit, die der Programmierung Zeit stahl (LL2). Was mich schlussendlich rettete war die Verfügbarkeit von Bild und Ton mit der Rechtsbezeichnung: „Free for non-commercial use“. Trotzdem, mit dem finalen Aussehen bin ich nur äusserst knapp zufrieden. Zu konzeptlos wirkt alles, zu langweilig und -schlicht- zu unästhetisch.
Programmierung
Ich kannte die vier involvierten Frameworks schon. Jedes neue Projekt stellt einen jedoch vor neue Herausforderungen: Wie bewege ich zum Beispiel den Roboter möglichst flüssig über das Spielfeld? Dies war mein erstes derartiges Spiel, vorher waren es ein Top-Down-Scroller und ein „Hau den Lukas“ mit Maussteuerung. Eine weitere Besonderheit: Die EaselJS-Suite ist an der HTW (noch) unbekannt. Für spezifischere Fragen hatte ich also keinerlei Unterstützung. Und so grub ich mich stundenlang durch FAQs, APIs, Foren und Chats mit belgischen Freunden. Es kam wie es kommen musste: Einiges läuft nun nicht ganz rund. Zum Beispiel hakt der Motorensound Eitschpiis an einer Stelle immer wieder, und ich vermute dies liegt daran dass der Sound 60 mal pro Sekunde abgefragt wird, und, sollte er fertig gespielt sein, wieder gestartet wird. Irgendwo in dieser Logik muss ein Fehler stecken.
Und jetzt zu einem der grossen Knackpunkte des Spiels: Die Objektorientierte Programmierung. Javascript ermöglicht OOP, und in solchen Projekten ist dessen Einsatz mehr als sinnvoll. So werden alle Teile des Spiels als Objekte definiert und handeln fortan autark. Reloads sind ebenfalls einfach möglich, die Story wird als Objekt geladen, welche nach Abarbeitung das Spielobjekt instanziert, welches weitere Objekte hervorruft usw. Dies ermöglicht zum Beispiel ein Überspringen der Story. Dieses Konzept habe ich nur teilweise erfüllt, zwischen Objekten entstand ein Flickenteppich aus prozeduralem Code, welcher immer unübersichtlicher und komplizierter wurde. Von technischer Seite sehe ich dies als meinen grössten Fehler an, schlussfolgere LL3 und entschuldige mich bei meinem Dozenten für OOP.
Fazit
Dieses Semester war stressig. Es gab einige Projekte bei denen die Leistungs/Ertrags-Balance nicht stimmte, so auch bei «HP - The awakening». Und doch bin ich froh dieses Spiel in Angriff genommen zu haben, es erweiterte in Skandinavien Gelerntes, führte mich durch viele Fertigkeiten des Multimediaproduzenten, und lehrte mich wichtige Lektionen am eigenen Leibe, vom regelmässigen Anfertigen eines Backups bis zu den unten aufgeführten Lessons Learnt. Setzt man diese um, ist auch mehr Zeit für die theoretische Konzeption, von der vorhandenen Theorie des Game- und Interaktiondesigns machte ich leider keinen Gebrauch.
Lessons learnt, Entwicklung von Casual Games an der HTW Chur
LL1: Legen Sie in der Planungsphase genau fest, in welchem Setting welche Charaktere spielen, wie der visuelle und der akustische Stil ist, wie sich das fertige Spiel anfühlt. Das Projekt profitiert auf sämtlichen Gebieten wenn diese Punkte früh fix sind. Besorgen Sie Visual und sonstige benötigte Medien schon in dieser Phase, und finden Sie heraus, ob diese zusammenpassen.
LL2: Arbeiten Sie in Teams. Jemand illustriert unheimlich gerne Comics, jemand anderes erschafft gerne Figuren aus Fotos, oder rennt mit dem Audiorecorder durch die Gegend, etc. Und allesamt brauchen sie Digezzprojekte. Ist LL1 erfüllt, erzielen Sie so schneller konsistentere und grössere Ergebnisse und sind nicht so sehr auf externe Ressourcen angewiesen. Ausserdem ist es die einzige Möglichkeit, aus den kurzen Momenten die Ihnen zur Verfügung stehen befriedigende Ergebnisse zu ziehen. Schliesslich müssen auch noch X andere Projekte aus sonstigen Modulen parallel abgearbeitet werden.
LL3: Auch von programmiertechnischer Seite: Vor dem Startschuss muss alles gefixt sein. Am besten stehen ausführliche UML. Auch wenn Sie das Gefühl haben, Ihnen renne die Zeit sonst davon; solange theoretische Pläne nicht einwandfrei funktionieren, fangen Sie nicht mit der Umsetzung an. Punkt.
Mögliche weitere Schritte
- Umsetzung des Spiels in kompletter OOP
- Hinzufügen von Levels, am einfachsten nach der Umsetzung in OOP
- Dadurch Erweiterung durch neue Gegnertypen, auch Bossgegner etc.
- Implementierung von mobile Steuerung
- Implementierung von sozialen Komponenten, zum Beispiel dem Eintrag in eine Bestenliste oder dem sharen von Resultaten auf Facebook
- Visuelles und auditives Makeover
- Mehrspielermodi
