Programmierbeispiele/Codesnipsel

Aus Das Wherigo-Handbuch
Wechseln zu: Navigation, Suche

Vorwort : Auf dieser Seite werden einige einfache grundlegende Beispiele zu den verschiedensten Kategorien gezeigt. Die Beispiele werden bewusst schlicht gehalten, so werden z.b Bilder und weiterreichende Funktionen nur verwendet, wenn sie für den angesprochenen Fall unbedingt notwendig sind. Die hier bereitgestellten Sourcen können und sollen zum Selbststudium anregen. Sie unterliegen keinem Copyright und dürfen für private Zwecke frei verwendet werden. Publizierungen auf eigenen Seiten oder Seiten Dritter ohne Nennung des Links auf diese Seite sind nicht oder nur nach Absprache gestattet. Modifizierungen und Upload der hier verfügbaren Sourcen sollten wenn möglich in Absprache mit den Autoren dieser Seite erfolgen. Fragen, Verbesserungsvorschläge, Ideen für die Aufnahme weiterer hilfreicher Beispiele, Fehlerhinweise und ähnliches platziert ihr bitte im Geoclub Forum

Inhaltsverzeichnis

Zonen

Zonen sind die virtuellen Stationen eines Wherigos. Sie können aktiv, nicht aktiv, sichtbar oder unsichtbar sein. Die folgenden Beispiele zeigen, wie es funktioniert.
Zonen (mehrfach) betreten
  • Aufgabe : Beim Betreten einer Zone soll eine Meldung erscheinen. Wird die Zone verlassen und der Spieler kommt nochmals zurück, so soll eine andere Meldung ausgegeben werden. Es gilt also zu unterscheiden, betritt der Spieler zum ersten mal die Zone oder war er bereits da.
  • Realisierung : Anlegen der Zonen, Anlegen eines Tasks, Belegung der Events mit Aktionen (Taskstatus umschalten, Meldungstexte ausgeben)
  • Anmerkung : Hier wird der Status des Task für die Unterscheidung abgefragt. Alternativ könnte man eine Variable vom Typ Boolean (z.b ZoneBetreten) deklarieren und diese auf "true" setzen, wenn der Spieler die Zone betreten hat. Das vorliegende Beispiel hat den Vorteil, daß man dem Spieler sowohl anzeigen kann, was er als nächstes zu tun hat "Gehe zur Wiese" als auch den Status dieses Tasks für die Fallunterscheidung benutzen kann.
Dieses Beispielscript herunterladen

Zonen sichtbar/unsichtbar/betreten/verlassen
  • Aufgabe : Beim Betreten einer Zone soll eine weitere sichtbar gemacht werden. Wird diese Zone erreicht, schalten wir eine weitere "innere Zone" aktiv aber nicht sichtbar. In der Praxis könnte man dies z.b anwenden, einen Spieler in eine Zone zu leiten um ihn dort einen versteckten virtuellen Gegenstand suchen zu lassen. Die nächsten Schritte werden jeweils mit einem Task angezeigt. Erfüllte Aufgaben werden auf "complete" gesetzt.
  • Realisierung : Anlegen der Zonen, Anlegen der Tasks, Belegung der Events mit Aktionen (Zone sichtbar machen, Taskstatus umschalten, Meldungstexte ausgeben)
  • Anmerkung : Wird die letzte Zone verlassen, ohne daß man die innere betreten hat (daß evtl. dort versteckte Item nicht gefunden hat), so ist der letzte Task nicht komplett. Dieser Zustand wird dann dazu benutzt eine Message auszugeben, daß der Spieler hier noch etwas zu erledigen hat.
Dieses Beispielscript herunterladen

Zonen als Kreis realisieren
  • Aufgabe : Um eine Zone zu realisieren soll lediglich der Mittelpunkt eingegeben werden und anschließend ein Radius um die Zone gezogen werden.
  • Realisierung : Koordinaten eingeben (auch im N50 39.008 E7 26.793 Format), Feld "In proximity" auf gewünschten Wert setzten (z.B 10 Meter), statt "On enter" "On proximity" verwenden.
  • Anmerkung : Das Verfahren hat den Vorteil, dass bei Abstand und Richtungspfeil garantiert immer der Zonenmittelpunkt anvisiert wird und empfiehlt sich damit insbesondere für Zonen in denen der Spieler physisch vorhandene Dinge suchen soll sowie für das Final. Das Verfahren hat aber auch den Nachteil, dass man das "On Exit" - Event der Zone nicht mehr verwenden darf, da der Spieler die nur aus einem Punkt bestehende Zone ja nie betritt und demzufolge auch nie verläßt. Achtung - Items mit Kommandos, die in Punktzonen liegen (on proximity sichtbar) scheinen auf dem iPhone nicht zu gehen Seit der Wherigoversion 1.3.7 ist dies nun auch möglich
Dieses Beispielscript herunterladen

Charakter

Charakter sind ähnlich den Items weitere Bestandteile von vielen Wherigos. Dialoge sollten sich allerdings nicht zu sehr verzweigen, da die Behandlungen der dann verschiedenartigen Situationen schnell sehr komplex werden. Wechseldialoge können mit Bildern (wer agiert gerade ?) lebendig gemacht werden. Charaktere und Items werden oft miteinander kombiniert (an Figur geben, von Figur nehmen).
Statischer Dialog mit einem Charakter
Der Verlauf des Dialogs ist fest vorgegeben und nicht lenkbar.
  • Aufgabe : Wir betreten eine Zone und treffen dort auf einen Bauern. In einem Dialog soll er uns den weiteren Weg sagen. Sprechen wir ihn ein 2. mal an, soll diese behandelt werden. Je nachdem wer gerade spricht, wird die passende Bebilderung angezeigt.
  • Realisierung : 1 Zone, 1 Charakter, 1 Variable die gesetzt wird wenn der Dialog erfolgt ist. Fallunterscheidung ob bereits Dialog geführt wurde. Wechsel der Bilder in den einzelnen Messageboxen.
  • Anmerkung : Man setzt diesen Ablauf hauptsächlich dann ein, wenn der Charakter lediglich Informationen geben soll, damit der Spieler weiterkommt. Weitere Kommentare siehe auch im Script.
Dieses Beispielscript herunterladen

Statischer Dialog mit einem imaginären Charakter (Phantomfigur)
Der Verlauf des Dialogs ist auch hier fest vorgegeben und nicht lenkbar. Dies ist die einfachste Art einen Dialog (ohne echten Charakter) aufzubauen.
  • Aufgabe : Wie oben, jedoch existiert der Charakter nicht wirklich. Durch Wechsel der Bilder in den Messages entsteht beim Spieler jedoch der Eindruck es handelt sich um einen anwesenden Charakter.
  • Realisierung : Wie oben, jedoch ohne Charakter, lediglich Messagesboxen (Dialog) mit wechselnden Bildern.
  • Anmerkung : Wichtig ist, daß in der letzten Messagebox eine Ankündigung erfolgt, daß der Charakter wieder verschwindet. Der Spieler soll sich beim Beenden des Dialogs nicht wundern, daß er in der Zone plötzlich niemanden mehr sieht. Ein zweites Ansprechen ist somit nicht möglich. Wird die Zone verlassen und erneut betreten, sollte jedoch eine Behandlung erfolgen (Message)
Dieses Beispielscript herunterladen

Dynamischer Dialog mit einem Charakter
Diesen Ablauf wird man häufig antreffen : Ein Dialog, bei dem der Spieler dem Charakter etwas geben muss, damit er ihm weiterhilft.
  • Aufgabe : Der Spieler kommt wieder zur Wiese und spricht den Bauern an. Dieser will aber erst etwas zu trinken, bevor er weiterhilft.
  • Realisierung : Wie oben, jedoch zusätzlich mit 1 Item und 2 Kommandos. Fallunterscheidung für alle Fälle die auftreten können.
  • Anmerkung : An dem Beispiel kann man schon ansatzweise erkennen, wie Fallunterscheidungen sehr schnell komplex werden können, da in einem guten Wherigo ALLE Aktionen behandelt werden sollten. Weitere Kommentare siehe auch im Script.
Dieses Beispielscript herunterladen

Items

Items sind meist mit die wichtigsten Objekte eines Wherigos. Der Anwendungsbereich ist die Interaktion mit dem Spieler und oft die Kombination der Items untereinander. Die typischen Kommandos sind etwa Nimm/Gib/Verwende/Benutze usw. Sowohl die Items selber als auch ihre Kommandos können je nach Situation sichtbar oder unsichtbar gemacht werden. Einige typische Fälle für den Einsatz werden hier behandelt.
Items nehmen und geben (Variante 1 mit Objektverknüpfung)
  • Aufgabe : Beim Betreten der 1. Zone soll der Spieler eine Axt aufnehmen, zur 2. Zone gehen und sie einem Bauern geben. Nur er darf die Axt erhalten.
  • Realisierung : Axt und Bauer in den Zonen platzieren, Kommandos anlegen und mit Zielobjekt verknüpfen (Geben > Bauer), Kommandos passend zur Situation aktivieren/deaktivieren. Bewegen des Items a) zum Spieler b) vom Spieler zum Bauern. Optional : Tasks anlegen und complete setzen, wenn Aufgabe erfüllt.
  • Anmerkung : Die Beschreibung des Charakters "Bauer" wird geändert, wenn er die Axt hat. Wird versucht das Item jemand anderem zu geben (in diesem Beispiel kann das nicht vorkommen), erscheint eine Fehlermeldung.
Dieses Beispielscript herunterladen

Items nehmen und geben (Variante 2 ohne Objektverknüpfung)
  • Aufgabe : Wie bei Variante 1 mit dem Unterschied, daß wir das Kommando "Geben" nicht mit dem Bauern verknüpfen. Vorteil : Klares Handling möglich, Nachteil : Etwas aufwendiger
  • Realsierung : Wie bei Variante 1, jedoch mit Abfrage ob Spieler und Bauer sich in der gleichen Zone befinden. Nur dann wird das Item zum Bauern verschoben.
  • Anmerkung : Wie bei Variante 1
Dieses Beispielscript herunterladen

Mehrfachitems (Beispiel Sixpack / Flasche)
  • Aufgabe : Ein Spieler kann in einem Supermarkt Sixpacks kaufen und einzelne Flaschen einem Bauern geben - nach 6 Flaschen ist der Sixpack alle und er kann erneut kaufen
  • Realisierung : jedes der Items (Flaschenregal im Supermarkt, Sixpack, Flasche) erhält einen Zähler - abhängig vom Zählerstand wird dann auch Sichtbar/Unsichtbar gesetzt bzw. ist das Kaufen eines Sixpacks möglich. Geben der Flasche an den Bauern ist mit Objektverknüpfung gemacht - um das zu testen kann der Bauer per Kommando auch mal für ne Minute verschwinden und kommt dann wieder...
  • Anmerkung : ausser ein paar LUA-Ausdrücke direkt als benutzerdefinierter Code ist nix aussergewöhnliches verwendet worden..Urwigo verarbeitet benutzerdefinierte Ausdrücke manchmal fehlerhaft - es werden manchmal Fehler im Code gemeldet, obwohl keine da sind - Abhilfe wenn das passiert: komplette Zeile als benutzerdefinierter Code beschreiben anstatt über Festlegen benutzerdefinierte Ausdrücke zu verwenden.
Dieses Beispielscript kann hier heruntergeladen werden: Datei:Sixpack.zip
Dies ist noch ein zweites Beispielscript, welches das "Sixpack-Problem" ebenfalls löst: Datei:Bier.zip

Komplexe Cartridge mit der Möglichkeit, Items in andere Containeritems zu verpacken
  • Aufgabe: Eine Cartridge verwendet sehr viele Items - diese widerum können auch in anderen Items verpackt werden - ein Hut kann in den Koffer gepackt werden, ein Koffer ins Regal gelegt werden, das Regal in die Garage gestellt werden. Natürlich müssen alle Gegenstände wieder rausgeholt werden können und die Behandlung von nicht sichtbaren Items muss geregelt werden
  • Realisierung: Die Container-Items Koffer, Regal, Garage enthalten je einen Menüpunkt um Gegenstände einzupacken, reinzulegen, reinzustellen (Namensunterscheidung, weil diese Menüpunkte automatisch bei allen verbundenen Objekten auftauchen). Diese Menüpunkte können nur auf bestimmte Objekte angewendet werden - bei Auswahl wird der Item einfach in den Container-Item geschoben. Weiterhin erhält jedes dieser Container-Items einen Menüpunkt zum darin befindliche Objekte wieder rauszuholen. Mit einer LUA-Funktion wird dynamisch ermittelt, welche sichtbaren Items in diesem Container-Item sind, ein Auswahlmenü aufgebaut und man kann den ausgewählten Gegenstand (oder alle Gegenstände) wieder rausholen. Ein Zauberstab wird als Testhilfsmittel noch gemacht um Items sichtbar/unsichtbar zu schalten
Dieses Beispielscript kann hier heruntergeladen werden: Datei:Koffer.zip

Selber programmierte Version einer Objektverknüpfung (Urwigo / LUA)
  • Aufgabe: Die Verknüpfung von Gegenständen / Character (z.B. Apfel -- geben -- Bettler) über das Kommando geben hat einen Effekt, der oft nicht gewollt ist. Wenn der Gegenstand Apfel den Befehl geben enthält und die Auswahl der Objekte eingeschränkt ist (in diesem Fall Bettler u. ggf. weitere Personen), dann wird im Player der Befehl "geben" auch rückwärts angezeigt - d.h. der Bettler bekommt in diesem Fall automatisch den Befehl "geben", obwohl dieser nur für den Apfel programmiert ist. Dieses Verhalten soll durch eine eigene Implementierung geändert werden
    • Bei der Initialisierung wird an das Objekt (im Beispiel Koffer) eine table withlist mit den zugelassenen Verknüpfungen angehängt (Cartridge:OnStart)
    • Der Koffer bekommt ein Kommando einpacken das nicht auf bestimmte Items/Charactere eingeschränkt ist
    • es gibt eine Multiple-Choice-Eingabe zur Auswahl der einzupackenden Items, die beim Aufruf des Kommandos Einpacken/Koffer dynamisch ermittelt werden (Lua: get_visible_objects)
    • Die zulässigen Objekte müssen
      • sichtbar sein
      • im Inventar liegen oder in den Zonen in denen der Spieler ist
      • in der withlist eingetragen sein
      • Nach der Eingabe wird das einzupackende Item/Character über den Namen gesucht (muss eindeutig sein !!! Rechtschreibung wichtig !!!) und wenn gefunden über Move in den Koffer gepackt (LUA: move_named_object_to)
  • Einbindung in eure Cartridges
    • relevanten LUA-Code in eure Cartridge kopieren (User functions)
    • Item/Character mit eigenem Namen versehen statt automatischer Kennung
    • Initialisierung (withlist) nicht vergessen
    • eigene Multiple-Choice-Auswahl bzw. Kommando mit Aufruf der LUA-Funktionen
Hier die Version - fuer das Item Koffer wurde die Objektverknüpfung dabei selber programmiert in LUA (koffer2, alte Version koffer liegt auch bei): Datei:Wherigo koffer.zip

Dynamische Items
Ein Item kann seinen Zustand und damit auch seine Funktion verändern, je nachdem welches Kommando ausgelöst wurde. Optisch schön ist es dann, Beschreibungen oder Bilder des Items dem jeweiligen Zustand anzupassen.
  • Aufgabe : Wir haben in unserem Inventar eine "2 in 1" Taschenlampe, die 3 Zustände einnehmen kann : Licht-UV Licht-Aus. Je nach Schalterstellung soll sich das Bild des Items verändern, so daß wir immer wissen, welchen Zustand die Lampe gerade hat.
  • Realisierung : Anlegen des Items mit 3 Kommandos, je nach Schalterstellung : die betreffenden Variablen setzen, Itembild wechseln, das jeweils nicht passende Kommando unsichtbar machen.
  • Anmerkung : In einem Wherigo kann man die Variablen auswerten. Der Spieler kann z.b ein Pergament mit Geheimschrift nur lesen, wenn sich die Lampe in der Stellung "UV-Licht" befindet.
Dieses Beispielscript herunterladen

Kombination zweier Items
Eine "lebendige" Handlung ergibt sich, wenn 2 Items zu einem neuen kombiniert werden. Die Vorgehensweise ist dabei immer die gleiche. Die ursprünglichen Items erhalten Kommandos mit denen die Items untereinander kombiniert werden können. Wird dann eine passende Handlung ausgelöst, werden die Items gelöscht oder deren Kommandos verändert und ein neues Items wird sichtbar.
  • Aufgabe : In 2 aktive Zonen befinden sich die Items "Leerer Krug" und "Brunnen". Nur wenn der Spieler den Krug genommen hat, kann er am Brunnen auch Wasser einfüllen. Nach dieser Aktion hat der Spieler einen gefüllten Krug.
  • Realisierung : 3 Items anlegen, davon das "Zielitem" unsichtbar. Da die Aktion von beiden Items aus erfolgen kann (Wasser schöpfen, Krug füllen), setzen wir hier eine Funktion ein, die von beiden Kommandoevents aus aufgerufen wird und zum gleichen Ergebnis führt : Leeren Krug löschen, gefüllten Krug ins Inventar.
  • Anmerkung : Das Beispiel verzichtet der Übersichtlichkeit wegen auf Tasks und Zonen Enter/Exit Events. Die Fehlerbehandlung beschränkt sich auf das entscheidende : Krug im Inventar ? Spieler befindet sich beim Brunnen ?
Dieses Beispielscript herunterladen

Item im Item
Soll sich ein Item in einem anderen befinden, so sind beide in einer gemeinsame Zone zu platzieren. Wenn Item B in A liegt, muss anfangs B unsichtbar und nur beim Öffnen von A sichtbar werden. In der Folge wird B wieder unsichtbar wenn A geschlossen wird.
  • Aufgabe : Der Spieler soll in einer Werkstatt eine Taschenlampe suchen. Diese befindet sich in einer Schublade.
  • Realisierung : Beide Items in einer Zone, die Schublade bekommt 2 Kommandos "Öffnen" und "Schließen", bei der Lampe reicht "Nehmen". Behandlung aller möglichen Fälle durch Abfrage der Taskzustände. Sichtbar/Unsichtbarmachen der Lampe, je nach "Status" der Schublade.
  • Anmerkung : In der Praxis wird die Situtation "Schublade wieder geschlossen, Lampe noch nicht genommen" kaum vorkommen. Für eine bis ins Detail ausgearbeitete Cartridge sollte aber auch dieser Fall behandelt werden. Hier werden die Qualitätsunterschiede von Wherigos deutlich.
  • Anmerkung für Fortgeschrittene: Wenn man das extrem macht, dann wird das unübersichtlich - wie man sehr komplexe Situationen meistern kann ist im Beispiel Container-Items ersichtlich - hier werden die Items tatsächlich auch in die Container-Items verschoben.
Dieses Beispielscript herunterladen

Tasks

Tasks werden in der Praxis hauptsächlich eingesetzt, um dem Spieler seine nächste und auch bereits erledigte Aufgaben anzuzeigen. Letzteres geschieht durch Statusänderung des Tasks auf "Complete".
  • Aufgabe : Der Spieler soll 3 Aufgaben lösen. Nach jeder richtigen Antwort, wird der Task dieser Aufgabe auf complete gesetzt und die nächste Aufgabe und damit der nächste Task freigeschaltet. Im Taskmenü sieht man ob und welcher Task noch offen ist und welcher schon erfüllt wurde.
  • Realisierung : 3 Items die mit Kommandos belegt sind und jeweils 1 Input aufrufen. Auswertung der Antworten pro Input. Wenn richtig, Aktivieren des nächsten Tasks und der nächsten Aufgabe. Löschen der aktuell richtig beantworteten Frage. Unterschiedliche Meldungstexte je nach Antwort.
  • Anmerkung : Der Task Status kann zusätzlich wie eine Boolean Variable behandelt und abgefragt werden (wenn Task_1 complete dann ...). Selten verwendet ist der Zustand correct/incorrect. In Verbindung mit complete/incomplete wäre eine Verwendung z.b bei Teilerfüllung einer Aufgabe denkbar, siehe folgende Beispiele.
Dieses Beispielscript herunterladen

Taskstatus auswerten durch Teiltasks
Den Status eines Tasks (incomplete/complete) kann man auswerten, um darauf folgende Aktionen zu steuern bzw. auszulösen.
  • Aufgabe : Der Spieler kommt zu einem Taucherdepot, in dem er ALLE Gegenstände mitnehmen muss, damit die nächste Teilaufgabe erscheint.
  • Realisierung : Anlegen der Tasks und nach der "Nehmen" Aktion jedes Items auf complete setzen. Anlegen einer Funktion mit UND Verknüpfung die von jedem Item aus aufgerufen wird.
  • Bemerkung : Zu viele einzelne Tasks ist für den Spieler schnell unübersichtlich.Stattdessen empfiehlt sich die folgende Variante mit Variablen.
Dieses Beispielscript herunterladen

Taskstatus auswerten durch Variablen
  • Aufgabe : Wie Beispiel 1
  • Realisierung : Wie Beispiel 1, nur anstatt Teiltasks werden (Boolean) Variablen verwendet und ausgewertet.
  • Bemerkung : Wie beschrieben ist diese Variante oft die übersichtlichere. Statt "Nimm A", "Nimm B", "Nimm C" ... wird nur 1 "großer" Task gesetzt, z.b "Untersuche Haus".
Dieses Beispielscript herunterladen

Variablen

Variablen finden überall dort Einsatz, wo Ergebnisse für eine spätere Nutzung gespeichert werden sollen. Die Anwendungsmöglichkeiten sind sehr vielfältig, allerdings kann es auch schnell unübersichtlich werden. Wichtig ist deshalb ein einigermassen sparsamer Gebrauch und treffende Bezeichnungen der Variablen um sich später noch im Code zurechtzufinden.
Z.B. kann man mit Variablen etwas zählen (z.B. die Anzahl der erledigten Aufgaben, die Anzahl der genommenen Items etc.) und diese dann in IF-Bedingungen wieder auswerten. Mit String-Variablen kann man Texte zusammenbauen (Concatenate / Verketten) - z.B. ist ein Spielstand in Variablen gespeichert und man Verkettet eine Zeichenkette mit dem Spielstand um ihn dann anzuzeigen.
Variablen können direkt in Meldungen/Dialogen verwendet werden oder auch in IF-Bedingungen abgefragt werden.
Variablen in Urwigo werden in die Typen
  • Boolean (Wahr oder Falsch bzw. True oder False)
  • Zahlen (Gleitpunkt oder ganzzahlig)
  • Strings/Zeichenketten unterschieden


Alle Wherigo-Objekte werden aus diesen einfachen Datentypen aufgebaut. Wenn in Urwigo z.B. bei einem Objekt (z.B. eine Task/Aufgabe) eine Checkbox zum Ankreuzen da ist (z.B. Feld Erledigt/Completed), dann wird das auch in einer Variable vom Typ Boolean abgelegt - diese Variable gehört dann natürlich auch zu der Task und wird nicht separat abgespeichert. Man kann alle Attribute der Urwigo-Objekte z.B. Tasks direkt in IF-Bedingungen verwenden, Variablen zuordnen oder die Objekte auch auf einen bestimmten Wert oder einen Variableninhalt setzen. Aufpassen muss man, dass die Variablen immer denselben Typ haben...man kann die Typen auch ineinander umwandeln..für Zahlen in Strings geht das automatisch.
Variablen in Urwigo werden im aktuellen Zustand beim Speichern / Beenden der Cartridge gespeichert und stehen genau in diesem Zustand nach dem Laden wieder zur Verfügung.

Inputs

Inputs finden überall dort Einsatz, wo der Spieler entweder etwas beantworten oder sich für etwas entscheiden muss. Je nach Situation werden unterschiedliche Typen verwendet. Es ist generell sinnvoll die Eingabe eines Inputs in eine Variable zu speichern. Nur wenn man den Eingabewert später nicht mehr benötigt, kann die Variable gespart und stattdessen direkt "Answer" verwendet werden. Das folgende Beispiel zeigt die verschiedenen Inputs, die Auswertung und das Fehlerhandling.
Die verschiedenen Input Typen
  • Aufgabe : Verschiedenen Inputtypen sollen gezeigt und die Antworten ausgewertet werden. Bei falschen Eingaben wird eine Fehlermeldung ausgegeben.
  • Realisierung : Anlegen der Inputs inkl. Variablen, denen die Antworten zugewiesen werden. Anlegen eines Items und Zuweisung der Inputs als Kommandos dieses Items. Auswertung der Antworten inkl. Errorhandling (falsche/ungültige Eingabe)
  • Anmerkung : Die Inputs sind der Übersichtlichkeit halber als Kommandos eines Items angelegt. In der Praxis würde man passenderweise einen Input in den Dialog mit einem Charakter einbauen, z.b frägt ein Wärter nach einem Passwort. Die "Inputschleife" ist lediglich eine Variante der Texteingabe. Ich vermeide sie, da sie sich nicht abbrechen lässt, der Vollständigkeit halber sei sie aber hier auch aufgeführt. Der "Message" Input ist eine Variante des Multiple Choice mit 2 Auswahlmöglichkeiten.
Dieses Beispielscript herunterladen

Inputverkettung ohne Abbruchmöglichkeit
Reiht man mehrere Inputs nahtlos aneinander ohne jedesmal wieder neu von einem Menü aus auf die Eingabe zu verzweigen, hat man eine Inputverkettung. An QTA Stages, Aufgaben an Infotafeln o.ä kann man sie passend einsetzen.
  • Aufgabe : Hintereinander sollen 5 unterschiedliche Fragen beantwortet werden. Im Fehlerfall muss die Eingabe wiederholt werden, im Erfolgsfall wird die nächste Frage gestellt. Add On Feature : Am Ende wird angezeigt, wieviel Versuche man benötigt hat und welcher "Erfolgsquote" dies entspricht.
  • Realisierung : 1 Item "Quiz" mit 5 Kommandos (Fragen) im Inventar des Spielers, 5 mit den Kommandos verlinkte Inputs mit Behandlung für richtig/falsch. Einen Zähler zum inkementieren (Aufaddieren der Anzahl der Antworten)
  • Anmerkung : Bei dieser Variante kann die Inputverkettung nicht verlassen werden ! Alternativ kann man bei Multiple Choice eine Abbruchmöglichkeit einbauen. Bei Zahlen- und Text Inputs kann man Fehleingaben behandeln, z.b bei keiner Eingabe (leer) zurück ins Hauptmenü verzweigen. Für das Speichern der Antwort wird hier keine Variable verwendet, sondern direkt der Urwigo Baustein "Answer".
Dieses Beispielscript herunterladen

Inputverkettung mit Abbruchmöglichkeit
Spezielle Eingaben können explizit behandelt und als Abbruch ausgewertet werden. Bei Nummern- und Text Inputs sind dies vorzugsweise Leereingaben, bei Multiple Choice ein extra Button "ABBRUCH".
  • Aufgabe : Wie Beispiel 1, jedoch mit Abbruchmöglichkeit.
  • Realisierung : wie Beispiel 1, jedoch mit zusätzlicher Behandlung bei Leereingabe oder Klick auf den "ABBRUCH" Button.
  • Anmerkung : Ein Abbruch beendet die komplette Eingabekette und verzweigt dann ins Hauptmenü. Eine Fortsetzung beim abgebrochenen Input ist nicht möglich. Vorher beantwortete Fragen werden nochmals aufgerufen.
Dieses Beispielscript herunterladen

Inputhandling aus der Praxis
Ein Beispiel aus der Praxis zeigt das Handling eines Inputs mit den bekannten Auswertungen, zusätzlich läuft jedoch noch ein Timer, der dem Spieler nur eine bestimmte Zeit zum antworten lässt.
  • Aufgabe : Eine Frage soll beantwortet werden, dabei sollen alle Antwortmöglichkeiten behandelt werden.
  • Realisierung : Anlegen einer Frage als Item und Verknüpfung dessen Kommandos mit einem Input. Auswertung der Antwortmöglichkeiten Richtig, Falsch, Leereingabe oder Zurück, Abbruch und Ablauf der Antwortzeit. Weitere Erklärungen stehen auch als Comments im Urwigo Quelltext.
  • Anmerkung : In der Praxis wird der Input auch oft durch Eintritt in eine Zone getriggert bzw. als Frage am Ende eines Dialogs. Bei Abbruch (auch versehentlich) ist die Frage dann verschwunden, da das ZoneEnter Event nicht mehr existent ist. Hinaus und hinein gehen in die Zone, um das Event erneut auszulösen, ist eine schlechte Lösung. Hier kommt das Item ins Spiel. Es kann an einem Dialogende einfach durch "Show Object Details" aufgerufen werden. Im Falle eines Abbruchs liegt es im Inventar des Spielers oder in der Zone und die Frage kann erneut aufgerufen werden.
Dieses Beispielscript herunterladen

Timer

Timer werden dort eingesetzt, wo zeitabhängige Aktionen stattfinden, z.B "Laufe in 30 Sekunden von A nach B". Die Verwendung des Typs (Intervall oder Countdown) ist wohl Geschmacksache, beide haben Vor- und Nachteile, lassen sich aber gleichermaßen (wie hier über Zählerkonstrukte) universell einsetzen.
Timer vom Typ Countdown
  • Aufgabe Der Spieler soll in die Startzone gehen, dort einen Timer auslösen und innerhalb 30 Sekunden die Zielzone erreichen. Während seines "Laufs" soll die verstrichene- und die Restzeit als Item angezeigt werden.
  • Realisierung : Zonen mit den Enter Events definieren (Start/Stop Timer), Ziel erst nach Bestätigung freigeben. Countdowntimer (1 Sekunde) einrichten, nach jedem Timerablauf Zähler hochlaufen lassen und vergleichen mit der vorgegebenen Zeit. Itemname und -Beschreibung über Concatenates solange aktualisieren, bis das Ziel erreicht oder der Timer abgelaufen ist, in beiden Fällen Meldungen ausgeben.
  • Anmerkung : Die Anzeige der Restzeit auf der Item Schaltfläche ist geräteabhängig. So funktioniert die Aktualsierung beim Oregon zwar im Itemmenü und im Item (Beschreibung) selber, nicht aber auf der Schaltfläche im Hauptmenü.
Dieses Beispielscript herunterladen

Timer vom Typ Intervall
  • Aufgabe Der Spieler soll in eine Zone gehen, dort wird er alle 5 Sekunden von Mücken gestochen ;-) Ein zusätzlicher Zähler hält die Anzahl der Stiche fest. Es sollen dabei Meldungen angezeigt werden.
  • Realisierung : 5 Sekunden Intervall Timer anlegen, nach Ablauf Meldung ausgeben. Beim Betreten der Zone wird als onEnter Event der Start des Timers ausgelöst, beim Verlassen wird er gestoppt. Eine Variable wird nach jedem Intevallablauf (5 Sekunden) hochgezählt und eine Meldung ausgegeben.
Dieses Beispielscript herunterladen
  • Anmerkung : Dieser Typ Timer (Intervall) startet, im Gegensatz zum Countdown, automatisch immer wieder neu. In komplexen Wherigos muss unbedingt darauf geachtet werden, ihn durch ein Event (z.b Zonen Enter oder Exit) zu stoppen. Ein "irgendwo" versehentlich noch laufender Timer kann die Fehlersuche zum Geduldspiel werden lassen.
Zuverlässig können Intervalltimer (innerhalb des Timerzyklus') nur im on Start Event beendet werden. Ein Timerstop im Elapse Event ist auf den meisten Playern wirkungslos.
Diese Variante (Timerstop im on Start Event) herunterladen

Media (Bilder, Töne, Sounds)

Geräteunabhängige Sounds
Will man Sounds und Töne in einem Wherigo verwenden, weiß dabei aber nicht mit welchem Gerät ein Wherigo gespielt wird, müssen beide in Frage kommenden Soundtypen (MP3/WAV/OGG und FDL) im Wherigo implementiert werden. Dies kann durch 2 unterschiedliche Methoden erfolgen. Zum einen durch das Abspielen der 2 Soundtypen hintereinander (sequentiell), wobei der Player sich gewissermaßen das passende "aussucht". Zum anderen durch einee Fallunterscheidung aufgrund der Garmin Kennung.
Dieses Beispielscript herunterladen

Töne auf Garmingeräten
iPhone und Co spielen in der Regel Sounddateien von den gängigen Soundtypen WAV, MP3 und OGG problemlos ab. Auf Garmin Geräten muss man sich mit sehr viel (im wahrsten Sinne des Wortes) eintönigeren "Sounds" zufrieden geben. Im folgenden Urwigo Script sind verschiedene sogenannte FDL Soundfiles als Items implementiert. Zur Zuordnung : Die Itemnummer entspricht der Nummer des FDL Files. Man kann sie in seinen eigenen Wherigos zur Signalgebung benutzen, z.b Zone betreten, Antwort richtig/falsch usw. Das Abspielen DIESES Soundtyps funktioniert natürlich auch nur auf Garmingeräten.
Dieses Beispielscript herunterladen

Environment (Spielername, Completion Code, Plattform ...)

Completion Code als Item erzeugen (Variante 1)
  • Aufgabe : Es soll eine Completioncode erzeugt werden. Diesen wollen wir als Item in das Inventar des Spielers legen. Dort kann er den Code dann abrufen.
  • Realisierung : Cartridge auf durchgespielt setzen, Infomessage durch String/Variablen Verkettung bilden, unsichtbares Item sichtbar machen und zum Player verschieben. Die Message ausgeben.
  • Anmerkung : Für die Erzeugung der Message mit dem Completion Code wird der Urwigo Baustein "Concatenate" verwendet. Zur Demonstration wird dieser zweimal ausgegeben. Einmal direkt als Beschreibung des Items "Unlockcode" und zusätzlich als Message eines Kommandos dieses Items. Welche Variante man wählt, ist Geschmackssache. Ich bevorzuge letztere, um in der Itembeschreibung dem Player noch Infos mitzugeben, z.b. wie er bei wherigo.com loggen kann.
Dieses Beispielscript herunterladen

Completion Code als Item erzeugen (Variante 2 / Praxisbeispiel)
  • Aufgabe : Es soll eine Completioncode erzeugt werden, den der Spieler nur bekommt, wenn eine Passwortabfrage richtig beantwortet wurde. Bei einem Wherigo Cache ist in der Praxis dieses Passwort im Final/Logbuch platziert. Nur wenn es gefunden wurde, kann das Passwort eingegeben und der Wherigo abgeschlossen werden.
  • Realisierung : Passwortabfrage durch Input Eingabe, Vergleich der Antwort, wenn richtig dann Cartridge auf durchgespielt setzen, Infomessage durch String/Variablen Verkettung bilden, unsichtbares Item sichtbar machen und zum Player verschieben. Die Message ausgeben.
  • Anmerkung : Die Inputeingabe wird mit einem weiteren Item realisiert, welches nach erfolgreicher Eingabe gelöscht wird.
Dieses Beispielscript herunterladen

Verschiedenes

Concatenate (String-/Variablenverkettungen)
Mit "Concatenate" können Teilstrings und Variablenwerte zu einem Gesamtstring verkettet werden. Dazu wird eine Messagebox angelegt, in die dann zunächst der Baustein "Concatenate" hineingezogen wird. Dieser wird wiederum nach und nach mit den gewünschten Strings und Variablen gefüllt.
  • Aufgabe : Der Spieler soll im Begrüßungstext mit seinem Namen angeredet werden. Zusätzlich wird das aktuelle Datum und die Uhrzeit angezeigt.
  • Realisierung : Ermittlung der notwendigen Daten und speichern in Variablen. Verketten der Teilstrings und Zuweisung des Gesamtstrings an eine weitere Variable. Anzeige des Strings in einer Messagebox und zusätzlich als Itembeschreibung.
  • Anmerkung : Der Gesamtstring kann, wie hier, entweder in einer Variablen gespeichert oder auch direkt in der Messagebox ausgegeben werden. Die Variante der Variablenzuweisung find ich flexibler. Oft können "zusammengebastelte Strings" im Verlauf des Wherigos noch einmal verwendet werden, so daß man in dem Fall nur auf die Variable zuzugreifen braucht.
Dieses Beispielscript herunterladen

Zufallswerte (Entscheidungen und Zahlen)
Man kann Entscheidungen und Zuweisungen nicht nur statisch vornehmen (wie Zahl=3 oder Frucht=Birne) sondern auch zufällig generieren lassen. So ist die Möglichkeit gegeben aus einem vorgegebenen Bestand zufällig ein Element auszuwählen. Daneben können auch Zufallszahlen aus einem festgelegten Wertebereich erzeugt werden (Zufallszahl zwischen 1 und 6)
  • Aufgabe : Ein Obstgeschäft eröffnet neu ;-) und wir ziehen Lose. Mögliche Gewinne sind Bananen, Birnen und Zitronen. Jedes Los enthält auch die Anzahl der Früchte die wir gewinnen.
  • Realisierung : Item Zufallsspiel mit 1 Kommando, Generieren einer Zufallszahl zwischen 1 und 5, Zufallsentscheidung welche Frucht, Aktualisierung des Bestands pro Frucht, Ausgabe des aktuellen Gewinns und des Gesamtbestandes als Beschreibung des Items.
  • Anmerkung : Die Wahrscheinlichkeit einer zufälligen Auswahl lässt sich gewichten, so daß es z.b doppelt so wahrscheinlich ist, daß das Element A statt B oder C "gezogen" wird (statt 33-33-33 eine Gewichtung von 50-25-25). Zufallszahlen können auch negative Werte annehmen (-10 bis +10). Eine Subtraktion wird dann am besten durch Addition eines negativen Wertes realisiert, wie 15 + (-3). So kann in der Summenformel immer mit der Operation "addiere" gerechnet werden.
Dieses Beispielscript herunterladen

Demo Cartridges (Open Source)

Advent

Veröffentlichter Cache: [1]
Du musst die Bestandteile für einen Adventskranz suchen, den Kranz zusammenbauen und die Kerzen anzünden, dann bekommst du die Finalkoordinaten.
In der Open-Source-Cartridge wurden natürlich die echten Finalkoordinaten / Stage-Koordinaten entfernt.
Die Cartridge ist sowohl in einer Play Anywhere-Variante (Walk-Anywhere) als auch mit fest einprogrammierten Koordinaten spielbar.
Die Cartridge kann über Datei:Advent opensource.zip heruntergeladen werden

Türme von Hanoi

Veröffentlichter Cache: [2]
Du musst den Turm von Hanoi (siehe Wikipedia) abtragen und auf dem eigentlichen Bauplatz wieder aufbauen. Dabei kannst du immer nur ein Teil
transportieren und immer nur ein kleineres Teil auf ein größeres Teil stapeln. Der am falschen Ort aufgebaute Turm steht auf dem Platz Schatzinfo
und muss auf dem Bauplatz wieder aufgebaut werden - du wirst den Materialplatz zum Ablegen von Bauteilen benötigen.
Das Spiel kann mit 3, 4 oder 5 Bauteilen gespielt werden und ist absolut generisch in Urwigo programmiert mit LUA-Code.
Es wird größtenteils auf komplizierte IF-Bedingungen verzichtet.
Die Cartridge enthält manche interessante Dinge, die für andere interessant sein können (aber nicht müssen) z.B.:
* Play Anywhere Initialisierungscode
* Ermittlung von Bildern aufgrund eines zusammengesetzten Namens (für die Darstellung der Türme)
* Speicherung der notwendigen Informationen direkt in den Zonen (Erweiterung von Objekt-Attributen)
* Umgang mit Tables
Die Cartridge kann über Datei:Hanoi.zip heruntergeladen werden

Historie der Scriptbeispiele

Im folgenden eine Historie für alle, die öfters mal vorbeischauen und sehen wollen, ob es was neues gibt. Man muss somit nicht die ganzen Kategorien durchforsten. Der Beispielname wird genannt, in Klammern dahinter die Kategorie in der sich das Beispiel befindet.

  • 02.12.2013 Neu : Input Handling aus der Praxis (Abschnitt Inputs)
  • 05.11.2013 Neu : Intervalltimer mit Stop im onStart Event (Abschnitt Timer)
  • 10.08.2012 Neu : Intervalltimer (Abschnitt Timer)
  • 27.12.2011 Neu : Item im Item (Abschnitt Items)
  • 25.12.2011 Neu : Tasksteuerung mit Variablen (Abschnitt Tasks)
  • 25.12.2011 Neu : Tasksteuerung mit Tasks (Abschnitt Tasks)
  • 25.12.2011 Neu : Open-Source-Cartridge 4. Advent als Play-Anywhere und mit festen Koordinaten (Abschnitt Demo-Cartridges)
  • 21.12.2011 Neu : Inputverkettung mit Abbruchmöglichkeit (Abschnitt Inputs)
  • 21.12.2011 Neu : Inputverkettung ohne Abbruchmöglichkeit (Abschnitt Inputs)
  • 17.12.2011 Neu : Dynamischer Dialog mit einem Charakter (Abschnitt Charakter)
  • 17.12.2011 Neu : Statischer Dialog mit einem imaginärem Charakter (Abschnitt Charakter)
  • 17.12.2011 Neu : Statischer Dialog mit einem Charakter (Abschnitt Charakter)
  • 11.12.2011 Neu : Zufallswerte (Abschnitt Verschiedenes)
  • 11.12.2011 Neu : Tasksetzen (Abschnitt Tasks)
  • 11.12.2011 Neu : Item_kombi (Abschnitt Items)
  • 10.12.2011 Neu : Wettlauf (Abschnitt Timer) / Änderung : Inputtypen (Abschnitt Inputs)
  • 09.12.2011 Neu : Die ersten Beispiele sind verfügbar
Meine Werkzeuge
Namensräume
Varianten
Aktionen
Navigation
Werkzeuge