29 1 Case: myTHeme Sus Lundgren

29 2 Vad är myTHeme ”A Storytelling game for non-storytellers”’ Ett datorförstärkt kortspel

29 3 Personer Staffan Björk (PLAY/II) – javaprogrammering spel(regel)design Jennica Falk (PLAY/II) – texter Sus Lundgren (PLAY/II) – spel(regel)design, grafisk design av kort & spelplan Karl Petter Åkesson (SICS) – hårdvara Divere annat löst folk –Jussi Holopainen (Nokia) – provspelande, muntra tillrop, feedback –Tobias Rydenhag – provspelande –Johan Thoresson - provspelande

29 4 Varför detta case? Hade funkat som projekt 2; det är en kombination av ett ovanligt inmatningssätt (sensorer) och ett ovanligt utmatningssätt (stor skärm, fleranvändarmiljö) Design på många nivåer som påverkar varandra –Spelregler –Grafisk design av kort och spelplan –Berättelsen och dess deltexter –Programmering –Hårdvara Många intressanta designval och iterativ designprocess

29 5 Vad är myTHeme Kortspel som med hjälp av reglernas design gör att det skapas en historia när man spelar Spelet är datorstött; historien genereras med hjälp av ett bibliotek texter (en för varje kort) och ett javaprogram Vilka kort som spelas och i vilken ordning läses in av en RFID-sensor; korten har motsvarande taggar i sig –Dessa data tas om hand av javaprogrammet Den pågående historien projiceras på storskärm

29 6 RFID-teknologin RFID-tags and readers is a technique used for keeping track of items. It uses very weak radio signals to communicate. First, there is one or several RFID-tags hidden in some kind of component. A tag only holds one piece of information; its value or id, and it does not require any electricity to work. It is small, cheap and very useful. Second, there is a RFID tag reader. This one has to get power from some source, but it needs quite little. The tag reader activates the tags when they are put onto it, reads their value and then sends this data somewhere. Unfortunately the tag readers cost fairly much.”

29 7 Designprocess Notech-iterationer –Design av spelregler och kort –Speltest  redesign av spelregler och kort Hitech-iterationer –Hårdvarukrav & programmeringskrav  redesign spelregler –Spelplansdesign –Textförfattande styrt av spelregler och programmering  styr i sin tur programmering –Speltest  redesign

29 8 Design: Test Demo i Stockholm –Redesign spelregler  redesign programmering & redesign texter Demo i Utrecht –Redesign spelregler  redesign programmering, redesign texter, redesign spelplan

29 9 Så började det… London, spelkonferens, Staffan Björk och Jussi Holopainen (Nokia) ber mig skapa reglerna till ”ett historieberättarspel”.

29 10 Narrativa strukturer Vad finns i en historia? –Hjälten –Bifigurer –Problemet/utmaingen/äventyret –Lösning(ar) på ovanstående Tretal vanliga, sju också ett vanligt tal Ett äventyr ofta en serie problem/lösningar och ibland konsekvenser av dessa –Hjälten stöter på en drake(p), dödar draken(l), får skatten(k) –Hjälten är utmattad och faller i sömn(l) men blir bestulen på en del av skatten(k)

29 11 Det första embryot till spelidé Det skulle handla om att få sina kort att ingå i det som blir den ”riktiga” historien; –hela tiden kan det finnas upp till tre tänkbara förlopp som konkurrerar Ett förlopp blir ”sant” så snart det har ”jämna par” problems/solutions och ett resultat –Men det kan finnas upp till tre problem- solution-par i en ”tråd” alltså max sju kort i en tråd (resultatet är ju ett kort också)

29 12 Prototypfas 1 Spelidé fyra teman (former), fyra färger –Heroes –Problems Enemies Physical Psychlogical –Solutions Enemies Physical Psychlogical –Results –Conclusions

29 13 Prototypfas 1 Bisarr budgivningfas för att etablera temat Skapande av substories –Målet var att dels få sina kort med i vinnande substory, dels att lägga kort i långa sekvenser av färg och/eller form Slut - poängräkning  Ännu så länge helt oimplementerat: enbart provspelande

29 14 Fysisk spelplan

29 15 Provspel visade att… Alldeles för komplext med fyra färger och fyra symboler –Tre färger och tre symboler istället Vi fick aldrig till budgivningsfasen –Den fick utgå… :) Det var oklart vem som spelat vilket kort –Placera markörer på sina kort –Alla har varsin lek med kort == många kort == många RFID-taggar == dyrt –Datorn kan hålla reda på detta om man inte bryter turordning –I senare spel, när det blev mera fokus på historierna som skapades ansågs det sistnämnda vara tillräckligt

29 16 Provspel visade att… Det var svårt att se skillnad på typerna av kort, var de problem eller solutions och av vilken typ? –Bokstavsförkortningar blev istället svarta ”pilar” och ”ursparningar” på korten

29 17 Mer om kortdesignen

29 18 Sen kom verkligheten Bra spel men svårt att stödja rent tekniskt Teknisk lösning: RFID-läsare skall hålla reda på de RFID-taggade korten –Min idé med att lägga kort var som helst på spelplanen och därmed säga något om historiens längd etc == 21 RFID-läsare == dyyyyrt! Verklighet: 1 RFID-läsare per substory RFID-taggningen påverkade också kortens storlek; det är bra om taggarna i korten är ungefär lika stora som motsvarigheten i tag-läsaren –Korten fick göras större

29 19 Om texterna Texterna definierade de tre teman (färger) som kom att finnas: epic, tragic, comic XML-filer; något som java kunde läsa Som sagt tre typer av problem-lösningar; fiender, fysiska hinder och psykologiska hinder Ett problem var att alla solutions av en typ var tvungna att fungera ihop med alla problems –Med ett rep kunde man undgå (klättra upp ur) en grop men inte klättra ut ur en fängelsehåla… äsch –Mer luddiga lösningar, inte rep och facklor längre utan uthållighet, list etc.

29 20 Ett ”Problem”... loud savage hulking enormous menacing green Obstacle Opponent And as the tales have been told, just as the air fills with the sound of booming footsteps, something rather large is approaching - a $variant$ giant! Suddenly the ground shakes and tremors violently…,...

29 21 En ”Solution”... strangles punches tackles beats figths strikes battles combats chokes Solution Opponent Mustering great courage and strength the hero $variant$ the life out of the $obstaclename$....

29 22 Om Javaprogrammet Tar in data från RFID-läsaren –Vilket kort som spelats (id) –Vilken substory Kollar: avslutas den substoryn? –Om ja  visar den fullständiga texten och placerar den i den färdiga historien –Om nej  publicerar ”waiting”-texten i fältet för den substoryn När den skapar texter slumpar den in ”variants” och lägger till rätt namn på problem etc Håller också reda på vem som spelat vad för poängräkningen

29 23 Java: Begränsningar Om två problems av samma typ och man spelar en solution, vilken löser den? Massa problem med detta ledde till att man var tvungen att spela korten i rätt ordning –Waitingtexterna blev meningslösa

29 24 Spelplanen

29 25 Spelplanen: Design Svårt att få plats med allt –Den riktiga historien fick delas upp i flera ”skärmar” När waiting-texterna fanns tog en substory oftast inte så mycket plats, men när de försvann blev det krisigt… –Riktigt illa när man inte kunde se det Problem som sist spelats och alltså inte visste vilken typ av Solution som skulle till… Å andra sidan försvann designproblemet att visa vilken sorts kort som låg och väntade i och med det sekventiella spelandet –Alltid Problem varvat med Solution

29 26 Vidareutvecklingar efter speltest Results – inventorysaker som automatiskt användes vid passande kort  påverkade programmeringen –Om man har Dragon’s Bane-svärdet i inventoryt används det automatiskt för att slå ihjäl draken ifall den dyker upp Hjältar/hjältinnor infördes  olika kön i texterna, påverkade texter och programmering Förslag på att dela upp spelplanen i två –en för sagan och en för substories och inventory

29 27 Vidareutvecklingar efter speltest Jokerkort som alltid kan spelas –Oväntade händelser/bonusar Nya kort –New Story –Quit –New Player –Next & Previous (för att bläddra i den färdiga historien) Ange namn på spelare Massor med nya idéer på hur spelet tar slut

29 28 BIG ISSUE Att korten måste spelas i rätt ordning –Hade sin grund i att vi inte kunde ha 21 tagläsare på den fysiska spelplanen; i kombination med begränsningar hos Java (Eller Staffan? Eller tiden?) Påverkade speltaktiken negativt –Gick inte att förlänga en substory genom att spela en massa problems exempelvis Påverkade spelplansdesignen positivt –Problemet med att behöva visa om en text var Problem eller Solution försvann Påverkade textskrivandet –Waitingtexterna försvann igen

29 Lärdomar… Allt påverkar vartannat! –Ju fler olika ”delar” man har i ett projekt, desto mer komplex blir den här väven av beroenden, begränsningar och samverkan Datorförstärkning ger helt nya möjligheter inom speldesign –Flexibilitet –Komplex poängräkning (vill ni veta mer kan ni läsa mitt exjobb…)