aktiviteter Usability2 Udviklingen af prototypen til testen

Udviklingen af prototypen til testen

Prototypen i vores tilfælde adskiller sig væsentligt fra mere artefakt-prægede tilfælde, hvor man har en "dims", som man kan se og røre ved. Vores idé med U2-testen var at lave en prototype, der ville være så tæt på det færdige spil som muligt, hvad angik interaktionen med spillet og den kontekst som det skulle foregå i, for bedst muligt at kunne afteste vores fokuspunkter. hvad angik interaktionen med spillet og den kontekst som det skulle foregå i. Derfor valgte vi at lade testen foregå over flere dage, hvor spillet foregik via sms, præcist som det er tænkt det "rigtige" spil skal gøre.

Vores prototype kan altså sammenfattes i de ting, der gjorde det muligt at give spillerne oplevelsen af et spil. Prototypen bestod således af en hjemmeside, spilfigurer, nogle scenarier og spil idéer, regler, sms-koder og en sms-central til at afsende og modtage sms med. Nedenfor gennemgåes forberedelserne af de enkelte dele i prototypen.

Hjemmeside
En del af konceptet er jo som sagt at spillet har en hjemmeside, hvor man bl.a. skal kunne: se sin egen figur, søge på andre spillere, se highscoreliste og kommunikere med andre spillere fx via chat. Vi overvejede at lave denne hjemmeside selv i ASP. Fordelen ville være, at vi helt selv kunne bestemme indholdet og designet af siden. Her er et tidligt udkast til en sådan side:

Ulempen var dog, som det hurtigt gik op for os, at det ville tage meget lang tid - det ville nærmest blive et designprojekt i sig selv. Og da det var selve spillet og interaktionen med sms, der havde vores fokus i denne test, syntes vi, det ville være et forkert sats af resourcer. Istedet valgte vi at benytte os af igroups.dk - en af de mange groupcare-tjenester på nettet. Vi oprettede således en gruppe www.g13.igroups.dk (prøv fx at logge ind med User: model Pwd: cosmo) på igroups. Her havde vi mulighed for at oprette en profil til hver spiller, der var en chat til rådighed, et besked-system, så spillerne kunne skrive beskeder til hinanden, en login-forside hvor vi kunne offentliggøre highscore. Denne hjemmeside gav os egentlig den funktionalitet vi havde brug for. Den gav os mulighed for at teste vores fokusområder omkring interaktion mellem spillere, der ikke var fysisk sammen både i forhold til det sociale aspekt og bytteaspektet.

Figurer
Vi havde som sagt valgt ikke at teste selve oprettelsen af figurene. Vi lavede således nogle figurer som skulle forestille at have været med i spillet et stykke tid. Vi respræsenterede figurerne med en historik (en forhistorie), et billede og et netværk (de personer som figuren allerede kendte).

Screenshot af figur eksempel
oversigt over figurer

Skabelsen af figurene og skabelsen af scenarierne var en del af den samme brainstorming proces - de to ting skulle jo gerne passe sammen. Det var vigtigt, at der var noget kød på figurerne, og at de var gode potentielle og ligeværdige med- og modspillere indenfor scenariets rammer. Fordelen ved, at vi havde fastlagt figurerne på forhånd, var også, at det gjorde det noget nemmere at forberede et godt scenarie, der kunne indeholde de ting vi gerne ville have testet. Hvis brugerne bare selv fuldstændig kunne have lavet deres figurer (hvilket bestemt kunne have været interessant i en anden sammenhæng) havde vi haft langt mindre styring med scenariet. Problemet var, at vi gerne ville have at brugerne skulle have et personligt forhold til figuren og føle ejerskab og ansvar for den(jf. tamagochi-effekten), hvilket selvfølgelig var lidt svært at tilgodese, hvis vi havde lavet alt på forhånd. Dette problem løste vi ved at lade dem vælge mellem de forskellige figurer - de havde rent faktisk et valg - desuden skulle de lave et navn og vælge en alder til deres figur. Denne løsning var langt fra optimal, men det var den måde, vi mente, at vi trods alt kunne give brugerne en form for medindflydelse på deres figur.

Inspirationen til figurerne hentede vi bl.a. i materialet fra workshoppen på gymnasiet, U1-testen og generelt vores arbejde med scenarier gennem hele forløbet.

Scenarier
Selve scenariet havde en meget central plads i prototypen. Hele omdrejnings punktet i selve spillet var jo netop det scenarie, der ville udfolde sig for spillerne. Det viste sig dog hurtigt også at være en af de sværeste opgaver i prototypeudviklingen. Vi havde det overordnede tema for scenariet på plads - nemlig musik/medie miljøet. Samtidig havde vi også efterhånden nogle ret veldefinerede figurer - det var jo nødvendigt, eftersom vi skulle have nogle konkrete figurer at udlevere til brugerne. Vores første idé var at lave en fuldstændig træstruktur for scenariet, hvor hver forgrening repræsenterede et valg for en af figurerne. Dette viste sig dog hurtigt at være en dårlig idé af flere grunde. Det ville være utroligt tidskrævende og uoverskueligt, og samtidig ville der også være en hel masse spildt arbejde, idet at hvert valg jo ville gøre at hele den fravalgte "gren" kunne smides væk. Derudover ville det være meget sårbart overfor uregelmæssigheder og ting vi ikke havde forudset. Endelig ville en sådan model også være meget ufleksibel og det ville være svært at inkorporere de idéer, der ville dukke op undervejs.Vi arbejdede herefter med at skrive scenariet som en slags drejebog, der beskrev det overordnede plot og nogle underplots. Den endelige udformning blev, at vi lavede en planche for hver dag med figurerne påskrevet.

Planche

Med post-its plottede vi nogle store events eller milepæle ind som pejlemærker for hver dag. Der var fx en seddel udfor torsdag, der angav, at her skulle et band have mulighed for en tv-optræden. Derudover lavede vi en brainstorm over mulige events og ting som man kunne få med samlekort, og dette samlede vi på en anden planche. Idéen var så, at man havde de overordnede milepæle at styre efter og så efterhånden på detaljeniveau kunne dykke ned i event- og samlekortposen og stykke scenariet sammen.

Under hele processen omkring scenarieudviklingen og også udviklingen af figurerne havde vi meget glæde af den inspiration vi havde med fra vores tidligere arbejde fx workshoppen på gymnasiet, U1-testen og generelt vores arbejde med scenarier gennem hele forløbet. For eksempel brugte vi under brainstorming til events og samlekort direkte nogle af post-it'ne fra gymnasieworkshoppen og førte over som events på vores planche.

Point og Regler
Ligesom ved scenarieudviklingen udviklede vi ikke et komplet point- og regelsæt på forhånd. Vi lavede den overordnede ramme for hvordan og for hvad, der skulle gives point. Belært af U1-testen og workshoppen på gymnasiet var det vigtigt for os at lave et simpelt og enkelt pointsystem. Rammen for pointgivning var således følgende:

Point
Det skulle give point at svare rigtigt på quizspørgsmål, træffe de rigtige valg for ens karakter, aktivere rigtigt samlekort, tilføje en person til ens netværk og god udnyttelse af netværk. Man skulle ikke kunne miste point. Pointscoren var altså et udtryk for ens accumulative præstation i spillet.

Stjernestatus
Udover point syntes vi at det var vigtigt at have et barometer for ens umiddlebare berømmelse. Man skulle således kunne få stjerner i stjernestatus, hvis man fx. havde optrådt til et stort arrangement. Men samtidig skulle man også kunne miste sin stjernestatus igen. Stjernestatus skulle altså være et mål for figurens succes "lige nu".

Netværk
Udover highscore i point og stjernestatus skulle det også fremgå, hvem der havde flest personer i sit netværk. Dette ville altså være et udtryk for popularitet og for ens sociale kompetence.

Sms-central
Det var vigtigt at være i stand til at sende og modtage en stor del sms'er i løbet af test-forløbet. Det var således udelukket at sende dem fra mobiltelefon, dette ville også have været små-dyrt. Vi rettede derfor blikket mod de mange internetbaserede sms-tjenester. Her havde vi mulighed for hurtigt og nemt at sende mange sms'er og vi havde samtidig let ved at føre en log, da vi bare kunne copy-paste beskederne over i et dokument. Vi afprøvede en række af de sms-tjenester der findes på nettet - mange af dem har nemlig op til flere dages forsinkelse, hvilket ville være totalt uacceptabelt for testen. Vi fandt frem til www.coolsms.dk, der havde nogle meget fine leveringstider. Desuden var der en række features, der ville lette arbejdet, herunder bl.a. en telefonbog og en sms-log.

Screenshot

Ved modtagelse af sms'er fra brugerne kunne vi ikke komme uden om mobiltelefonen. I et rigtigt spil skulle man selvfølgelig bare kunne besvare sms'erne direkte, hvilket vi ikke havde mulighed for at simulere i denne test. Vi lod én af vores egne mobiltelefoner være svartelefon, dvs. den telefon som brugerne ville sende alle beskeder til i spillet.

Sms-koder (interaktions protokol)S
Selve interaktionen med spillet var også en vigtig del i testen. Omkring interaktionen i spillet lå en række overvejelser både i forhold til de beskeder vi skulle sende ud og den type respons vi skulle modtage fra spillerne. I forhold til beskederne fra spillet til brugerne havde vi at gøre med to forskellige slags kommunikation, dels de administrative beskeder (info og stats om point og placering) og dels de deciderede rollespils beskeder (fx "hey, dette er Agent Arne, jeg har et spændende..."). Det skulle være tydeligt for spilleren hvilke beskeder, der var info om spillet og hvilke der var en del af selve spillet. Info-beskederne skulle således være meget formelle og fx have overskriften "Info" eller underskrives med "Admin". Selve spilbeskederne skulle derimod være langt mere levende og friske, men også med en tydelig afsender fx "hey, Agent Arne her...".

I forhold til kommunikationen den anden vej fra spillerne til spillet var det vigtigt, at det var entydigt, meningsfuldt og umiddelbart klart hvordan man som bruger skulle svare. Samtidig skulle det gerne være svar som skulle kunne forstås og behandles af en server. Det bruger-interface, som man har at gøre med ved sms er i princippet en kommandoprompt, hvilket er en temmelig begrænset interaktionsform. Vi havde som sagt tidligere overvejet at lade alt respons være i form af en unik kode (fx tag til fest <fes456773> eller fx aktiver guitar <gui566234>), men for at kunne implementere flere respons- og handlemuligheder lavede vi istedet nogle forvalgskommandoer, som så skulle sammensættes med ens valg:

Ved tilføjelse af person til netværk skriv: Ven "navn"
Kæreste "navn"
Ved aktivering af samlekort skriv: Kort "kode"
Ved svar på quizspørgsmål skriv: Quizsvar "svar"
Ved valg af diverse skriv: Valg "svar"

Dette var naturligvis en meget vigtig information for brugerne. Derfor lavede vi en lille infoguide til spillet med disse og andre vigtige oplysninger.

Opsamling
Når vi kigger tilbage på forberedelsen af prototypen er planlægning naturligvis utrolig vigtig. Men samtidig var det vigtigt ikke at planlægge alt - for i bund og grund ville det være umuligt for os at forudsige forløbet fuldstændigt. Og en meget stringent planlægning ville gøre det svært at lade os inspirerer af idéer og inputs under testen, det ville være en hæmsko for at lære under processen, hvis man hele tiden kigger efter noget man har planlagt og regner med skal være der, og således overser det væsentlige som rent faktisk dukker op. Det er selvfølgelig en balancegang og i sidste ende nok meget et temperamentsspørgsmål.

Noget der også kom bag på os var, at der rent faktisk var så mange valg, der skulle træffes i forbindelse med forberedelsen af prototypen. Vi var lige pludselig tvunget til at tænke alle kroge af konceptet igennem. Dette gjorde, at vi rent faktisk blev meget mere klar over hvad vores produkt skulle kunne, og at vi fik konkretiseret en masse ting som vi indtil da havde skubbet lidt til side.