Jag har i dagarna satt samman en serie om tre föreläsningar om speltest, som jag kallar Playability 101. Föreläsningen bygger i mångt och mycket på Tracy Fullertons Game Design Workshop och på en usabilityworkshop jag var på på GDC 2007.

Playability övningar del 1.

Föreläsningen handlar om de olika typer av tester som ett spel kan gå igenom, deras fördelar och nackdelar, men även vilka tester som används i vilka sammanhang och varför, samt så klart även hur man genomför sina egna tester på spel. De här testmetoderna funkar både på analoga och digitala spel.

Vi kan börja med att reda ut begreppen. Det finns många olika typer av test som ett spel kan genomgå, och det är viktigt att ha klart för sig vad de olika testernas syften är, inte minst för att undvika missförstånd.

Internal design review – (eller som vi brukar säga “har du kört igenom den senaste builden än?”) handlar om intern testning som vanligtvis är relativt informell. Det finns företag som tar den här typen av test mycket allvarligt och det finns också de som gör det mer slentrianmässigt. På Avalanche körde vi genomgångar av speldesign och spelmekanik på sprint reviews som visade sig vara utmärkta tillfällen att gå igenom och revidera vår design. Det det handlar om är alltså en intern process där teamet och kanske eventuellt higher-ups går igenom speldesign och spelmekanik för att bekräfta att designen/ mekaniken håller.

Quality assurance testing – eller QA handlar om att i högre grad buggtesta och funktionalitetstesta spelet. Vanligtvis slinker det med en del playtesting här också, men det är inte det som är syftet med QA. Syftet med QA är att kunna sätta en “okejstämpel” på spelet så att det kan skeppas till de väntande massorna.

Focus group testing – handlar nästan uteslutande om marknadsföring. Det är när man tar spelet till den tänkta marknaden och låter dem berätta hur mycket de kan tänka sig att betala för spelet och om det är ett spel de kan tänka sig att spela.

Usability testing – tangerar playtesting en smula, men det handlar i högre grad om gränssnittets effektivitet och förmedlingsförmåga än något annat. Det är ett område som rör sig mer runt “skalet” på spelet än själva spelet.

Playtesting då – till sist – handlar om att testa spelets grundläggande mekanik, hur väl spelet är balanserat, svårighetsgrader och kontrolluppsättningar. Det är att kontrollera, genom test, att spelet lever upp till sitt syfte. I Silent Hill är syftet att berätta en skräckhistoria med spelaren. I Lumines handlar det om att göra ett underhållande och beroendeframkallande pusselspel (som man kan dansa till) och så vidare.


Vilka områden och testmetoder går föreläsningarna in på? Till viss del handlar det om internal design review, vilket jag hoppas kommer mer eller mindre automatiskt redan i brainstormingstadiet. Internal design review är dock inget jag kommer att gå igenom.

Det handlar också delvis om Quality Assurance. När man testar kan det dyka upp buggar. De buggarna bör man ha med sig om man skall revidera spelet, särskilt om det handlar om showstoppers, men det är inte huvudsyftet med testprojektet.

Usabilitytesting behöver man också ha i bakhuvudet, eftersom gränssnittet är det “skal” som spelaren måste interagera med för att kunna spela spelet. Om det området brister så finns det risk att det ger spelaren en negativ upplevelse, men det är heller inte usabilitytesting som här huvudfokus för spelprojekt. Huvudfokus är playtesting, det vill säga att testa spelidé, spelarkitektur, balans och mekanik, så att man får en god uppfattning om vad som är bra i spelen och vad som är mindre bra och behöver förbättras, ändras eller tas bort.

Varför är just de här områdena så viktiga för spelutvecklare? Jo, för att man oundvikligen kommer att komma i kontakt med dem och lär behöva lära sig hur man hanterar dem. Det är näst intill oundvikligt att i produktion inte behöva använda sig av QA, playtest eller usabilitytest. Ibland är de ihopbakade – som här – och på andra företag är de helt åtskilda. Det beror helt på hur företaget sköter sitt testande.

Skillnaden mellan playability och usability är på ytan ganska stor. Där spelbarhet handlar om att se till att spelaren får roligt, är usability mer angelägen om att skapa ett effektivt gränssnitt. Där playability handlar om att ge spelaren precis rätt utmaning handlar usability om att skapa en så lättlärd och lättanvänd upplevelse som möjligt.

Hur hänger usability och spelbarhet ihop då? På fler plan än man kanske kan tro vid första anblick. Jag tänker dessutom ge er fyra stora anledningar till varför speltest är den viktigaste delen i spelutvecklingsprocessen på köpet.

Ett – för att spelaren skall kunna ha roligt med ditt spel måste hon förstå hur det “funkar”. Det måste finnas ett grundläggande, kul, flöde i spelmekaniken för att spelet skall nå fram till sin publik. Speltest hjälper designers att uppnå det här flödet utan “specialistkunskaper”. Bygger man spel blir man mycket skicklig på att ta sig förbi buggar, använda specialkombos och så vidare. För en vanlig spelare hindrar den här sortens specialare flödet och funktionsdugligheten i spelet.

Två – För att etablera en hållbar svårighetskurva. Du är expert på ditt spel efter många, många timmars spelande. Du har helt enkelt inte distans till och en uppfattning om hur svårt eller lätt spelet är. Därför behöver du extern hjälp som kan ge dig en uppfattning om det.

Tre – För att minska fel sorts frustration. När spelaren blir förbannad på kontrollerna för att kontrollerna är för komplicerade eller ointuitiva att hantera, eller om spelaren fastnar i ett pussel för att pusslet är omöjligt att lösa utan förkunskaper så är det fel sorts frustration. Frustrationen – och viljan att lösa ett problem – skall uppstå som en del av spelet, inte på grund av att spelet har oförståeliga kontroller eller beter sig ologiskt. Det finns vissa spel som använder sig av jobbiga kontroller med avsikt, men min personliga åsikt är att om man måste använda kontrollerna som ett sätt att uppnå en viss känsla, det vill säga att kontrollernas dåliga styrsel orsakar stressmomentet, så har man misslyckats eftersom det inte är spelet som skapar känslan utna bristen på kontroll över spelet.

Fyra – för att göra ett roligt spel som är roligt för fler än utvecklarna. Som jag redan påpekat är det många utvecklare (mig inbegripen) som gör spel som antingen är så kluriga, svåra eller oförståeliga att de blir svåra för genomsnittspelaren att spela. Gör du spelen för dig sjölv eller för en publik?

Hur identifierar man vad som skall testas? Dels beror det på spelets syfte (återkommer till det), men det handlar också om vart i processen du är. Om du jobbar med konceptframtagande och grundläggande design är det de allra mest fundamentala områdena, som spelmekanik, som testas. Det här är viktigt! Så fort det finns en prototyp kan den börja testas. Vanligtvis brukar argumentet “men den är ju så ful och ofärdig” dyka upp. Det är mycket möjligt, men då väljer man en testpublik som förstår att det enbart är en prototyp. Testa med pappersprototyper och med en gång. Testprocessen är ett ovärderligt verktyg, även om det är omständigt och jobbigt till en början. Det betalar sig i slutändan.

Finns det en prototyp som har de grundläggande funktionaliteterna på plats kan man börja testa i mindre grupper och med förtrogna, som till exempel familj, kompisar eller avdelningen bredvid. Ju närmare färdigstadiet man kommer, desto mer “främlingar” och utomstående testgrupper kan man ta in. När det är dags för polering och balansering är det enbart externa testgrupper som ger den nyttigaste informationen och då handlar det också förhoppningsvis bara om finlir.

Vad kan man testa och vad skall man testa? Det beror lite på vilken utgångspunkt man har. Utgångspunkten bör dock alltid vara – ur ett övergripande perspektiv – om spelet uppfyller sitt syfte. Det är därför också viktigt att ha koll på vad spelets syfte är, men det är ett ämne för en annan föreläsning.

När man testar ur usabilitysynvinkel så tittar man på hur lärbart gränssnittet är. Lärbarhet handlar om att vara konsekvent i placering av interaktionsobjekt, det handlar om att inte göra för djupa hierarkier i menuer men i första hand handlar det om hur lätt det är för en användare att göra grundläggande uppgifter första gången de kommer i kontakt med systemet.

Det handlar också om effektivitet, det vill säga hur fort en användare kan använda systemet när han redan har kännedom om det, det handlar om hågkomst, det vill säga hur svårt eller enkelt en användare har för att “plocka upp” ett system efter att de inte använt det på ett tag. det handlar också om hur hög frekvens det är på felen som görs av användaren och hur ofta felen upprepas, samt hur lätt det är att “återhämta sig” ifrån ett fel. I sista hand handlar det också om hur nöjsamt det är att utnyttja gränssnittet. Lagom torrt och tråkigt, men livsviktigt om man vill att användaren skall komma tillbaka till en websida eller ett spel.

När man å andra sidan testar ur spelbarhetsperspektiv så tittar man på hur ofta en feature – en viss mekanik – används och om den används på det sätt som utvecklaren hade tänkt sig. Man tittar också på svårighetsgrad och svårighetsgradens ökning för att försäkra sig om att spelet inte blir för svårt, men heller inte för enkelt. Man tittar på förståelse av spelet och det kan gälla både hur gåtor skall lösas, men även om spelaren förstår vilka mekaniker hon skall använda i vilka sammanhang. Felfrekvensen är kopplad till förståelsen, men handlar också om hur ofta spelaren gör ett visst fel. När jag var på usabilityworkshop på GDC pratade teamet bakom HALO om ett tillfälle i en level där spelarna gjorde samma dödsbringande misstag gång på gång eftersom de trodde att en öppning i en klippvägg ledde vidare in i nästa level, när det i själva verket var ett bottenlöst stup. Och så klart så tittar man också på hur roligt spelaren har det och hur ofta de vill spela om, hur de tycker att spelet fungerar och så vidare.

För att kunna identifiera vad som skall testas i spelet behöver man bestämma sig för vilka områden och features som är fokus, kärnan, i spelet. En bra fråga att ställa sig i sammanhanget är vad spelaren behöver kunna göra för att spela, men även vad spelaren måste förstå för att kunna spela.

I Mass Effect måste jag kunna använda kontrollerna för att kunna röra mig i spelet. Men jag måste också förstå hur upgrades fungerar, hur jag byter dem, var jag hittar dem och hur upgradesen påverkar mitt spelande och den skada jag gör på fiender, det skydd jag får och så vidare.

Tittar man på ett rollspel, som till exempel Dragon Age, måste jag förstå hur jag utforskar världen – rör mig på kartan – hur jag sköter strid – i konsollversionen handlar det om att kunna hantera interaktionshjulet och de snabbkommandon jag har på höger skulderknapp – hur jag hittar uppdrag – det vill säga hur jag når inventariemenyn och sedan använder häger/ vänster skulderknappar för att cykla igenom menyn – hur jag hittar mitt inventarie och så vidare.

Intressant?

Läs även andra bloggares åsikter om , , ,