• Geocaching
  • Wherigo
  • Was schief gehen kann... 100 Tage lang

Was schief gehen kann...

Wherigo-Caches sind etwas spezielles: Man sucht nicht einfach nur einen Cachebehälter oder läuft wie bei einem Multi-Cache von Station zu Station, sondern hat eine Reihe von Interaktionsmöglichkeiten mit seinem GPS-Gerät (oder Smartphone): Hier wird ein üblicherweise ortsbezogenes Programm (die "Cartridge") ausgeführt, das eine Vielzahl von Optionen ermöglicht, je nachdem, was der Programmierer sich ausgedacht hat. Diese Cacheart ist ein seltenes Exemplar, gehört aber für mich zu den faszinierendsten.

Wherigo-Entwicklung

Wie bei jeder Cache-Art ist die Bandbreite der Qualität auch bei Wherigos enorm.

Typen in Kurzform

Die einfachsten Wherigos sind klassische Stadtführungs- oder andere touristische Rundgänge. Wie bei einem herkömmlichen Multi werden hier verschiedene Stationen in einer definierten Reihenfolge besucht, man erfährt durch Textanzeigen auf dem GPS etwas von dem Ort und muss häufig Fragen beantworten, deren Antwort man vor Ort findet.

Eine Ausbaustufe stellen Geschichten dar: Innerhalb von Wherigo-Cartridges können nicht nur Orte wie bei einem Multi verwendet werden, sondern auch virtuelle Personen und Gegenstände. Der Spieler hat sogar ein virtuelles Inventar, mit dem er seine Fundstücke durch die Gegend schleppen kann. So lassen sich ganz nach der Kreativität der Owner Geschichten mit interessanten Handlungsoptionen in die Cache-Suche einbetten und Rätsel vor Ort gestalten.

Selbst dort, wo eigentlich gar nichts mehr geht, weil alles von einfachen Filmdosen-Mikros verstopft ist und die Abstandsregel keine Caches mehr zu lässt, können mit diesen virtuellen Elementen interessante Ideen und Herausforderungen aufgebaut werden. Aber wie in der ersten Kategorie sind auch diese Geschichten linear, man folgt einer festgelegten Reihenfolge.

Ein Experiment mit unklarem Ausgang

Was nun, wenn diese feste Reihenfolge verlassen wird? wenn wir nicht alles genau festlegen, sondern eine virtuelle Welt auf dem GPS entstehen lassen und der Spieler entscheidet? So wie in klassischen Adventure-Spielen auf dem PC. Die Idee schleppte ich schon einige Zeit mit mir herum, an die Umsetzung traute ich mich nicht wirklich heran, weil ich Bedenken hatte, dass dort etwas so komplexes bei herauskommt, dass die meist rechenschwachen Geräte davor kapitulieren. Denn auch wenn es für den Spieler den Anschein hat, dass er sich frei bewegen kann und freie Entscheidungen trifft, so muss das Programm stets wissen, was da gerade Sache ist.

Ein einfaches Beispiel:

Wir haben zwei Zonen:

A wird als dunkler Raum beschrieben

B ist eine Kammer, mit allerlei Krams

Der Spieler kann wahlweise die Zone A oder B aufsuchen. Um weiterzukommen (zur nächsten Zone C) muss er Zone A durchqueren. Dass heißt, diese Zone C wird erst aktiviert, wenn A betreten und verlassen wurde. Nun wollen wir es nicht so einfach machen: Um die Lage für C herauszufinden, muss der Spieler in Zone A eine Taschenlampe einschalten. Diese muss er sich vorher in Zone B holen.

Die Cartridge muss also wissen, wo sich der Spieler befindet, wo die Taschenlampe ist (in Raum B oder beim Spieler) und ob sie eingeschaltet wurde.

Das einfache Beispiel zeigt, dass viele Parameter zu kontrollieren sind.

Meine Zweifel, ob so etwas mit einer ausreichenden Spieltiefe umsetzbar ist, wurden in dem Moment zerstreut, als ich in Berlin die geniale Cartridge "Parkabenteuer" (http://coord.info/GC2PN9A) von roolku spielte.

Danach machte ich mich daran, meine eigene Story zu schreiben, einen geeigneten Spielort zu suchen und danach für jede Zone und jeden Gegenstand festzulegen, was damit wo in welcher Form passieren darf. Dann ging es an die programmtechnische Umsetzung: Das Rahmengerüst wurde mit den Wherigo-Builder Urwigo erstellt (über das Original von Groundspeak decken wir lieben den Mantel des Schweigens) und ein paar allgemeine Funktionen angereichert, auf die die fertige Cartridge jederzeit zugreifen kann.

Solche Funktionen haben Auslöser-Charakter ("Trigger"). Da der Spieler sich frei bewegen kann, prüfen sie, ob bestimmte Bedingungen an verschiedenen Orten erfüllt sind, bevor sie die nächste Aufgabe freischalten.

Als alles fertig war, war die Urwigo-Projektdatei nach vielen Wochen Planung und Arbeit inzwischen auf über 30.000 Codezeilen angewachsen. Uff.

Nun hieß es testen, testen, testen...

Irgendwann war alles rund, die Cartridge konnte veröffentlicht werden. Sie bekam den etwas selbstironischen Titel "Was schief gehen kann...". Der Titel wurde so gewählt, weil Wherigo nicht die stabilste Softwareplattform ist und weil es in der Geschichte um ein spezielles Cacher-Erlebnis geht, in dem so manches schief geht.

Ein gewisses Risiko war dabei: Die Cartridge ist technisch abspruchsvoll, nicht jedes Gerät wird das alles fehlerfrei schaffen. Wie würde die Resonanz sein?

100 Tage später:

Für eine solche spezielle Cacheart gab es in dieser Zeit 105 Found-Logs, 43 Favoritenpunkte wurden vergeben, was einer stolzen Quote von 52% entspricht. Auf GC-Vote wurde ein Traumwert von 4,38 Punkten (von 5 Punkten) erreicht. Das hatte ich nicht erwartet.

Danke an alle Spieler!

Was schief gehen kann:

Zwischendurch waren natürlich die ganz normalen Probleme zu lösen, die es jenseits der Cartridge so gibt: Eine gemuggelte Dose, ein Bewohner am Final... Man hat es halt nicht leicht. :)

Und wenn doch etwas schief geht:

Die Absturzgefahren bei Wherigos sind legendär. Unterstellt man saubere Programmierung, so kann eigentlich in der Theorie nichts schief gehen. Ein Faktor beeinflusst das Ganze aber erheblich: Ein solches Spiel ist Zonenbasiert. Wenn der Empfang schlecht ist oder wenn der Spieler nicht weit genug in die Zone hineingeht, sich nur am Rand aufhält und die Genauigkeit zu pendeln anfängt, verliert das System den Überblick. War der Spieler einen Augenblick lang noch in einer Zone und hat einen Befehl ausgeführt, ist er im nächsten Moment, ohne sich bewegt zu haben, durch Empfangsstörungen draußen. Dann wird der Empfang besser, der Spieler ist wieder drin. Die Cartridge versucht nun, den Befehl des Spielers auszuführen, gleichzeitig aber auf die Ereignisse "Spieler hat Zone verlassen" und "Spieler hat Zone betreten" zu reagieren. Das muss schief gehen. Es sei denn, der Programmierer hat sehr umfangreiche Fehlerbehandlungsroutinen für so einen Fall aufgebaut. Wherigo-Entwicklung ist trotz bunter Editoren echte Programmierarbeit und nicht einfach so umgesetzt. Meine Cartridge läuft zwar auf allen gängigen Geräten fehlerfrei durch, es gibt einige Fehlerbehandlung, aber alle Sachverhalte abfangen und darauf reagieren ist kaum möglich. So kommt ein Spieler mitunter absturzfrei zu Ziel, ein anderer jedoch nicht. Hier kann ich nur allen empfehlen, die Tipps im Listing genau zu beachten, dann ist die Wahrscheinlichkeit, dass nur das schief geht, was auch schief gehen soll, weil es die Story so will, sehr hoch.

Und wie geht es weiter?

Bei einer solchen 100-Tage-Bilanz mit so tollem Feedback in den Punkten, Favoriten und vor allem den Logeinträgen stellt sich schon die Frage: War es das oder kann man da noch eins draufsetzen und einen anderen Wherigo entwickeln? Ideen sind genug da, aber das ist dann doch eher etwas für kühle Wintermonate. Mal schauen, was die Zeit so bringt...

Kommentareingabe einblenden