LOCATION BASED STORYTELLING //

Titelbild

Unter dem Arbeitstitel “Location Based Storytelling” wurde eine Methode zur modularen Erzählung einer Geschichte per Geokoordinaten entwickelt. Nutzer können anhand ihres Smartphones die Geschichte des amerikanischen Soldaten Russell E. Dunham bei der Einnahme des Reichsparteitagsgeländes in Nürnberg miterleben.


A // AUSGANGSPUNKT //

Die grundlegende Idee der Arbeit besteht darin, realen Ort und erzählte Geschichte auf möglichst interessante Weise miteinander zu verknüpfen.

RECHERCHE // INHALT

Um das Thema Location Based Storytelling anzugehen wurden zunächst Recherchen in verschiedene Richtungen, wie beispielsweise Alternate-Reality-Games (ARGs), Fitness-Games, Gamification, Cut-Up-Stories und Hypertextstories durchgeführt.
Resumierend lässt sich dabei sagen, dass ARGs besonders großen Aufwand bei ihrer Erstellung, sowie auch beim Spiel selbst verursachen. Die Zielgruppe selbst ist hingegen sehr klein und es ist enorme Motivation der Spieler erforderlich, um das Erlebnis bis zum Ende zu bestreiten.
Fitness-Games, wie sie beispielsweise derzeit in den App-Stores verfügbar sind, versuchen die Zeit während körperlicher Aktivität aufregender zu gestalten. Dabei stehen entweder die tatsächliche Fitness oder einfach nur das Aktiv-Werden im Vordergrund. Es wird nur die zurückgelegte Strecke oder die verbrannten Kalorien für Spiel-interne Goals gemessen. Die Geschichte findet dabei in einem eigenen Universum statt. Die Immersion wird zwar durch die Bewegung des Spielers parallel zur Bewegung der Spielfigur erhöht, jedoch fehlt der Bezug zum realen Ort.
Gamification schlägt in die gleiche Richtung. Elemente aus Spielen werden angewendet, um Alltagsaufgaben zu bewältigen.
Die Methoden des Cut-Up und von Hypertextstories wurden eher methodisch betrachtet. Interessant war hierbei der Aspekt, wie aus gegebenen Strukturen und Elementen neue, möglichst generative Erfahrungen gestaltet werden können.

Die detaillierte Zusammenfassung der Recherche mit Quellenangabe ist aufrufbar unter folgendem Link:
http://campus-muenchberg.de/ixd-ws2014/2014/11/09/recherche/

RECHERCHE // TECHNIK

Als Basis für die technische Ausstattung des Spielers wurde der Besitz eines aktuellen Smartphones vorausgesetzt. Um ein Konzept definieren zu können war es notwendig, die technischen Möglichkeiten kennenzulernen und sich verschiedene Einsatzmöglichkeiten auszudenken. Interessant ist hierbei die Möglichkeit, die Immersion des Spielerlebnisses zu erhöhen, indem bereits vorhandene Technik, die ein Großteil der Spieler sowieso besitzt, genutzt wird. So können über die verschiedenen Messinstrumente, wie beispielsweise Mikrofon, Gyrosensor, Helligkeitssensor oder Pulsmesser (per Fitnesstracker) Details zum Aktivzustand, der Bewegung und der Umgebung des Spielers gesammelt werden. Auch die Ausgabemethoden sind vielfältig. So lassen sich durch Sound, Vibration oder Interaktion mit anderen Spielern immersive Erlebnisse schaffen, die ausgehend allein vom Gerät – einem einfachen Handy – zunächst nicht erwartet werden.
Im Verlauf der Recherche wurden auch erste Skizzen zur Aufzeichnung von Wegen und Umgebungen erstellt, die auf der Messung von WLAN-Signalen und GPS-Koordinaten basieren. Genauere Informationen finden sich unter unten angegebenem Link.
Soll das Konzept auch in Außenbereichen funktionieren, werden detaillierte Informationen über die Umgebung benötigt, wie sie beispielsweise auch in Google-Maps verfügbar sind. Hierzu wurden die Inhalte von Openstreetmap – einer Open-Source-Kartendatenbank – betrachtet. Dabei wurde deutlich, dass für nahezu alle Regionen des Landes eine Vielzahl an Informationen bereits vorhanden ist. Um darauf reagieren zu können, muss die entstehende App die Kategorien der Kartendaten verarbeiten können, wie beispielsweise “Bushaltestelle”, “Café”, oder ähnliches. Auch hier war der Aspekt interessant, offene, bereits vorhandene Daten zu nutzen.

Übersicht über Inhalte, die dem User gegeben (Input) und die von ihm erhalten werden können (Output):

Input&Output1

Die detaillierte Zusammenfassung der Recherche mit Quellenangabe ist aufrufbar unter folgendem Link:
http://campus-muenchberg.de/ixd-ws2014/2014/11/09/technik/

IDEENFINDUNG // SPIELKONZEPTE

Recherche und Ideenfindung fanden parallel statt. Während sich technische Ideen bereits herauskristallisierten war das Konzept selbst noch weitgehend offen.

Anfangs war das Ziel des Projekts die Entwicklung eines Spiels mit Interaktion im Raum. Hierzu wurden Ideen zu Story-basierten Varianten, wie beispielsweise einem Zombie-Szenario oder einer Horror-Story entwickelt und die Ausrichtung des Spielerlebnisses festgelegt. Aufgrund der Gefahr, dass der Spieler hohen eigenen Antrieb aufbringen muss, sowie beim Spielen in der Öffentlichkeit beim Fokus auf Spielelementen – nicht auf Fitnesselementen – albern aussehen könnte, wurden die Ideen wieder verworfen.
Weitere Interessante Ansätze beziehen sich eher auf die resultierende Anwendung des Spiels. Beispielsweise dem Fokus auf Gamification im Alltag, dem Finden eines Partners in Form einer Lovestory oder dem Profilieren in sozialen Netzwerken per Pranks. Aufgrund mangelnder Spieltiefe wurden die Ansätze allerdings ebenfalls wieder verworfen.
Eine angedachte mögliche Anwendung wäre der Einsatz der App als Werbeträger, beispielsweise als Second-Screen zu Portalen wie Netflix oder Maxdome, die Werbung zusammen mit Vibrationseffekten oder in Bezug zum Aktivzustand des Zuschauers punktgenau anhand der Audiospur des laufenden Films platzieren könnten.

IDEENFINDUNG // SPIELMECHANIKEN

Auch Spielmechaniken wurden analysiert. Dabei war vor allem interessant, wie sich das Verhalten der Spieler durch Einflüsse von außen manipulieren lässt. Beispielsweise könnte man hierbei Negativposts durch die App in sozialen Netzwerken nutzen. Ein ähnlicher Effekt ließe sich auch durch Likes echter Personen erzielen, die bestimmte Ereignisse mehr oder weniger würdigen und somit die Aktionen des Spielers beeinflussen.
Besonders hervorzuheben ist auch der Aspekt des Cheatens. Dies kann auf verschiedene Weisen eingesetzt werden. Entweder kann der Spieler die gegebene Technik nutzen und cheaten, um die App auszutricksen, beispielsweise indem er seinen Fitnesstracker an den Deckenventilator hängt. Der weit witzigere Weg, die App auszurichten, wäre, die Anforderungen so hoch zu setzen, dass der Spieler cheaten muss, um die Aufgaben zu bestehen. Dabei steht die eigene Kreativität bei der Vorgehensweise im Fokus. Diese Aspekte können auch gemeinsam im Zusammenspiel genutzt werden. Kreatives Cheating und Likes anderer Nutzer würden zu immer neuen Ergebnissen führen und den Wettbewerb unter den Spielern fördern.

Letztendlich konnten die Spielmechaniken allerdings noch nicht in ein schlüssiges und funktionierendes Spielkonzept übertragen werden.

Übersicht über Inhalte, die dem User gegeben (Input) und die von ihm erhalten werden können (Output):

Input&Output2

Die detaillierte Zusammenfassung der Ideen und Spielmechaniken ist aufrufbar unter folgendem Link:
http://campus-muenchberg.de/ixd-ws2014/2014/11/10/ideen/


B // KONZEPTIDEE 2ND DIVOICE //

Die erste konkrete aus den Recherchen resultierende Konzeptidee wurde zunächst unter dem Arbeitstitel “Virtual Buddy” entwickelt. Dabei handelt es sich um einen Begleiter für den Alltag, der den Nutzer sowohl informiert, als auch kommentiert und unterhält. Auf Basis des Konzepts können verschiedene Charaktere entworfen werden, die jeweils ihre persönlichen Eigenheiten besitzen. Beispielsweise hören sich die Kommentare einer pöbelnden, auf Spaß ausgelegten Figur anders an, als die Kommentare eines Infoguides für Blinde. Auf diese Weise lassen sich verschiedene Ausrichtungen mit der selben zu Grunde liegenden Technik erzielen. Auch das Erzählen von Geschichten, die in den Alltag integriert werden können, wäre denkbar.
Im Laufe der Ausarbeitung wurde die Namensgebung in “2nd Divoice” geändert. Diese setzt sich aus den Begriffen “2.”, “Device” und “Voice” zusammen, was so viel bedeutet wie die Verwendung einer mobile Device (Mobiltelefon) als zweite Stimme, die den Nutzer kommentiert.
Das System wurde nach und nach weitergedacht und um folgende technische Mittel ergänzt:

STUFE 1 // STORYELEMENTE

Während der ersten Ausarbeitungsphase wurde das Konzept zunächst für einen Charakter ausgelegt, der den Nutzer über eine Woche hinweg begleitet. Daten von Openstreetmap sollten Umgebungsdetails liefern, die vom System nach und nach gespeichert werden, wenn ein und dieselbe Koordinate auf der Landkarte angesteuert werden (Vgl. Mindmap: “Weg”). Auf diese Weise wird ermöglicht, dass der Charakter von Tag zu Tag unterschiedliche Aussagen zu den gleichen Standpunkten im realen Leben treffen kann (Vgl. Mindmap: “Wochentage”). Weicht der tägliche Weg des Nutzers, beispielsweise dessen Arbeitsweg, vom Schema ab, so kann die App ebenfalls darauf eingehen und die neue Route oder neue interessante Orte kommentieren.
Um das unmittelbare Umfeld des Spielers erfassen zu können, können Tweets oder Facebook-Posts mit Geotag ausgelesen werden. Sind die resultierenden Daten mit vordefinierten Kategorien einer Datenbank abgleichbar, kann der Charakter auch das direkte Umfeld kommentieren, beispielsweise Personen, etc. Daten aus Openstreetmap stehen ebenfalls zur Verfügung und liefern beispielsweise mögliche Anhaltspunkte über Personen in umliegenden Geschäften. Wo ein Kiosk ist, befindet sich – im Abgleich mit der Uhrzeit – auch ein Verkäufer, der vom Charakter möglichst unbestimmt, aber auf witzige Weise beschrieben werden kann.
Das Konzept wurde in einer Mindmap erfasst und mit einer beispielhaften User-Journey versehen.

Mindmap_2ndDivoiceDie Mindmap in hoher Auflösung als PDF findet sich unter folgendem Link:
150207_Mindmap_2ndDivoice

STUFE 2 // INPUT FÜR VIELE SITUATIONEN

Um für alle möglichen Situationen geeignete Aussagen des virtuellen Begleiters zu erstellen ist ein hoher Zeitinvest erforderlich. Die Daten von Openstreetmap wurden analysiert und grob gegliedert. Es wären nach bisherigem Konzept unterschiedliche Aussagen für verschiedene Wochentage zu jeder möglicherweise eintretenden Situation nötig. Mehrere Texter wären hiermit einige Zeit lang beschäftigt. Aufgrund der zahllosen möglichen Varianten wurde das Vorgehen hier zunächst gestoppt.

STUFE 3 // GENERATIVER INPUT

Das Problem mit der Erstellung einer umfangreichen Input-Datenbank sollte per Twitter gelöst werden. Ziel war es, die App automatisch Tweets realer Personen zitieren zu lassen. Dies wurde prototypisch zusammen mit dem Tutor Alexander Roidl per Processing umgesetzt. Auf diese Weise konnten nun Tweets zu bestimmten Suchworten ausgelesen werden. Gleichzeitig wurden Hashtags, Links, etc. entfernt. Im nächsten Schritt wurde der Processing-Sketch zusammen mit Professor Michael Zöllner erweitert (“tweetslist2_plus_saetze”), um den zitierten Sätzen Eigenheiten des Charakters anzufügen. Dazu mussten die Originaltweets zunächst auf positive oder negative Äußerungen untersucht werden. Beispielsweise werden so bei negativen Aussagen die Präfixe “Duh.”, “Oh man.”, “Damn.” oder “Shit.”, bei positiven Aussagen “Yeah!”, “Supi!”, “Rock!” oder “Yes!” vor den eigentlichen Twitter-Satz geschrieben. In diesem Zusammenhang wurde auch angedacht, die per Twitter erhaltenen Zitate mit Systemen wie “Rita” und “Wordnet” umschreiben zu lassen, indem einzelne Worte analysiert werden und mit Synonymen ausgetauscht werden. So sollten die entstehenden Aussagen des Charakters möglichst generativ gestaltet werden und sich vom ursprünglichen Post auf Twitter abheben. Der virtuelle Begleiter sollte seine Eigene Sprache entwickeln, die sich von mal zu mal unterscheidet und sich so selten wie möglich wiederholt.

procshitoh man

damntxt

In der final angestrebten Umsetzung würde die App Schlagworte per Twitter beziehen, solange sich der Nutzer in Abgleich mit Openstreetmap in einem bestimmten lokalen Bereich rund herum um einen Geotag, beispielsweise eine Buchhandlung, befindet. Verlässt er diesen, wird der nächste Geotag, beispielsweise eine Bushaltestelle, verwendet, und Twitter wird anhand anderer Schlagworte durchsucht. Auf diese Weise kann jeweils auf die letzten 5-10 Tweets des entsprechenden Suchwortes zurückgegriffen werden, ohne dass diese sich von Geozone zu Geozone unmittelbar wiederholen.

Der originale Code, auf dem aufgebaut wurde ist unter folgender Quelle aufrufbar:
Codasign: Processing and Twitter – Searching Twitter for Tweets, in: codasign.com, letzter Aufruf am 07.02.2015, http://codasign.com/tutorials/processing-and-twitter/processing-and-twitter-searching-twitter-for-tweets/

Der mit Processing erstellte Code kann unter folgendem Link heruntergeladen werden:
https://www.dropbox.com/s/7573rvmc2fken2m/G%C3%B6tz_Programmierung.zip?dl=0

STUFE 4 // INTERAKTION MIT DEM BOT

Das Projekt wird noch weit spannender, wenn das System User-Interaktion zulässt. Hierbei war angedacht, Spracherkennung in Anlehnung an das bekannte Programm “Eliza” (Manifestation.com: Eliza, computer therapist, in: manifestation.com, letzter Aufruf am 07.02.2015, http://www.manifestation.com/neurotoys/eliza.php3) einzubauen, damit der virtuelle Begleiter auf Anfragen des Nutzers reagieren kann.
Damit das System allerdings auf alle per Open Streetmap gegebenen Möglichkeiten reagieren kann, ist, genau wie bei der Erstellung von genügend Input, enormes Engagement in Bezug auf Frage- und Antwortmöglichkeiten notwendig. Hier müsste eine generative und selbstständige Lösung noch erarbeitet werden.

STUFE 5 // INTERAKTION MIT ANDEREN NUTZERN

Die letzte erwünschte Evolutionsstufe des Programms wäre die Interaktion mit anderen Nutzern durch den Bot. Beispielsweise sollte der virtuelle Charakter in Abhängigkeit zur Situation des Nutzers auch dessen bekannte benachrichtigen. Ein Beispiel hierfür ist – passend zur anfangs ausgedachten Story rund um den Begleiter – die Frage des Bots, ob er der Freundin des Nutzers etwas aus einem nahegelegenen Supermarkt, einer nahegeledenen Bäckerei, etc., mitbringen soll. Der Charakter würde so die Interaktion zwischen User und dessen echten Bekanntschaften antreiben und für Spannung und unerwartete Momente sorgen.

Insgesamt besteht das unter B beschriebene Projekt aus vielen Einzelteilen, die in ihrer Form zunächst nicht beherrscht werden können. Der Umfang und das gewünschte Ziel erfordert gute Programmierkenntnisse, hohe Rechercheleistungen und viel zeitlichen Invest. Eine tatsächliche Anwendung von Nutzern in ihrer Freizeit ist ebenfalls noch fraglich, da die Gefahr besteht, dass das Programm auf dauer eher Stress verursacht, als zu unterhalten. Der angedachte Einsatz von Sound- oder Vibrationseffekten würde den Aufwand und den potenziell verursachten Stress nochmals steigern. Insgesamt musste das Projekt aus diesen Gründen zugunsten einer realen Anwendung im Bereich eines Guides für historische Begebenheiten im Entwurfsstadium verbleiben.


C // KONZEPTIDEE LOCATION BASED STORYTELLING //

Auf Basis der bisher erarbeiteten Grundlagen konnte eine real einsetzbare Anwendung für ortsbasierte Geschichten entwickelt werden. Das gesamte System wurde dazu wieder auf seine wesentlichen Elemente reduziert: Ortskoordinaten und die eigentlich erzählenswerte Geschichte.

Der Ansatz des Projektes greift in die Richtung gängiger Audioguides, die sich Besucher eines Museums oder einer Stadt üblicherweise ausleihen können. Audiodaten sind dabei nicht in Form eines Sprechers angedacht, sondern eher als unterstützende Soundeffekte, die Atmosphäre schaffen können. Besonderer Fokus liegt auf der persönlichen Kommunikation des Charakters der Geschichte mit dem Benutzer. Wünschenswert wäre hierbei der Zugriff der App auf die SMS-Funktion des Handys. Auf diese Weise könnte eine persönliche Bindung zur Person entstehen, als würde die virtuelle Person wirklich auf eine heute übliche Weise mit dem Nutzer kommunizieren.

Ein Prototyp wurde mit dem Programm “if this then that” (ifttt) und der Twitter-App auf dem eigenen Handy erprobt. Audiodaten konnten hierbei auf Basis der technischen Grundlage nicht eingesetzt werden. Twitter war der Kanal der Wahl, da sich hiermit per mobilem Internet live Posts absetzen lassen, die ebenfalls mit Fotos kombiniert werden können. Für den Prototypen konnte dies mit der SMS-Funktion vorerst nicht realisiert werden.

In Zusammenarbeit mit dem Dokumentationszentrum des Reichsparteitagsgeländes (RPG) in Nürnberg wurde die Geschichte des amerikanischen Soldaten Russell E. Dunham hergenommen, um dem Nutzer dessen Erlebnisse im Bezug zum realen Ort zu vermitteln.

UMSETZUNG // STORY

Zunächst wurde die Geschichte des Soldaten erarbeitet. Grundlage hierfür bildete das Buch “Die US-Armee in Nürnberg auf Hitlers “Reichsparteitagsgelände”” von Peter Heigl (Heigl, Peter: Die US-Armee in Nürnberg auf Hitlers “Reichsparteitagsgelände”, Nürnberg, 2003).
Die Story wurde aus der persönlichen Sicht von Russell E. Dunham geschrieben. Die Herausforderung bestand darin, Textabschnitte von maximal 140 Zeichen zu erstellen, die die Länge eines Standard-Tweets nicht überschreiten.
Die jeweiligen Abschnitte der Erzählung wurden durch Fotos aus den US National Archives ergänzt (Fotos wurden in Absprache mit Herrn Alexander Schmidt aus dem genannten Buch von Peter Heigl reproduziert).

Insgesamt sind 26 Tweets in Verbindung mit 13 Fotos entstanden, die Russell E. Dun hams Übernahme des Reichsparteitagsgeländes schildern. Diese können per Ortskoordinaten modular abgerufen werden. Der Ablauf der Geschichte liegt in der Hand des Nutzers.

Tweets_EntwurfUMSETZUNG // TECHNIK

Auf technischer Seite wurde der Prototyp unter Zuhilfenahme des Programms ifttt und der Twitter-App realisiert.
Ifttt gewährt dabei zahlreiche Möglichkeiten Input und Output aktueller Smartphones wie beispielsweise dem iPhone zu analysieren oder zu generieren. Für den Prototypen am iPhone 5S wurde vor allem die Funktion “iOS Location” – die Ortungsfunktion des Handys – sowie der Twitter-Channel verwendet. Die hier aufs wesentliche reduzierte Funktion der Apps im Zusammenspiel kann wie folgt beschrieben werden: Ifttt ist gewissermaßen Vermittler zwischen Grundfunktionen des Handys und bestimmten Apps. Man umgeht somit eigene Programmierarbeit, erhält aber ähnliche oder identische Funktionsweisen, wie man sie selbst herstellen würde. Beim Prototypen wurden somit Areale bestimmt, in denen das Handy per Twitter auf das Betreten, Verlassen oder beides reagiert. Sprich: Betritt man eine vordefinierte Geozone, so wird automatisch ein Tweet gepostet.

Der erste Schritt hierbei war die Festlegung der möglichen Wegeführung, der Geozonen, sowie die systematische Platzierung der Ortsspezifischen Tweets auf dem Areal des Reichsparteitagsgeländes:

RPG Satellit

Verteilung Geozonen und Tweets
Verteilung Geozonen und Tweets2
Verteilung Geozonen und Tweets3

Geozonen wurden so angelegt, dass es insgesamt so wenige wie möglich gibt. Es wurde eine Struktur aus verschiedenen Zonen erstellt: Blau dargestellte Bereiche tweeten beim Betreten des Bereichs, grün dargstellte Areale posten Nachrichten zunächst beim Betreten, anschließend nochmals bei Verlassen und orangefarbene Zonen werden nur beim Verlassen der Koordinaten aktiviert. Beim Layout der Bereiche wurde darauf geachtet, dass Nutzer die Story aus möglichst vielen Eintrittswinkeln nachvollziehen können. Sie erhalten stets zur rechten Zeiten die richtige Nachricht aufs Handy, egal von welcher Himmelsrichtung aus sie sich den Stationen nähern. Ein gutes Beispiel hierfür ist die Zone rund um das Zeppelinfeld. Diese ist recht großzügig angelegt, damit das Feld von jedem der Zugänge aus betreten werden kann und dabei trotzdem der Trigger ausgelöst wird. Zunächst wird dabei getweetet: “Das Zeppelinfeld. Noch ein Ort für Aufmärsche und Paraden, geschmückt von einem Hakenkreuz mit Lorbeerkranz auf der Haupttribüne.” Anschließend hält sich der Besucher des RPG einige Zeit in diesem Bereich auf, stößt auf weitere Tweet-Bereiche, etc. Zu einem späteren Zeitpunkt verlässt er das zuvor betretene große Areal rund um das Zeppelinfeld wieder und löst durch das Verlassen des Gebiets erneut einen Trigger aus: “Lasst die Yankee Doodlers spielen!” – Dieser Tweet schließt gewissermaßen den Kreis rund um das Zeppelinfeld. Das Zusammenspiel aller Geozonen wird im beigefügten Dokumentationsvideo genau erläutert.

Im Anschluss wurden die Vorüberlegungen in Ifttt übertragen und die Ortskoordinaten mit den jeweiligen Tweets eingestellt:

Verteilung Geozonen und Tweets Verteilung Geozonen und Tweets2 Verteilung Geozonen und Tweets3 Verteilung Geozonen und Tweets4

Ifttt ist fest mit dem eigenen Twitter-Account verknüpft. Tweets werden vom verknüpften Account aus abgesetzt. Die übliche Funktion der Zuordnung von Tweets per “@Username” funktioniert in diesem Zusammenhang leider nicht, da Russell E. Dunham die damit erhaltenen Tweets nicht automatisch veröffentlichen lassen kann. Sprich im derzeitigen Entwicklungsstand funktioniert der Prototyp für eine Einzelperson wunderbar, kann jedoch nicht als Russell E. Dunham für die Öffentlichkeit bereitgestellt werden. Herunterladen der jeweiligen Rezepte für Jedermann ist dennoch möglich, allerdings werden die abgesetzten Posts dann in der jeweils eigenen Twitter-Timeline veröffentlicht. Für eine Realisierung des Projekts wäre allerdings der Zugriff auf die SMS-Funktion des Handys aus bereits genannten Gründen wünschenswert.

ERGEBNIS //

Das Ergebnis des Projektes ist ein funktionierender Prototyp, der automatisch ortsbasierte Tweets absetzt.

Vorteil des Systems ist, dass der Nutzer je nach Belieben das Areal erkunden kann und immer zum richtigen Zeitpunkt die nächste Nachricht von Russell E. Dunham erhält. Ein Rundgang über das historische Gebiet muss also nicht linear ablaufen, sondern richtet sich nach den Bedürfnissen der Anwender.

Der Nutzer kann durch Erforschen des Reichsparteitagsgeländes die Geschichte Dunhams nachvollziehen und stößt immer wieder auf neue Details zur Geschichte. Die gesamte Geschichte inklusive Fotos kann letztendlich per Twitter-Timeline nochmals nachgelesen werden und wird durch eine Fotowand ergänzt.Hi Def 1

Verteilung Geozonen und Tweets Verteilung Geozonen und Tweets2 Verteilung Geozonen und Tweets3Hi Def 3
Hi Def 2
Verteilung Geozonen und Tweets4Verteilung Geozonen und Tweets5Verteilung Geozonen und Tweets6Verteilung Geozonen und Tweets7Verteilung Geozonen und Tweets8Bildschirmfoto 2015-01-21 um 02.48.40


VIDEODOKUMENTATION //

Die ausführliche Videodokumentation kann unter folgendem Link heruntergeladen werden (Dauer ca. 24 min. – Bitte herunterladen – Dropbox gewährt nur eine Vorschau von 15 min):
https://www.dropbox.com/s/xk3sspidfi4l4nr/Interaction_RPG_final.mp4?dl=0

Ein Teaser der Videodokumentation kann unter folgendem Link heruntergeladen werden:
(Dauer ca. 3 min. – Bitte herunterladen):
https://www.dropbox.com/s/41yi0ic2n6l8c13/Interaction_RPG_Trailer.mp4?dl=0


AUSBLICK //

Ziel des Projektes wäre eine Umsetzung als eigenständige App mit Zugriffsrechten auf die SMS-Funktion. Somit könnte Russel persönlich mit dem Nutzer interagieren, anstatt auf Twitter als Konversationsmedium zurückzugreifen. Die erhaltene Geschichte kann dann zusammen mit Fotos per SMS-Verlauf nachgelesen werden.
Eine andere Möglichkeit wäre die Programmierung einer eigenständigen App, die von der Funktionsweise des Prototypen unwesentlich abweicht, jedoch keine Einstellungen seitens des Nutzers erfordert.


CREDITS //

Constantin Götz