zweig alpha

Zweig Early Alpha Version

Ich will ein interaktives Hörspiel für Android entwickeln. Hier erzähle ich was ich für die erste spielbare Version umgesetzt habe.

Aufteilung einer Geschichte in Kapitel

Ein Hörspiel besteht aus mehreren Kapiteln. In einem Kapitel steht welches Tondokument abgespielt werden soll und welche Entscheidungsmöglichkeiten es am Schluss gibt. Mein erster Versuch war, diese Daten jeweils am Anfang eines Kapitels aus der Firebase Datenbank zu laden. Das war für die erste Version gut genug. Einen flüssigen Spielfluss gab es da aber nicht weil die Ladezeit zu lange waren. Am Ende eines Kapitels trifft man dann eine Entscheidung. Diese Entscheidung bestimmt welches Kapitel als nächstes kommt. So geht die Geschichte immer voran. 

Wie definiere ich das Ende 

Wenn die Geschichte dann zu ende ist, stürzt die App ab. Hier musste ich erst mal definieren wann das Ende erreicht ist. Und zwar wenn ein Kapitel geladen wird das keine Entscheidungsmöglichkeiten hat. An der Stelle endet das Spiel und der User kann mit dem back button raus zum Inhaltsverzeichnis gehen.

Crashlytics

Bis zu diesem Punkt hatte ich sehr wenig Fehlerbehandlung eingebaut. Ich wollte erst mal den Codepfad fertig schreiben auf dem alles funktioniert. Dann war es aber an der Zeit Firebase Crashlytics einzubauen. Das ist ein Bugtracking Tool. Wenn die App abstürzt, wird das protokolliert und auf der Firebase Seite gespeichert. Somit geht kein Fehler verloren. 

Button fragment

Wie wird jetzt aber am Ende eines Kapitels eine Entscheidung getroffen? Das ist das Haupt Feature meiner App. Hier will ich möglichst unterhaltsame Möglichkeiten finden indem ich alle Sensoren eines Handys verwende. Die erste Art war jedoch ein einfacher Button. Wenn es also 3 Wahlmöglichkeiten gibt, zeige ich 3 Buttons an. Beim klick darauf wird das nächste Kapitel geladen. Das will ich aber so nicht veröffentlichen. Das dient nur dazu um die Bedienung während der Entwicklung zu vereinfachen oder erst einmal zu ermöglichen.

Shake fragment

Die nächst Art der Entscheidungsfindung die ich einbauen wollte war das schütteln. Das erkennen einer Schüttelgeste ist nämlich sehr einfach und schnell umgesetzt. Die Implementierung habe ich mit einer Programmbibliothek eines Drittherstellers gemacht. Es wird einfach nach dem Schütteln eine Methode aufgerufen. Damit kann man nicht zwischen zwei Möglichkeiten auswählen, weil ich ja nur ein Signal bekomme. Also entweder schütteln oder nichts. Aber das könnte man vielleicht zur Auflockerung verwenden. Eine kleine Interaktion bevor die Geschichte weitergeht ist manchmal interessant um den Benutzer wach zu halten.

Swipe fragment

Als nächstes habe ich dann eine weitere grundlegenden Mechanismus eingebaut. Das swipen. Ich erkenne 4 verschiedene swipe Richtungen. Rauf, runter, links, rechts. Bei Konkurrenzprodukten ist das oft schon die komplexeste Interaktionsform. Für mich ist das eher etwas das ich nur verwenden will wenn es wirklich zur Geschichte passt. Zum Beispiel wenn man an einer Kreuzung entscheiden soll in welche Richtung man weiter geht.

Gemockte Daten

Die fertige App soll ja ein Audiospiel werden. Für diese erste Alpha Version hab ich aber komplett auf Ton verzichtet. Den inhalt eines Kapitels habe ich nur als Text dargestellt. Das war nötig um die erste Implementierung der Spiellogik zu machen. Text anzuzeigen geht eben viel schneller als einen Audio Stream abzuspielen. 

Testdaten in der Datenbank

Die Testdaten musste ich in Firebase händisch in die Datenbank eintragen. Das ist sehr mühsam und kann ich nicht empfehlen. Es lohnt sich auf jeden Fall das schreiben in die Firebase Datenbank im Coden zu machen. Vielleicht in einer eigenen Test Activity wo man mehrere Testdatensätze erstellen kann.

World4You Webhosting

1 thought on “Zweig Early Alpha Version

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

code