Hur kan du avgöra om spelarna förstår din spelmekanik?
Om du har utformat en mekanik för att den verkar smart bör du testa om spelarna kan upptäcka vad den gör, förutsäga konsekvenserna och använda den för att göra ett meningsfullt val. Ge spelarna en liten uppgift som är beroende av mekaniken och observera vad de gör innan du förklarar den. En lyckad animation, en rätt gissning efter en ledtråd eller att en spelare säger ”Jag fattar” räcker inte i sig: vart och ett kan bara visa en del av den förståelse du vill testa.
Definiera vad ”förståelse” innebär för den här mekaniken
Skriv ner mekanikens avsedda regel med enkla ord innan du bjuder in någon att spela. Beskriv sedan vilka beslut spelaren behöver fatta med hjälp av den. Anta till exempel att ett påhittat plattformsspel har en puls som stöter bort föremål i närheten. Ett användbart test kan undersöka om spelaren kan upptäcka pulsen, avgöra vilka föremål den påverkar, förutse åt vilket håll föremålet stöts och välja när pulsen ska användas. Det här är separata observationer; en spelare kan förstå effekten men inte räckvidden, eller förstå båda men ändå välja att inte använda pulsen.
Den här uppdelningen är en praktisk testplan, inte en validerad universell skala. Den bygger på MDA-ramverket, som beskriver spel utifrån mekanik, den dynamik mekaniken skapar under spelets gång och de upplevelser som dynamiken ger. Ramverket är användbart här eftersom mekanikens implementation inte är hela designfrågan: du behöver också se vad spelarna gör med den och hur det känns att spela.
Skriv ner en kort förutsägelse före sessionen: ”Om spelarna förstår X förväntar jag mig att se Y, utan ledtråden Z.” För pulsen kan det vara: ”Efter att ha sett ett föremål röra sig kommer spelaren att prova pulsen nära ett annat flyttbart föremål och ställa sig så att föremålet stöts mot hindret.” Då fokuserar testet på observerbart beteende i stället för ditt intryck av att någon verkade engagerad.
Lägg upp ett test där spelarna kan visa sin egen uppfattning
Ge varje deltagare samma startförutsättningar och en uppgift där mekaniken är relevant, utan att tala om svaret. Undvik instruktioner som ”Använd pulsen för att flytta lådan”; då testar du om de kan följa en anvisning. Skapa i stället en situation där det är rimligt att försöka ta sig vidare genom att flytta lådan, och se om spelarna upptäcker pulsen och kopplar den till föremålet.
Om du vill ta reda på vad de tror händer kan du be dem tänka högt medan de spelar. Nielsen Norman Group beskriver metoden som att representativa deltagare utför representativa uppgifter medan de sätter ord på sina tankar, och att testledaren lyssnar och uppmuntrar dem att fortsätta prata utan att styra deras val. Deras vägledning handlar generellt om användbarhetstester, så att tillämpa den på spelmekanik är en anpassning av metoden, inte ett forskningsresultat specifikt för spel.
Ställ en neutral fråga som ”Vad tänker du på?” om en spelare blir tyst. Undvik frågor som antyder mekaniken eller svaret, till exempel ”Såg du pulsknappen?” Den frågan kan förvandla ett test av spontan upptäckt till ett igenkänningstest. Om det stör tajmingen eller koncentrationen att prata medan man spelar kan du låta spelaren göra ett kort försök först och sedan be hen beskriva vad hen trodde skulle hända vid viktiga tillfällen. Tänk på att en förklaring i efterhand kan vara mindre tillförlitlig än att se beslutet fattas under spelets gång.
Observera handlingar, förutsägelser och återhämtning
Dokumentera belägg för de specifika påståenden du skrev ner. Användbara anteckningar är om spelaren provade mekaniken utan uppmaning, vilket mål hen valde, vilket resultat hen förutsåg, om utfallet stämde med förutsägelsen och vad hen gjorde efter ett oväntat resultat. Om en spelare lyckas använda pulsen av en slump men inte kan förutsäga utfallet vid ett andra försök visar den första framgången inte att hen har en stabil mental modell.
När det går att pausa utan risk kan du ställa en fråga om förutsägelsen före nästa försök: ”Vad tror du händer om du använder den här?” Låt sedan spelaren agera. Då kontrollerar du om spelaren kan koppla regeln till en ny situation i stället för att bara upprepa ett visat drag. Håll frågorna öppna och korta; om du förklarar regeln innan du frågar blir resultatet svårt att tolka.
Skilj förståelse av mekaniken från andra möjliga hinder. En spelare kan förstå regeln men missa kontrollen, inte se ett relevant föremål eller hindras från att agera av banans utformning. Anteckna det här som separata observationer. Om kontrollerna är otydliga kan sessionen till exempel inte visa om spelaren förstår själva mekaniken. Ändra en sak i taget i en uppföljande version eller session, så att du kan se vilket problem ändringen löste.
Använd en kompakt dokumentation av belägg
Sammanfatta beläggen efter varje session i stället för att sätta ett vagt betyg som ”fattade”. Den här lilla matrisen är ett illustrativt hjälpmedel, inte ett standardiserat instrument:
Håll den sista frågan åtskild från förståelsen. En spelare kan förstå en mekanik utan att tycka om att använda den; en spelare kan också uppskatta den visuella effekten utan att förstå regeln. Båda resultaten kan vara viktiga, men de kräver olika designbeslut.
Upptäckt: Anteckna det första frivilliga försöket, eller att spelaren inte försökte innan en ledtråd gavs. Om försöket uteblir kan problemet ligga i kontrollen, ledtråden eller tillfället.
Effekt: Anteckna spelarens förklaring och ett avsiktligt test. Om de inte stämmer överens kan återkopplingen vara tvetydig eller regeln inkonsekvent.
Förutsägelse: Fråga vad spelaren tror kommer att hända i en förändrad situation innan hen agerar. Det skiljer överförd förståelse från att minnas ett enskilt resultat.
Användning för att nå mål: Anteckna mål, tajming, val och resultat. En spelare kan förstå mekaniken även om den har liten strategisk betydelse.
Valfri användning: Se om spelaren återkommer till mekaniken och fråga varför. Preferens är något annat än förståelse.
Tolka mönstret innan du ändrar designen
Leta efter återkommande problem och sammanhanget där de uppstår. Om spelarna inte provar mekaniken bör du undersöka hur lätt den är att upptäcka: kontrollens instruktion, visuella ledtrådar och om banan ger dem anledning att experimentera. Om de provar men misstolkar resultatet bör du undersöka återkopplingen och om regeln är konsekvent. Om de förutsäger rätt men inte använder mekaniken när den är valfri bör du fundera på om den verkligen påverkar ett beslut eller om en annan handling helt enkelt är mer användbar. Det här är diagnostiska hypoteser, inte automatiska slutsatser; pröva dem mot det som faktiskt hände under sessionen.
Behandla inte en handfull sessioner som en uppskattning av hela spelargruppen. Kvalitativa observationer kan visa var en design är förvirrande och ge förslag på ändringar, men de kan inte ensamma fastställa hur vanligt problemet är bland alla spelare. Testa den reviderade versionen igen med samma uppgift och undersök även okända situationer utöver den där problemet först blev synligt. Om du senare behöver jämföra andelar eller preferenser bör du använda ett större, lämpligt rekryterat urval och ett mått som utformats för den frågan.
En praktisk tumregel för när du kan sluta
För en tidig prototyp kan du sluta revidera förklaringen när flera av de avsedda spelarna kan upptäcka mekaniken, förutsäga dess effekt i minst en situation de inte har sett förut och använda den för att nå ett mål utan en ledande ledtråd – och när återstående misslyckanden pekar på specifika, åtgärdbara problem snarare än förvirring om vad mekaniken gör. Det exakta antalet sessioner beror på projektet och besluten som står på spel; källorna som citeras här fastställer ingen universell gräns.
Syftet med testet är inte att bevisa att din idé är smart. Det är att ta reda på om spelet förmedlar regeln och gör det avsedda valet möjligt. Om spelarna förstår mekaniken men ändå inte tycker att den är intressant är det också användbar information: designen kan behöva en annan roll, belöning eller kontext.