Idee
Die ursprüngliche Idee zu «Browse Browse Revolution» basierte eigentlich hauptsächlich auf fünf Punkten:
- Es sollte eher IntMed-lastig sein
- Am liebsten ein kleines Spiel oder so
- Es sollte die "übliche" Steuerung von Browsergames auf die Probe stellen, wenn möglich sogar eine Alternative testen.
- Es sollte gut klingen und gut Aussehen
- Das ganze sollte ohne Frameworks umgesetzt sein, so wie auch die Kommunikation JS <---> Browserdaten eher roh ist.
Das ursprüngliche Konzept sah einen Piraten auf der Planke vor, den es durch Veränderung des Browserfensters zu retten gilt. Hier stellten sich jedoch technische Probleme, es kann nämlich die Breite des Browsers verändert werden, jedoch lässt sich mit JavaScript nicht herausfinden, welche Seite bewegt wurde. Ausserdem ist das schnelle Wechseln zwischen Rändern, die in der Hast zu erwischen gar nicht einfach ist, ein Verfehlen welcher jedoch unangenehme Folgen (Verschiebung von Files, Aktivierung von zum Beispiel Bookmarks etc.) hat, äusserst mühsam. Es bot sich deshalb die einfache seitliche Bewegung eines Randes an, das rhythmische herumschieben in Denkpausen brachte uns dann auf die zündende Idee.
Vorbereitung
Dance Dance Revolution ist ein bekanntes Spielhallen-Game das überall auf der Welt täglich gespielt wird. Dieses Spiel basiert auf der Bewegung des Menschen, in dem man, im einem vorgegebenen Takt, mit seinen Füssen auf aufleuchtende vorgegebenen Pfeilen treten muss. Unser Ziel war es nicht, einfach eine Kopie dieses Spiels zu erstellen, sondern die Umsetzung einer unüblicheren Steuerung. Nicht das Spiel im Browser spielen, sondern den Browser zum Spielen nutzen.
Solche Dinge haben wir in Gesprächen festgelegt, die der eigentlichen Umsetzung voraus gingen. Auch haben wir die Rollen klar verteilt, und konnten uns so auf jeweils ein Aufgabengebiet konzentrieren, Termine vereinbarten wir mündlich. Bis auf diese Treffen verliefen die Arbeiten am Projekt autark nach der festgelegten Aufteilung.
Umsetzung
Die Umsetzung im Zweierteam klappte, für Gruppenarbeiten im MMP-Studium äusserst unüblich, vorbildlich. Termine hielten wir ein, waren begeistert bei der Sache und konnten uns offen Feedbacks zu den Arbeiten geben. Die Programmierung verzögerte sich zwar leicht, da aber die Visuals zum Teil recht früh ausgearbeitet waren, wurden sie, eben der Grundidee, zu einer Art Leitsatz für die folgenden Schritte.
Greg (Programmierung)
«Das ich das noch erleben darf!» Am liebsten hätte ich diesen Satz ob der wirklich tollen Teamarbeit laut vom Dach des Medienhauses geschrien. Da dürfen wir aber leider nicht hin. Aber jetzt im Ernst: Ich bin ziemlich zufrieden mit dem Ergebnis. Die im letzten Projekt gewonnene Erkenntnis, auch mal einen Teil der Arbeit jemand anderem zu geben, habe ich direkt umgesetzt, und das hat sich gelohnt. Das Spiel sieht meines Erachtens wirklich super und vor allem stimmig aus, klingt, dank der Tracks eines Kommilitonen und meines Stiefbruders auch gut, und bietet sich für kurzweilige Ablenkung an.
Aber es gibt auch Grund zur Selbstkritik: Den zu Anfang gefassten Entschluss, diesmal ohne Frameworks zu arbeiten, verwarf ich irgendwann und band jQuery ein, und zwar nur wegen der FadeOut-Methode. Diese hätte man auch selbst umsetzen können, was ich aber lange vor mich her schob bis ich mich am Ende nicht mehr darum kümmern konnte. Sehr schade.
Mit der technischen Umsetzung bin ich, bis auf kleinere Ausnahmen, zufrieden. Der Aufbau aus JS-Klassen ist passabel. Die Vermischung von PHP und HTML passierte, als ich nach einer Möglichkeit suchte, die benötigte Datenmenge klein zu halten.
Die modalen Fenster sind rein aus HTML und CSS aufgebaut, was meines Erachtens eine sehr coole Methode ist diese zu Nutzen, im Endeffekt habe ich ja aber trotzdem jQuery verwendet und hätte auch gleich die dort zur Verfügung gestellte Funktion nutzen können.
Auch läuft das Spiel nun einigermassen flüssig (ausser in Chrome), was einiges Tüfteln erforderte, der springende Punkt war eine möglichst ideale Abmischung von Anzahl Balken, gemachten Schritten und Browserabtastrate.
Roman(Design)
Eine reibungslose Projektarbeit für die geliebte Plattform «Digezz». Mit einem sehr witzigen und zeitvertreibendem Spiel endet die Karriere bei Digezz mit diesem letzten Beitrag. Ein sehr gutes Gefühl. Vor allem wenn man es mit einem Spiel beenden kann, dass die Freude am Browser-Fenster wieder so richtig zum Leben erweckt. Aber nicht nur die Freude am Spiel ist gross, sondern auch die Freude über die Zusammenarbeit im Team. Es lief bei uns wie am Schnürchen. Das Spiel ist von A bis Z gut aufgebaut, hat ein klares und erkenntliches Design, die Tracks der beiden Musiker unterstützen das Spielvergnügen und es läuft auf allen Browsern einwandfrei. Trotzdem gab es auch die eine oder andere Hürde die man irgendwie hinter sich lassen musste.
Für das Design des Spiels wollte ich einen einheitlichen Look erstellen. So habe ich die Begriffe Musik, Dance und Balken versucht zu vereinen. Das Background-Design war eine der grössten Herausforderung für mich. Nach diversem Zeichnen von Entwürfen für den Background, entschied ich mich für eine Balken-Wave-Background, welcher nicht zu stark vom spielen ablenken soll. Die Überlegung für einen dynamischen, bewegten Background blitze bei mir auch mal kurz auf. Doch diese Idee verwarf ich gleich wieder, weil sich dann die Datenmenge des Spiels zu stark vergrössern würde. Das Spiel soll spielbar sein und nicht lange Ladezeiten mit sich bringen.
Am meisten gefällt mir am Design das Logo. Die Kombination aus den oben genannten Begriffen habe ich auch hier einfliessen lassen. So sind verschiedenfarbige Balken zu sehen, die die Aussterung(Musikpegel) zeigt. Ein Logo, das dem Spiel sehr wohl gerecht wird und bestimmt auch für Klicks sorgen wird.
Als letztes möchte ich noch kurz auf das GIF bei der Anleitung eingehen. Das GIF wurde im Nachhinein zur Unterstützung des Spiels erstellt, damit der Spieler es schnell und einfach verstehen kann. Grundsätzlich ist das GIF eine sehr coole Sache, da es innert kürzester Zeit was aufzeigen und erklären kann. Für die Erstellung des GIF’s habe ich hier die Variante mittels Bildern vorgezogen. Ebenfalls ist auch hier der Grund die Datenmenge. Das Spiel sieht aus meiner Sichtweise soweit schick aus, spielt sich flüssig und ein netter Zeitvertreib für jedermann.
Fazit
«Browse Browse Revolution» bleibt, was es von Anfang an war: Ein Experiment, ein Versuch. Die finale Antwort auf die grundlegende Frage könnte man etwa so umschreiben: Man kann auch auf einem Bügeleisen kochen, aber halt nur schlecht, denn dafür wurde es nicht konzipiert. Unsere Bügeleisen sind eben Browser, die ausgelegt sind auf das Verarbeiten und Darstellen von Webinhalten. Gleichzeitig sollten sie sich gleichzeitig in ein OS einfügen und die heute übliche Window-Qualitäten aufweisen.
Übrigens: Die historische Entwicklung und sicherheitstechnische Bedeutung des Sandboxing, die bei heutigen Browsern greift, war uns durchaus bewusst, schien aber ein zu weites und zu tiefgreifendes Feld, um sie in diesem Artikel auch noch anzuschneiden.
