Spiltest af computerspillet Total Overdose

Transkript

1 Spiltest af computerspillet Total Overdose En komparativ analyse af spiltestmetoder

2 Forord Denne rapport omhandler test af et computerspil. Vi har tidligere beskæftiget os med usabilitytests men aldrig såkaldte playtest. Projektet har derfor et gennemgående pragmatisk præg, idet mange af teorierne er nye for os, og vi må derfor afprøve dem i praksis for at kunne foretage fornuftige udtalelser. Man taler ofte om learning by doing, i vores tilfælde beskriver learning by reflecting over doing mere præcist den proces vi har gennemgået. Vi vil gerne rette en tak til Deadline Games for at producere et spil som var interessant at benytte som analyseobjekt. En tak går også til Studienævnet, fordi de imødekom vores ansøgning om støtte til erhvervelse af ovennævnte spil. Slutteligt en stor tak til vores vejleder Lasse Winther Wehner, som har hjulpet os meget med indsamling af teoretisk materiale. 1

3 FORORD...0 INDLEDNING...9 Problemfor mulering...10 METODE...11 METODE...13 TEORIPLAYABILITY...15 PLAYABILITY...17 Gameplay...17 Spillets historie...18 Spillets mekanikker...18 Usability...18 HEURISTISK EVALUERING...21 HEURISTIC EVALUATION FOR PLAYABILITY...23 TÆNKE HØJT TEST...25 Udarbejdelse af opgaver...25 Evaluering af testresultater...26 PLAYTESTING...27 Valg af testdeltagere...27 Forberedelse af playtesting miljø...28 Under playtesten...28 Feedback...29 GESTALTTEORI...31 Hvad er gestalt

4 Gestaltlovene...31 Nærhedsloven...31 Lighedsloven...32 Lukkethedsloven...33 Symmetriloven...33 Retningsloven...34 Figur grund fænomenet...34 Opsummering...36 ANALYSE...37 PRAKTISK UDFØRELSE AF HEURISTISK EVALUERING...39 Præsentation af eksperterne...39 Praktisk udførelse...39 Fejlkilder...39 PRAKTISK UDFØRELSE AF TÆNKE HØJT TESTEN...41 Opgaver...41 Valg af testpersonerne...42 Valg af testmiljø...42 HEURISTISK EVALUERING...45 Gameplay...45 Spillets historie...48 Spillets mekanikker...49 Usability...51 TÆNKE HØJT TESTEN...54 Første mission The father...54 Anden mission The good son...54 Tutorial...56 Tredje mission The bad son

5 Fjerde mission Steal the Weels...58 Play Matrix...58 IDENTIFIKATION AF GESTALTLOVE...62 OPSUMMERING...64 DISKUSSION & REFLEKSION...66 Gameplay...68 Heuristic Evaluation for Playability...68 Tænke højt...69 Spillets historie...69 Heuristic Evaluation for Playability...70 Tænke højt...71 Spillets Mekanikker...71 Heuristic Evaluation for Playability...72 Tænke højt...72 Usability...72 Heuristic Evaluation for Playability...73 Tænke højt...74 KONKLUSION...78 LITTERATURLISTE...82 Bøger...82 Tidsskrifter...82 Artikler...82 Websites...82 Spil...83 Bilag 1 Tænke højt empiri...84 Kim...84 Lene...85 Kristian...85 Line...86 Bilag 2 HEP heuristikker...88 Bilag 3 HEP empiri...89 Bilag 4 Spørgsmål...92 Bilag 5 Ansvarsliste...94 Bilag 6 Om Total Overdose...95 Beskrivelse af analyseobjektet...95 Bilag 7 De fire spillertyper

6 5

7 6

8

9

10 Indledning Computere bruges i dag til en række af forskellige gøremål. Et af disse gøremål er at spille computerspil på enten en PC eller på en spillekonsol. Antallet af danskere der har adgang til en computer med Internet ligger i 2005 på 84% ifølge dansk statestik 1. Hvis man sammenholder dette tal med, det faktum, at der på de fleste PCere bliver spillet computerspil af den ene eller anden form, er der tale om en stor del af den danske befolkning der bruger deres PC til spil. Computerspilgenren kan være alt fra 7 kabale over online spil som pakkeleg på DRs hjemmeside, til spil Half life 2, og det er spil som førnævnte at befolkningen bruger deres computere og konsoller på. Vi har i forbindelse med vores tidligere studier på Naturvidenskabelig Informatik, beskæftiget os med usability i forbindelse med udvikling af programmel og efterfølgende test. Derfor kunne det være et interessant projekt at teste et spil for usability og andre aspekter. Disse aspekter er interessante for os, da vi aldrig har lavet en spiltest før, og en stor del af vores undren ligger også heri. Spilindustrien i Danmark er på vej frem 2, og de danske spilproducenter ønsker at gøre sig gældende indenfor blandt andet ovennævnte spilgenre. Derfor mener vi at det kunne være interessant, at spilteste et dansk spil, da vi begge har en interesse for de danske computerspil. Vi har valgt det dansk producerede spil Total Overdose, som bliver introduceret i bilag 6. Et eksempel på vores undren er, at en normalt udformet opgave i en usabilitytest af en hjemmeside, ofte er udformet med henblik på at finde informationer. Men et computerspil har ofte dets egne opgaver, der skal løses, og kompleksiteten i forbindelse med opgaveløsningen er ikke altid, i modsætning til hjemmesiden, rettet mod de kriterier, som blandt andre Jacob Nielsen og Rolf Molich beskriver. Kriterierne er at holde kompleksiteten på et minimum, således at førstegangs brugere, såvel som de erfarne brugere, kan navigerer rundt i produktet. Det vil sige at et computerspil gerne må indeholde elementer, der kræver en anstrengelse fra spillerens side, fordi denne ville forvente dette, for at spillet er tilfredsstillende, i modsætning til hjemmesiden. Med ovenstående i mente, er vi kommet frem til en konkretisering af vores undren, som giver følgende problemformulering:

11 Problemformulering En traditionel usabilitytest kan bruges til at finde ud af, om for eksempel et tekstbehandlingsprogram eller en hjemmeside er opbygget optimalt, men når man tester et computerspil, er der antageligt områder af spillet som klassiske usabilitytests ikke dækker. Med udgangspunkt i dette har vi opstillet følgende, der skal præcisere vores problem: Hvilke områder er relevante når man beskæftiger sig med spiltest, og hvordan kan man teste disse? Herunder vil vi foretage to tests med henblik på en komparativ analyse af de udvalgte testmetoder. Formålet med testene er ikke, at vurdere spillets kvalitet, men en del af en proces, hvor målet er at komme med et kvalitativt svar på vores problemformulering. 10

12 Metode 11

13

14 Metode Dette afsnit har til formål at beskrive de overvejelser, vi har gjort os i forhold til valg af teorier. Vi har bestræbt os på at udvælge teorier, som ville hjælpe os med at komme med et kvalitativt svar på vores problemformulering. Vores problemformulering lægger op til, at vi på en eller anden måde skal foretage test af et spil. Da vi tidligere har beskæftiget os med usabilitytest af hjemmesider, både i form af tænke højt tests samt heuristisk evaluering, var det nærliggende for os at vælge disse to testmetoder. Formålet med at vælge to testmetoder, er at vi afslutningsvis vil foretage en sammenligning af disse to testmetoder, baseret på de resultater de har givet gennem analysen. Vi vil tage udgangspunkt i de standardiserede fremgangsmåder, men for at benytte disse to testmetoder optimalt i forbindelse med spiltest, har vi ligeledes set på, hvordan andre mener, at disse testmetoder kan bruges. Den heuristiske evaluering tager udgangspunkt i en testmetode kaldet Heuristic Evaluation for Playability (herefter HEP)[Desurvire et al]. Denne metode tager udgangspunkt i fire områder: gameplay, spillets historie, spillets mekanikker og usability. Disse fire kerneområder dækker de aspekter af et spil, som vores tests vil beskæftige sig med. Vi vil desuden inkludere andre teorier om spiltests, i forhold til en præcisering af disse kerneområder. Efter den heuristiske inspektion vil det være muligt for os, at sige noget konkret om hvert af de fire områder, hvilket vil give os et generelt indtryk af spillets playability. Eksperterne i denne inspektion vil være os selv, da det ikke lykkedes os at få udviklerne af spillet til at foretage denne test. Vi mener at havde et udmærket udgangspunkt, da vi har gennemspillet spillet flere gange. Vi opfatter ligeledes os selv som værende målgruppen for spillet, og har begge en stor interesse for computerspil. Vi mener ligeledes at have erhvervet den fornødne viden, gennem de erfaringer vi har gjort os i forbindelse med indsamlingen af teori til dette projekt. Vores tænke højt test baseres på de principper, der beskrives i teorierne om playtesting [Hoffman, et al]. Playtesting er en samling af retningslinier for opstilling af spiltest. Disse retningslinier har til formål at fremme brugernes deltagelse under testen. Testen bliver foretaget af fire personer, som alle er familiære med den platform, hvorpå spillet skal testes. På den måde sikrer vi os, at brugerne 13

15 ikke tester platformen men spillet. Tænke højt testen vil give os et sammenligningsgrundlag, som vi kan benytte i vores sammenlignende analyse. I forbindelse med disse tests af spillet, vil vi ligeledes undersøge hvordan de retningslinier for grafisk design, der er beskrevet i gestaltlovene, kommer til udtryk. Vi vil påpege problemer, hvor gestaltlovene kan benyttes som udgangspunkt for et løsningsforlag, og ligeledes fremdrage momenter hvor der er gjort fornuftig brug af gestaltlovene. Der findes en mindre problematik ved at bruge disse testmetoder på et færdigudviklet spil. Både playtesting og HEP er metoder, som fortrinsvis er blevet brugt fortløbende i spilproduktioner, hvor begge testmetoder gentages for hver iteration i udviklingsforløbet. Vi mener dog vores metoder har deres berettigelse, da man ikke reelt kan snakke om et færdigt spil, men blot den iteration af spillet, som vurderes mest fejlfri. Skulle det ske at det spil, vi benytter som analyseobjekt, viser at være fejlfrit vil det naturligvis afspejle sig i vores test og efterfølgende analyse. Efter denne redegørelse vil vi i næste kapitel beskrive den teori, vi har introduceret i metoden. 14

16 Teori 15

17 16

18 Playability Når man snakker computerspil, taler man ofte om et spils playability. Dette begreb er fokus for en mængde diskussioner. Mange spildesignere og forskere har forskellige definitioner på playability. Nogle mener at det drejer sig om, at et computerspil skal være sjovt, vanedannende og let at lære men svært at mestre. Andre spiludviklere mener at playability er en udefinerbar størrelse, som alle forsøger at forstå 3. Når der hersker så stor uenighed om hvad playability egentligt er, findes der ikke nogen god opskrift på hvordan man laver gode computerspil. Derfor er det nødvendigt at foretage spiltests, for at sikre spillet er interessant for spillerne. Man kan diskutere hvad man skal teste, når man ikke har en konkret definition på det man vil undersøge. I følgende afsnit vil vi derfor fremsætte vores definition af playability, med udgangspunkt i HEP. Vi lige ledes nævne andre definitioner, for at vise forskellige synspunkter. Aarseth arbejder med tre områder indenfor spilanalyse, gameplay, game rules og game world. Det er disse tre områder, som man ifølge Aarseth bør fokuserer på i en spilanalyse 4. HEP omtaler fire områder, der tilsammen udgør definitionen af playability. Vi har på samme måde som HEP valgt at arbejder med fire kerneområder: Gameplay, spillets historie, spillets mekanikker og usability. Vi vil i følgende afsnit beskrive disse nærmere. Gameplay Aarseth beskriver gameplay som det en spiller gør i et spil. Herunder også de strategier og motiver en spiller gør brug af i forbindelse med spillet. Konzack beskriver gameplay ud fra ludologien, hvor der arbejdes med otte underområder 5 : Positioner som beskriver de synsvinkler, hvorfra et spil kan betragtes: det kan være fra en spillers synspunkt eller på andre tidspunkter fra en testleders synspunkt. Ressourcer beskriver de ting som en spiller kan bruge til at påvirke et spil med. I computerspil er det oftest en grafisk repræsentation. Rum omhandler både spillets virtuelle rum, men også det virkelige rum, hvorfra det virtuelle rum påvirkes. Tid beskriver spillets varighed. Nogle spil slutter når spillet er gennemført, andre spil slutter når en forudbestemt tidsmængde er udløbet

19 Mål(delmål) er det der kræves for at vinde spillet. Delmål er vejen til målet. Forhindringer er det som gør et spil udfordrende. Forhindringer skal overkommes for at nå målet(delmål). Viden er den information som er tilgængelig i spillet. Herunder findes blandt andet regler, statistik og andre spilleres strategi. Belønning/straf er elementer som point, penge, tid og ressourcer som en spiller kan vinde eller tabe i løbet af et spil. En mere generel definition af gameplay er, måden hvorpå spillet spilles. Vi har valgt at tage udgangspunkt i gameplaydefinitionen, som Desurvire beskriver i HEP. Gameplay defineres som de problemer og udfordringer, en spiller skal overkomme for at vinde et spil. Spillets historie Der har i lang tid været diskussion om hvorvidt spil er historier. Vi vil ikke diskutere dette her, men blot påpege at spil kan fungere uden historier, men når kompleksiteten og valgmulighederne i et spil stiger, kan historier bruges til at give disse valgmuligheder mening. Vi definerer spillets historie som spilkarakterens udvikling, udviklingen af historiens plot samt de valg spilleren bliver konfronteret med i spillet. Spillets mekanikker Det samlede sæt af mekanikker som et spil indeholder, beskriver hvordan en spiller kan spille et spil. På den måde kan man opfatte spillets mekanikker som et regelsæt for interaktion. Derfor definerer vi spillets mekanikker som spillets regler for interaktion med spillets elementer herunder også spillets styring og spillets AI. Usability Aarseth er ikke omkring dette område, men vi mener at det er et vigtigt, da det omfatter spillets interface og hvordan instruktioner og informationer formidles til spilleren. Under dette område indbefattes også de enheder som spilleren bruger til at interagere med spillet (mus, tastatur, gamepad med flere). 18

20 Definition af disse fire kerneområder giver et indtryk af de tanker, som vi har gjort os om playability, samt de definitioner vi arbejder ud fra. Disse definitioner kan med fordel bruges, når vi foretager vores sammenlignende analyse, da vi dermed kan få et indtryk af, hvilke områder af playability de to testmetoder undersøge bedst. Nu da vores definition af playability er fastlagt, vil vi i næste kapitel beskrive teorierne om testmetoderne heuristisk evaluering og tænke højt. Disse beskrives inden vi introducerer HEP og playtesting, for at forklare de grundlæggende tanker bag testmetoderne. 19

21 20

22 Heuristisk Evaluering HEP beskriver en række metoder til gennemførsel af den heuristiske evaluering. Den opsætter ligeledes de heuristikker, der kan benyttes. Vi vil dog i dette afsnit alligevel beskrive de grundlæggende idéer om heuristisk evaluering, med henblik på at forklare vores fremgangsmåde i den praktiske udførelse af testen. Heuristisk evaluering er en metode kreeret af Rolf Molich og Jakob Nielsen. En heuristisk evaluering udføres af en række eksperter, der på egen hånd gennemgår en brugergrænseflade. Formålet med gennemgangen er at verificerer at en række heuristikker overholdes. Molich og Nielsen har opsat heuristikker som knytter sig til test af brugergrænseflader. Vi har af åbenlyse årsager valgt at benytte heuristikkerne opsat i HEP 6. Hver eksperter gennemgår brugergrænsefladen, helst to gange, dog maksimalt i to timer, og vurderer hvorvidt heuristikkerne overholdes. Eksperterne skal, når de finder en uoverensstemmelse med heuristikkerne, beskrive problemet og ligeledes formulere en løsning på problemet. Når alle eksperterne er færdige med deres respektive gennemgang, mødes de med en observatør 7. Denne observatør har til formål, i fællesskab med eksperterne, at udarbejde en oversigt over fejl og tilhørende løsningsforslag. Nielsen påpeger at antallet af eksperter bør være tre til fire. Dette tal har Nielsen analyseret sig frem til gennem utallige heuristiske evalueringer. I Figur 1 8 ses en oversigt over antallet af eksperter, og hvor stor procentdel af fejl, de vil finde under en evaluering. 6 Bilag

23 Figur 1 Ud fra figuren er det tydeligt, at flere eksperter, vil finde proportionelt flere fejl. Nielsens har desuden vurderet antallet af anbefalede eksperter ud fra et cost benefit synspunkt, illustreret i Figur 2. Figur 2 Resultaterne fra en heuristisk evaluering er en liste over problemer og løsningsforslag baseret på de heuristikker, der er overtrådt. Det er ikke altid at løsningsforslagene er systematiske, i forhold til en efterfølgende implementering. Derfor anbefaler Nielsen, at man efter endt test afholder en debriefing 9, hvor både eksperter, observatøren samt udviklere deltager. Sammen kigger de på de fundne problemer, og finder i fællesskab ud af, hvordan rettelser kan implementeres på den bedste måde. Fordelen ved at bruge heuristisk evaluering, er at testen kan benyttes ofte og nemt i alle iterationer i en udviklingsproces. Brugertest kræver derimod længere planlæggelse og forarbejde

24 Heuristic Evaluation for Playability HEP er en samling af heuristikker, som benyttes til at foretage heuristiske evalueringer af computerspil. HEP er baseret på teorier om brugen af heuristikker i forhold til bræt, video og computerspil. Normalt benyttes heuristiske evalueringer i forbindelse med undersøgelser af brugergrænsefladers brugervenlighed. Brugergrænseflader i opgaveorienteret programmel designes med henblik på effektivitet, let at lære og let at bruge. Computerspil derimod skal forsøge at være lette at lære, men svære at mestre[federoff]. Derfor må man, når et spil undersøges, gå længere end blot at kigge på brugergrænsefladen, men også kigge på ting som gameplay, spillets historie og spillets mekanikker. Under HEP defineres disse tre ting følgende: Gameplay er den samling af problemer og udfordringer en spiller skal overkomme, for at vinde spillet. Spillets historie; hentyder til plot og karakterudvikling i spillet. Spillets mekanikker; er den struktur hvori spilleren interagere med spilverdenen[desurvire, et al]. Udviklerne af HEP påpeger at usability også er del af den heuristiske inspektion, og definerer det som værende de elementer brugeren bruger til at interagere med spillet, herunder gamepad, tastatur, mus etc. Ud fra disse definitioner, opsattes en række heuristikker, som skulle undersøge hvert af de fire områder. I bilag 2 ses den samlede opstilling af heuristikker. Forfatterne til HEP benyttede fortrinsvis deres metode i de tidlige stadier af et spiludviklingsforløb. Der blev skabt en model af spillets interface i Macromedia Flash med begrænset gameplay. En playability ekspert gennemgik derefter heuristikkerne med henblik på at afgøre, hvorvidt hver enkel heuristik blev overholdt eller ej. Ligeledes var det denne persons opgave, at definere de playability problemer der var, når de respektive heuristikker ej blev overholdt. Efter gennemgangen var det så optil til playabilty eksperten og spiludviklerne, at definere alternative løsninger til de playability problemer der måtte findes[desurvire, et al]. På trods af at HEP benyttes i de tidlige faser af spiludvikling, påpeges der dog at HEP med fordel kan benyttes på senere stadier samt efter spillets udgivelse. Man skal dog blot være opmærksom på, at brugen af HEP på forskellige stadier, resulterer i forskelligt fokus. For eksempel vil man på de tidlige stadier finde flest problemer i spillets historie og spillets usability, når man benytter HEP. 23

25 Ligeledes vil brugen af HEP på senere stadier give resultater, som i større grad knyttes til gameplay og spillets mekanikker. Vi vil i vores heuristiske evaluering benytte alle heuristikkerne, som de er beskrevet under HEP. Vi vil i forbindelse med den sammenlignende analyse, påpege heuristikker som vi fandt overflødige eller problematiske at verificere. 24

26 Tænke højt test Når et spil bliver udviklet, forsøger spiludviklerne at opmærksomme på de mindste detaljer, men der vil altid være uforudsete fejl, som udviklerne har overset. Der findes forskellige metoder til fejlfinding, den mest almindelige er brugertests, og et godt redskab i forbindelse med en brugertest er en tænke højt test. En tænke højt test kan med fordel bruges i både den tidlige designfase, såvel som på et allerede eksisterende produkt 10. Formålet med en tænke højt test i forbindelse med en playtest, er at få afklaret graden af usability, playability og om brugerne kan lide den valgte grænseflade. Desuden kan tænke højt testen hjælpe med at afsløre om spillet indeholder kritiske fejl. Testdeltagerne får stillet nogle foruddefinerede opgaver, som de skal prøve at løse.. Testdeltagerne der anvendes i testen, skal under optimale vilkår være eksisterende brugere af produktet, eller også skal de repræsenterer målgruppen. Dette vil give udviklerne relevant feedback til en analyse. Testen udføres typisk af fire til seks personer 11. Anvendes der flere personer end dette, forbedrer det ikke testens resultater væsentligt, der bliver blot mere evalueringsarbejde til udviklerne. Anvendes der derimod færre testdeltagere end de fire, stiger risikoen for større usikkerhed i testresultaterne. Udarbejdelse af opgaver Inden testen foretages, er det vigtigt at specificere, hvad det er man gerne vil have testet. Derfor er det godt at involvere udviklerne af systemet, da de i forvejen har en god ide om, hvor eventuelle problemer med produktet befinder sig. Når opgaverne udformes, er det vigtigt at spørgsmålene er formuleret i et tydeligt sprog, således at testdeltagerne ikke er i tvivl om, hvornår den stillede opgave er slut. Selve testen må helst ikke vare over en time, da det efter denne tidsgrænse bliver sværere at fastholde testdeltagernes koncentration. Det er vigtigt at udforme opgaverne sådan, at der findes både svære og lette opgaver. Det er ofte en god ide at starte med en let opgave så testdeltagerne starter med en succesoplevelse, som kan motivere dem yderligere i testen[molich] test.html 11 test.html 25

27 Det er vigtigt, at stedet hvor testen bliver udført, er aflukket fra forstyrrende elementer, og samtidig skal dette sted fremstå hyggeligt, således at testdeltagerne kan få en følelse af tryghed. Dertil hjælper det også at gøre testdeltagerne opmærksomme på at det er en test af produktet, og ikke af dem. Evaluering af testresultater Når testen er afsluttet, og resultaterne skal analyseres, deles de fundne fejl op i typer, og i hvor mange der har fundet den samme fejl. Fejlene kategoriseres efter en skala, som er med til at belyse fejlenes alvor[molich]. Kritisk problem; giver anledning til hyppige katastrofer; bør rettes inden systemet sættes i drift. Denne kategori er reserveret de få problemer, som har en alvorsgrad, der er så høj at brugerne er bedre tjent med at få udskudt leveringen af systemet. Alvorligt problem; giver lejlighedsvis anledning til katastrofer; bør rettes i næste iteration af systemet. Kosmetisk problem; kan rettes ved lejlighed Efterfølgende rettes først de kritiske problemer, efterfulgt af de alvorlige og til sidst de kosmetiske. Gennemgangen af heuristisk evaluering og tænke højt har givet os en forståelse af, hvordan disse to testmetoder grundlæggende opbygges. Retningslinierne vil indgå i vores overvejelser omkring den praktiske udførelse af testene. Vi vil i det næste afsnit introducere HEP og playtesting. 26

28 Playtesting I dette afsnit vil vi først forklare de forskellige kategorier indenfor playtesting. Derefter vil vi redegøre for valg af testdeltagere, og det ideelle playtestingmiljø vil blive beskrevet. Efterfølgende gennemgås de værktøjer til fremme af brugerdeltagelse, som testlederen har til sin rådighed under selve playtesten. Afsnittet afsluttes med en guide, til hvordan testlederen skal gebærde sig under testen, og hvad der kan gøres for at optimere empirien. Playtesting er en nødvendig del af et spils udvikling. Delmål skal opfyldes, og kriterier skal overholdes for at ende med et spil, der kan begå sig på et marked, der konstant er i udvikling. Der er forskellige måder at lave playtesting på, og overordnet set kan de deles op i to kategorier [Hoffman et al]. Den ene kategori er de uformelle tests, som giver et kvalitativt bud på hvad brugerne mener om spillets styrker og svagheder. Denne type foregår for det meste ved, at testdeltagerne sidder i samme rum og spiller spillet igennem i deres eget tempo, og testlederne spørger ind til, hvad testdeltagerne får ud af spiloplevelsen. Den anden kategori er de tests, der giver kvantitativ empiri, og som foregår under strukturerede forhold. Denne type af playtesting har ofte en masse specifikke opgaver, der skal løses på en stringent måde, hvilket giver spiludviklerne et billede af nogle helt specifikke elementer. Valg af testdeltagere Når den første prototype af et spil er færdigt er det vigtigt at få det testet af nogle testdeltagere. Disse må gerne være personer spiludvikleren kender, fordi det i denne fase handler om at få et par friske øjne på spillet 12, som kan være med til at give den første feedback, og når spillet ikke er færdigt, er det billigere for udvikleren at bruge venner og kollegaer som testdeltagere. Senere i forløbet er det klogt at teste spillet ved hjælp af testdeltagere, der ikke har relationer til udviklerne, da disse relationer kan være til hindring for at få et præcist billede af, hvad der kan være galt med spillet. Det er de testdeltageres subjektive følelser for udvikleren, der kan overtage, når de bliver bedt om at teste spillet. De kan enten være for overbærende, eller for kritiske i forhold til de fejl de finder, og dermed er objektiviteten ikke i centrum når spillet skal testes[hoffman et al]. Den

29 ideelle testdeltager er en der ikke har relationer til udvikleren, er åben, snaksaglig og i stand til at formulere sine observationer videre til intervieweren. Forberedelse af playtesting miljø Metoden foreskriver at en playtest bliver udført i klassiske usabilityfaciliteter, der har mulighed for overblik over skærm og testdeltager. Testdeltageren skal tænke højt, og der skal tages notater. Metoden anbefaler også, at det er en god ide at have snacks og drikkevare tilstede under testen, da en skænk kan motivere spiltesterne til at give detaljeret feedback, da de føler, at de skylder det, når de får gratis mad. Metoden beskriver, hvordan det er god kutyme at gennemføre playtesten med én testdeltager af gangen. Ifølge Hoffman er det en almen accepteret regel, at gruppedynamik er god til at få ideer, men dårlig til at evaluere ideer. Han påpeger dog, at det stadig er muligt at playteste, selvom man ikke har de optimale forudsætninger[hoffman et al]. Under playtesten Hoffman opstiller nogle punkter for, hvordan det er muligt at strukturere et testforløb under forskellige scenarier: En til en test Hvor testlederen kigger testdeltageren over skulderen og stiller spørgsmål og tager notater. Gruppetest En gruppe mennesker sidder sammen og spiller, imens testlederen observerer og stiller spørgsmål. Feedback formularer Hver testdeltager får et spørgeskema, hvor de skal svare på en række spørgsmål. Interview En testleder snakker med testdeltageren om oplevelsen efter testen. Der er ikke tale om en diskussion, men mere en afhøring, hvor testlederen stiller spørgsmål til testdeltagerne. Åben diskussion Der er en række muligheder for hvordan denne diskussion kan foregå. Enten mellem to eller flere og diskussionen kan være helt fri, eller struktureret efter en dagsorden [Hoffman et al]. 28

30 Ét playtestingforløb kan gøre brug af flere af ovenstående punkter. Feedback Det er vigtigt at stille de rigtige spørgsmål til testdeltagerne, og der er aldrig et rigtigt eller et forkert svar på et spørgsmål. De bedste spørgsmål er dem, der åbner op for en diskussion og leder til nye og interessante ideer fra testdeltagerens side. Hoffman præsenterer derfor The Play matrix, illustreret på Figur 3, hvori fire punkter bliver stillet op overfor hinanden. Punkterne er evner, held, mental kalkulation og adræthed. Figur 3 The Play matrix er et værktøj, der kan bruges under eller efter playtesten. Den kan bruges i diskussioner hvor testlederen spørger indtil, hvor spil, som testdeltageren normalt ville spille, ligger. Testdeltageren bedømmer så ud fra de fire punkter, hvor han/hun ville placere spillet. Hvis testdeltageren ikke kan lide spillet, så er der en stor sandsynlighed for at denne vil placerer spillet sammen med andre spil, som testdeltageren ikke bryder sig om. Et par eksempler beskriver bedst play matrixen opbygning. For eksempel er skak placeret oppe i venstre hjørne, fordi det at være god til at spille skak, kræver at man kan tænke flere træk frem, og vide hvilke træk der er fornuftige. En leg som tagfat er placeret nede i højre hjørne, fordi den kræver, at man bevæger sig meget, og at man er heldig, hvis man får fat på en af de andre. Fodbold er placeret nede i venstre hjørne da det kræver både evner og adræthed for at være god. I øverste 29

31 højre hjørne kan placeres spil som Blackjack, der kræver at spilleren er heldig med kortene, og at spilleren kan kalkulere med, hvad der mon gemmer sig i bunken og hvad der allerede er spillet. Hoffman har lavet et fyldigt eksempel med computerspil og lege i en play matrix som ses i Figur 4. Figur 4 Det er vigtigt for testlederen, hvis denne har været med til at lave det testede spil, at holde sig neutral overfor kritik i feedbacken. Specielt fordi mange har problemer med at tage kritik, som konstruktivt input, og derfor vælger at ignorere kritikken 13. Derudover er det vigtigt at skrive alt ned, eller få det optaget på kamera, da man generelt kun husker de ting, som man forinden havde forventet eller håbet, at spiltesterne ville finde[hoffman et al]. Gennemgangen af playtesting, har givet os en række metodiske retningslinier, som vi vil benytte til udformningen af vores tænke højt test. Dette vil sikre, at vi får optimeret vores brugerdeltagelse og derigennem vores testresultater. Den præcise udførelse af tænke højt testen, bliver beskrevet på side