På Babelgum hittade jag en intressant kortdokumentär om datorspel och användartester för datorspel. Tyvärr går den inte att embedda vad det verkar, men här är länken i alla fall.

Psychology of Computer Games

I samband med det så tänker jag klistra in lite tankar runt speltestande här. Hämtat från djävulskattungen

Föreläsning på Futuregames Academy på fredag kommer att handla om att klippa och att testa spel. Det här är första delen av två och den tar upp klippandet.

Klipp klipp! Test, Test!
Vad gör du när du står framför ett gigantiskt monster? Ett gigantiskt monster som du själv har hjälpt till att skapa? Jag pratar inte om någon Frankensteinartad mardröm här, jag pratar om en speldesign som expanderat bortom all möjlighet att genomföra. En speldesign drabbad av feature creep.

Det är lätt hänt att man börjar expandera ett spel med alla möjliga idéer som är roliga, coola, snygga och så vidare. Då är det jätteviktigt att kunna identifiera vilka delar av spelet som är livsviktiga, och vilka delar man klarar sig utan.

Hitta visionen
När du började koncepta spelet hade du förmodligen en vision. Finns den visionen fortfarande kvar i den spelmekanik du har kommit fram till?

Varför har du valt just det här spelet och vad vill du åstadkomma? Försök sammanfatta det i en mening. Lyckas du så har du din vision. Då blir det lättare att börja klippa de ovidkommande delarna av spelet.

Om du inte lyckas sammanfatta spelet i en mening så är det dags att fundera över vad det egentligen bör handla om.

Separera spelmekaniken
Ett sätt att börja skära i materialet är att separera spelmekaniken i “bubblor”. Skriv upp alla spelmekaniska delar på post-it lappar och fäst dem på ett papper. Skriv ner din vision och placera den i mitten.

På det här viset får du en översikt över hur många olika mekaniker det finns i spelet. Det blir en visuell översikt över ditt spel.

Gå igenom alla post-it lappar. Rangordna dem utifrån visionen i mitten. De lappar som innehåller mekanik som är absolut avgörande för spelet sätter du närmast visionslappen.

Prioritera spelmekaniken
När du har din visuella översikt över spelet så kan du börja märka dem med viktighetsfaktor. Lappar nära visionen har hög viktighetsfaktor (och viktighetsfaktor är något jag har lånat ifrån Scrum – istället för att prioritera ger man varje uppgift som skall göras en viktning mellan 0 – 500. 500 betyder att det inte kan bli viktigare, medan 120 inte är så himla påträngande) och lappar långt bort har låg viktighetsfaktor. Alla lappar med en faktor under 250 kan du ta bort. Se vad som händer med spelet när du gör det.

Hitta ekonomin i spelet
I mångt och mycket handlar prioritering om att hitta rätt balans i ekonomin i spelet.

Kommer du ihåg?

• Resurser: Ex. vis ammunition, kroppspoäng, monster
• Källor: Ex. vis upphittad ammunition, medicinlådor, spawnpunkter
• Förluster: Ex. vis att avfyra vapnet, att bli träffad av en fiende, att monstret dör

Hur fungerar ekonomin i ditt spel? Går den att balansera? Är det övervikt någonstans på resurser som inte har några förluster, eller källor som spottar ur sig grejer som inte behövs?

Avslutande ord
I mångt och mycket handlar klippande om att analysera spel och att hitta de delar i spelet som är livsviktiga för att spelet skall fungera. Hittar man de bitarna så kan man också klippa bort allt annat som inte behövs, polera upp grundmekaniken och, om nödvändigt, strunta i resten av spelmekaniken. Har man kort om tid är det något man definitivt bör göra.

Ofta inom spelprojekt så prioriteras mekanik och resurser osv i tre kategorier:

• Måste ha! Utan mekaniken fungerar inte spelet
• Viktig. Mekaniken fungerar, men det är något som höjer användarupplevelsen
• Trevlig grej. Det här är mest kosmetika, en funktion eller grafik som är trevlig, men som vare sig påverkar användarupplevelsen eller spelmekaniken.

Test! Test!
Sent omsider kommer ännu ett blogginlägg baserat på en Futuregamesföreläsning, den här gången om test. Återkommer snart med en om hur man skriver regler. Den här föreläsningen baserades delvis på Microsoft Gamelabs “Do it yourself usability” från GDC 2007.

Test, test!
Speltest handlar i huvudsak om två saker:

• Att se till så att spelaren förstår vad spelet går ut på
• Att se till så att spelmekaniken/ spelet fungerar som designern har tänkt sig

Att hitta testområden
För att kunna genomföra ett bra speltest är det viktigt att identifiera de områden som du som speldesigner vill testa.

Visst går det att testa i blindo, men resultaten blir mycket bättre och mer fokuserade om du redan innan testsessionen vet vad det är du vill ha reda på.

Vad behöver spelarna göra eller förstå när de spelar det första gången?

Utifrån den frågan – och utifrån visionen som spelet har – kan man hitta en mängd features som måste framkomma när man spelar.

Definiera beteenden
Definiera vilka beteenden du förväntar dig att se när spelaren förstår eller inte förstår ett beteende. Det här hjälper till när du skall testa.

Om du vet ungefär hur en användare beter sig när de förstår eller inte förstår kan du också avgöra vilka områden i spelet som de förstår eller inte förstår.

Exempel:
Spelaren skall kunna ställa upp spelpjäserna på brädet på rätt sätt

Skapa testuppgifter
Skriv testuppgifter, små beskrivningar av vad spelaren skall göra, för att testa de beteenden du vill att spelaren skall förstå.

Exempel
“Du har precis köpt ett nytt brädspel som du tycker är intressant. Packa upp spelet och ställ upp pjäserna på brädet.”

Att observera ett test
Det är viktigt av testskäl att du som testar ditt spel inte hjälper din testperson allt för mycket med ledande frågor. Istället bör du använda “öppna” frågor som är generellt hållna och inte avslöjar för mycket om uppgiften du låter dina spelare genomföra. Exempelvis:

• Vad förväntar du dig skall hända nu?
• Kan du berätta för mig vad du tänker?
• Vad vill du åstadkoma här?
• Beskriv vilka steg du genomför.

När du uppmuntrar en spelare att tänka högt, så håll i åtanke att som testledare bör du fokusera på

• Frågorna, inte svaren
• Att utforska hur användaren tänker på ett relativt neutralt sätt
• Att fråga användarcentrerade frågor

Det finns många sätt att fånga upp data på, blanda annat kan man spela in testsessionen på band eller video, eller bara anteckna. Nedan ger jag ett exempel på hur man kan anteckna på ett strukturerat sätt.

Det här sättet att anteckna på låter dig hålla koll på:

• Deltagaren
• Uppgiften deltagaren genomför
• Det observerade beteendet och deltagarens kommentarer
• En kod för att klassificera deltagarens beteende och/ eller kommentarer. Att använda koden kan förenkla för dig när du letar efter vissa uppgifter och analyserar materialet

Intressant?

Andra bloggare om:
föreläsning, test, speldesign, futuregames