Spelare och speldesign:
att involvera användare i designprocessen
Gamers and Game Design: Incorporating Users in
the Design Process
Tor Hellström
K3, Malmö Högskola Interaktionsdesign Examensarbete VT 2012 13/09/2012
Handledare: Lars Rauer Examinator: Jonas Löwgren
2
Abstract
This paper deals with the difficulties of applying user-centered design practices as an independent developer, based on the visualization of a game concept in the form of a prototype. The aim is to evaluate the usability of user-centered design practices, specifically in the field of games development. Throughout this paper, I will give an account of the methods used for testing, as well as a review of previous research done in this field of study. Finally, I will end with a discussion regarding the pros and cons of user-centered design, as well as some thoughts about its importance in similar projects.
Keywords: Usability, User Experience, User-Centered Design, Interaction Design, Games Development, Human-Computer Interaction, Participatory Design, Modding.
3
Innehållsförteckning
1. Inledning 4
2. Syfte och frågeställningar 5
3. Ansvarsområden 6
4. Metod 6
4.1 High-fi- och low-fi-prototyper 7
4.2 Direkta observationer 7 4.3 Användarintervjuer 8 4.4 Undersökningsgrupp 9 4.5 Forskningsöversikt 10 4.6 Validitet 10 5. User-centered Design 10
5.1 Vad är användarcentrerad design? 10
5.2 Användarcentrerad design i relation till spel 14
5.3 Användarcentrerad design: Principer i praktiken 20
5.4 Att designa spel med användare 22
5.5 Diskussion: Användarcentrerad design och
oberoende spelutvecklare 23
6. Redovisning och analys av användartester 26
6.1 Teoretisk förankring 26 6.2 Spelkoncept 27 6.3 Prototyp 1 27 6.4 Prototyp 2 29 6.5 Prototyp 3 31 6.6 Prototyp 4 33 7. Slutdiskussion 34 Referenslista 38 Glossary 40
4
1. Inledning
Spelindustrin är i dagsläget en av de snabbast växande industrierna i världen. Från 1993 till 2008 har intäkterna nästan femdubblats.1 Fortfarande ökar lönsamheten inom
industrin, och dess potential är till synes obegränsad. På grund av denna tillväxt och på grund av ständiga tekniska framsteg, har även förväntningarna hos användarna ökat. Tiden då spel som Worms, Pac-Man, eller Tetris verkade häpnadsväckande i spelarens ögon är länge förbi.
Dagens gamer förväntar sig, förutom en fängslande handling, även utmärkt grafik och häftiga ljudeffekter. Dessa aspekter har kanske intagit en mer framträdande roll i spelutveckling på senare tid, vilket har resulterat i att utvecklingen av spelets mekanik blivit sekundär, eller åtminstone mindre viktig. Ett exempel på detta är spelserien och bästsäljaren Call of Duty, i vilket man gång på gång använder sig av samma spelmotor för att utveckla nya versioner av spelet. Att utveckla en stor spelproduktion är emellertid kostsamt och tar tid. Utvecklingen av Diablo III påbörjades till exempel redan under 2001, alltså elva år innan dess slutgiltiga släppdatum.2
Med detta i åtanke kan man som utvecklare lätt förstå att det finns ett behov av metoder för att utvärdera en spelproduktions potentiella lönsamhet innan man lägger ner resurser på dess utveckling. Detta kan man åstadkomma genom att applicera användarcentrerad design under utvecklingsskedet.
Det här examensarbetet handlar just om hur man kan involvera användare i designprocessen. Arbetet utgår ifrån utvecklandet av ett musikspel där fokus ligger på att spelaren skapar musik genom att interagera med spelvärlden. I dagens musikspel är det vanligt att spelaren följer en melodi eller ett mönster. I spel som Guitar Hero och Dance Dance Revolution är målet att följa rytmen och trycka på rätt knapp vid rätt noter. Gör man inte det avbryts den förutbestämda melodin. Det finns oftast ingen möjlighet att skapa musik utanför spelets linjära ramar. Vi har därför arbetat med att utveckla ett spel som utforskar och experimenterar med möjligheterna att skapa musik som ett resultat av interaktionen med spelet.
1 http://vgsales.wikia.com/wiki/Video_game_industry (18-07-2012). 2 http://en.wikipedia.org/wiki/Diablo_III (13-09-2012).
5
Tre personer har arbetat med projektet: Tor Hellström, Neven Kedza och Vedran Simicic. Tidigare har vi genomfört ett projekt gemensamt inom ramen för kursen Projektledning I på Malmö högskola, och kunskaper vi anskaffat där har bidragit till planeringen av projektet. Arbetet med projektet har varit gemensamt men rapporterna är individuella, med olika forskningsinriktningar och olika forskningsfrågor. Mitt arbete har alltså fokus på användarcentrerad design.
Arbetet inleds med en redogörelse av projektets syfte, forskningsfrågor, och de olika ansvarsområden som vi som grupp haft under projektets förlopp. Därefter följer redogörelse av de metoder som vi som grupp har använt oss av under arbetet. Sedan redovisas resultaten. Först följer en forskningsöversikt och därefter redovisningen och analysen av användartesterna. Rapporten avslutas med en diskussion av forskningsresultaten.
2. Syfte och frågeställningar
Vi har skapat en visualisering av ett spelkoncept, i vilket spelaren kan skapa ljud och musik genom interaktioner som är typiska för just spel. Tanken är att spelaren ska kunna manipulera ljudet i spelvärlden för att skapa musik på olika sätt. Under projektets gång har vi experimenterat med olika interaktioner som är vanliga i spel för att ta reda på vad som skulle passa bäst för ett musikspel. Genom att fokusera på användartester och skapandet av prototyper för dessa tester har vi haft möjligheten att testa kritiska aspekter av spelets design.
Syftet med min del av detta projekt har varit att studera hur man kan använda sig av användaren som ett redskap i designprocessen. Detta har gjorts med utgångspunkt i det spelkoncept vi har tagit fram. Mina frågeställningar är de följande:
1. Vad säger forskning som gjorts inom speldesign om användarcentrerad design? 2. Hur mycket kan man använda sig av tillvägagångssättet som en oberoende
6 Med oberoende utvecklare menar jag inte bara de personer som utvecklar ett spel i projektsyfte liknande vårt, utan också s.k. Indie-utvecklare, som arbetar professionellt och kommersiellt men utan stöd av spelutgivare. Den första frågeställningen besvaras genom en forskningsöversikt och den andra bearbetas i en diskussion av de användartester som vi utfört.
3. Ansvarsområden
I planeringsfasen och utvecklingen av spelidén har samtliga gruppmedlemmar varit aktiva. Arbetet med själva spelet har varit uppdelat i tre delar; musik, kodning och grafik. Neven Kedza skötte musiken och hur det påverkade spelvärlden. Tor Hellström stod för kodningen av det spelmekaniska och utformandet av användartesterna. Vedran Simicic designade spelets grafik.
4. Metod
Vi har använt oss av kvalitativa forskningsmetoder i vårt projekt. Enligt Alan Cooper (2007:50) är det bättre att använda sig av kvalitativa metoder än kvantitativa metoder när man vill förstå sig på mänskligt beteende. Detta beror på att människors beteende är för avancerat och påverkas av för många variabler för att man ska kunna uttrycka det i siffror.
Vi bestämde oss för att göra ett antal speltest, under vilka vi utförde direkta observationer och halv-strukturerade intervjuer med ett antal standardiserade frågor. Till en början skapade vi hastiga low-fi-prototyper för att testa grundläggande spelmekanik med användartester. Användartesterna bestod av en kort introduktion, en spel-session och en diskussion med speltestarna. Intervjuerna spelades in på en smartphone och själva spel-sessionen spelades in med hjälp av Fraps, ett program som kan spela in det som händer på skärmen till en video. Varje test ledde till en ny prototyp. Sammanlagt har vi gjort fyra prototyper och tre speltester.
7
4.1 High-fi- och low-fi-prototyper
Termerna high fidelity prototype (high-fi) och low fidelity prototype (low-fi) används inom interaktionsdesign för att beskriva hur avancerad en prototyp är. Low-fi-prototyper är inte menade att se ut som den färdiga produkten. De är till för att testa en specifik funktion. Low-fi-prototyper är användbara eftersom de är enkla, billiga och går att bygga och modifiera snabbt, vilket underlättar utforskandet av en produkts möjligheter eftersom man hinner utvärdera flera koncept. Low-fi-prototyper är viktiga inom spel- och mjukvaru-utveckling eftersom de kan hjälpa utvecklarna upptäcka om deras idé är tekniskt genomförbar. High-fi-prototyper är närmare den slutgiltiga produkten. High-fi-prototyper har oftast full funktionalitet och interaktivitet. Till skillnad från low-fi-prototyper kan de användas av användarna utan hjälp från utvecklaren. De ger en mycket bättre bild av den slutgiltiga produkten och är därför användbara för marknadsföring av idéer. Enligt Sharp et. al. (2006:530-536) finns det emellertid en del problem med high-fi-prototyper. De tar oftast för lång tid att bygga och detta kan leda till att utvecklarna kan vara ovilliga att göra ändringar med något de har jobbat länge med. Testare brukar ofta klaga på problem med utseendet istället för innehållet.
4.2 Direkta observationer
Saffer (2010:78-79) förklarar att observationer är lätta att utföra och möjligen mest givande. Observationer ger designers tillfälle att interagera med användare genom att exempelvis ställa frågor om varför användaren genomförde en specifik uppgift på ett speciellt sätt. Designers kan även observera i hemlighet om de håller sig dolda genom att klä sig i neutrala kläder som ger möjligheten att smälta in i miljön. I en del miljöer kan man använda sig av specifik rekvisita som underlättar för observatören att passa in i en speciell bakgrund, exempelvis kan man ta med sig en ryggsäck om man befinner sig på en skola.
8
4.3 Användarintervjuer
I boken Interaction Design: Beyond Human-Computer Interaction av Sharp et. al. (2006:298-307) förklarar man att det finns fyra huvudsakliga typer av intervjuer:
● Strukturerade intervjuer ● Ostrukturerade intervjuer ● Halv-strukturerade intervjuer ● Grupp-intervjuer
I en strukturerad intervju är målet att fråga ett antal förutbestämda frågor, i syfte att samla mätbar data. Samma frågor ställs till samtliga deltagare, i samma ordning, och ofta med svarsalternativ.
En ostrukturerad intervju är informell och obegränsad av tid. Dessa är bäst lämpade för att ta reda på saker som t.ex. det första intrycket en spelare får vid starten av testet. En blandning av dessa två tillvägagångssätt är halv-strukturerade intervjuer. För följdriktighet täcker frågeställaren samma ämnen med alla deltagare, med både förutbestämda och öppna frågor.
Vi har använt oss av halv-strukturerade intervjuer under vårt testande. Hälften av frågorna har varit öppna och standardiserade för varje test och har behandlat spelaruppfattningar om varje prototyp. Resterande frågor har varit strukturerade för att samla information om spelets kritiska aspekter.
9
4.4 Undersökningsgrupp
För att testa våra prototyper avgränsade vi oss till personer med ett intresse i spel och/eller musikskapande. Vi har kommit i kontakt med testarna genom att fråga vänner och genom att använda Facebook. Några testare är elever på Malmö högskola.
Speltestare A, 23 år gammal, man. Spelade blockflöjt och saxofon som ung men gör inte det ofta längre. Spelar spel på PS3 och PC, ungefär 2-3 timmar varje dag. Spelar oftast actionspel och rollspel.
Speltestare B, 18 år gammal, kvinna. Kan spela trummor, piano, gitarr. Är duktig på att spela piano, har spelat i tio år. Har ett PS3 hemma men spelar det inte särskilt ofta, ungefär en timme två gånger i veckan. Spelar mycket spel på mobiltelefonen.
Speltestare C, 24 år gammal, man. Har aldrig haft ett särskilt musikaliskt intresse. Spelar spel på Xbox360 och PC, ungefär 4-5 timmar varje dag. Spelar spel i alla olika genrer.
Speltestare D, 20 år gammal, kvinna. Kan spela gitarr, men skapar inte egen musik. Spelar bara spel på mobiltelefonen och Facebook.
Speltestare E, 22 år gammal, man. Skapar musik i musikprogram (Fruity Loops) som hobby. Dubstep är hans favoritgenre. Spelar spel på PC, ungefär 2-3 timmar varje dag. Spelar oftast RTS-spel.
Speltestare F, 18 år gammal, man. Lyssnar på alla sorters genrer av musik men spelar inga instrument. Spelar spel på PC, ungefär 3 timmar om dagen. Spelar oftast FPS.
Speltestare G, 26 år gammal, man. Lyssnar mest på dödsmetall och thrash. Spelar bas, har spelat i fyra år. Spelar mest MMOs som World of Warcraft och Rift.
10
4.5 Forskningsgenomgång
För att besvara min fråga om vad forskningen säger om användarcentrerad design har jag gjort en genomgång av den litteratur som finns inom området. Jag började med att titta på relevant litteratur inom interaktionsdesign med inriktning mot användarcentrerad design, och övergick sedan till att titta på litteratur om speldesign. Vetenskapliga artiklar har jag hittat genom databaser såsom ACM Digital Library.
4.6 Validitet
För att kunna genomföra en bra studie gäller det att urvalet representerar målgruppen. Våra speltestare är i åldern 18-26, och som framgår ovan, har de erfarenhet av många olika spel och av musik. Trots att antalet testare hade kunnat vara högre, anser jag att gruppen har fungerat väl.
Ett större problem var utformandet av prototyperna. Inom tidsramen för projektet var det svårt att utveckla ett så avancerat spel som vår ambition krävde. Detta resulterade i skapandet av flera low-fi-prototyper för att lägga mer fokus på att testa intresset för spelidén, snarare än upplevelsen av spelet. Detta kommer att diskuteras djupare i analysen.
5. User-centered Design
5.1 Vad är användarcentrerad design?
Användare vet bäst, detta är filosofin bakom användarcentrerad design. Utövare av detta tillvägagångssätt anser att det är upp till skaparen av en produkt att ta reda på vad användarnas behov, mål, och preferenser är. Användare kan bidra med värdefull information om spel som kan leda till att det slutligen blir roligare att spela. I de grundligaste av projekt med fokus på användarcentrerad design involverar man användare vid varje steg av utveckling i projektet. Under projektets gång är det användardata som är den avgörande faktorn vid designbeslut, och när en fråga uppstår om hur någonting ska utföras, är det användarnas åsikt som spelar störst roll (Saffer, 2010:31-32).
11 Användarcentrerad design (User-Centered Design, UCD) är en arbetsmetod som länge tillämpats på industriell nivå. Det var Henry Dreyfuss, skaparen av 500-series-telefonen för Bell Telephones, som först populariserade tillvägagångssättet med sin bok Designing for People 1955. Men det var inte förrän på 80-talet som mjukvarudesigners började tillämpa dessa metoder. Delvis kan detta ha berott på allmänhetens bristande kunskap om datorer, eller det faktum att bearbetningshastigheten och minnet i datorer under den tiden var begränsad. Merparten av utvecklingstiden gick åt att bara få produkten att fungera korrekt, vilket gjorde att användarens behov kom i andra hand. Med förbättringen av datorernas kapacitet blev olika typer av gränssnitt möjliga och en rörelse började fokusera på användarnas behov snarare än på datorernas möjligheter. Denna rörelse blev känd som User-centered Design (Saffer, 2010:31-32).
Det finns många anledningar till varför intresset för användarcentrerad design och användbarhetstestande har vuxit de senaste åren inom spelindustrin. Som utvecklare försöker man nå ut till en betydligt större målgrupp och på flera olika spelplattformar. Spelföretag har nu också betydligt fler anställda än tidigare, och det blir svårt att jobba efter intuition när projektets vision blir för stort för en person att hantera (Isbister & Schaffer, 2008:3-4).
För att få en bättre uppfattning om hur användarcentrerad design fungerar, är det viktigt att ta en närmare titt på begreppen Usability och User Experience, som kan ses som beståndsdelar inom användarcentrerad design.
Begreppet usability3 syftar på den utsträckning i vilken en produkt är effektiv och intuitiv för en användare att utföra uppgifter med. Traditionell usability testing har fokuserat på tester med användare inom målgruppen för en produkt, för att se huruvida produkten uppfyller förväntningarna när den används i praktiken (Isbister & Schaffer, 2008:4).
12 Generellt ses usability som ett sätt att försäkra sig om att produkter är lätta att hantera och interagera med. Det handlar om att optimera interaktionen med en produkt för att förenkla och effektivisera vardagen för dess användare. Sharp et. al. (2007:20-23) beskriver i boken Beyond Human-Computer Interaction sex mål för framgångsrik usability testing:
● Effectiveness (Hur bra är produkten på att göra vad den är avsedd att göra?)
● Efficiency (Hur bra är produkten på att hjälpa användare att utföra uppgifter?)
● Safety (Hur bra är produkten på att skydda emot oönskade situationer, såsom förlorade sparfiler etc.?)
● Utility (Erbjuder produkten rätt sorts funktionalitet för den uppgift som ska utföras?)
● Learnability (Hur lätt är det att lära sig använda produkten?)
● Memorability (Hur lätt är det att komma ihåg hur man använder produkten?)
Syftet med de ovanstående målen är att göra det möjligt för produktdesignern att utvärdera olika aspekter av en produkt. Genom att besvara dessa frågor kan en utvecklare tidigt i designprocessen bli medveten om potentiella problem i produktdesignen som denne kanske inte identifierat innan (Isbister & Schaffer, 2008:4). Om dessa mål täcker användbarheten av en produkt utförligt, så finns det också andra aspekter av produktdesign som är minst lika viktiga, som till exempel upplevelsen en användare får av en produkt. På senare tid har man inom HCI och Interaktionsdesign blivit mer intresserad av användarens upplevelse av produkten, så kallat User Experience. Denna utveckling från usability testing fokuserar mer på hur det känns för användaren att använda produkten, och med vilken inlevelse han eller hon använder den.
Tre fördelar med att jobba med user experience snarare än usability tas upp i tidsskriftsartikeln User Experience - a Research Agenda (Hassenzahl & Tractinsky, 2006).4
13 Den första aspekten handlar om att komma bort från det snäva fokus på det instrumentella som finns inom usability testing. Inom user experience försöker man istället argumentera för behovet av icke-instrumentella värden, som till exempel överraskning, avledning eller intimitet. I en tidigare artikel av Hassenzahl ansåg han att det blir allt mer viktigt att inte bara bekymra sig över pragmatiska aspekter av interaktiva produkter, utan också hedonistiska aspekter, såsom stimulans, individuell personlig utveckling och ett ökande av kunskap och skicklighet.5
Den andra aspekten gäller hur user experience tar ett “mänskligt perspektiv”. Det finns ett större intresse i att förstå den roll som emotionell påverkan har i koppling till användningen av interaktiva produkter. Emotionell påverkan är inte något nytt inom HCI, tidigare har man fokuserat på att förhindra känslor som frustration och missnöje, men man har inte sett på känslor som något som kan vara positivt. Det som user experience tillför HCI är ett fokus på positiva emotionella resultat som glädje, nöje och stolthet.
Den tredje och sista aspekten gäller upplevelse i koppling till bruk av interaktiva produkter. I detta perspektiv ses en upplevelse som ett samspel mellan produkten och användarens sinnesstämning vid bruk, under en avgränsad period. Det sker en ständig interaktion mellan användarens känslor och produkten, vilket leder till en upplevelse. I tidskriftsartikeln menar man att upplevelser är viktigare för personligt emotionellt välbefinnande än materiell konsumtion.
Dessa tre aspekter tillsammans bildar perspektivet som kallas User Experience. På nästa sida följer en bild som beskriver deras samspel.
14 Figur 1. User Experience (User Experience - a Research Agenda, Hassenzahl & Tractinsky, 2006:95).
5.2 Användarcentrerad design i relation till spel
Jag har nu gått igenom två centrala beståndsdelar när det gäller design av interaktiva produkter ihop med användare. Det framgår att user experience fungerar som ett tillägg till usability, för att täcka en helhet av produktdesign som usability inte riktigt klarar av. När man sedan börjar tala om användarcentrerad design, är det speciellt viktigt att tänka på de aspekter som perspektiven belyser, det vill säga saker som emotionell påverkan och upplevelse vad det gäller user experience, och det instrumentella vad det gäller usability.
Hur går man då tillväga när man arbetar med användarcentrerad design? Det är tydligt att användarcentrerad design är en extremt viktig del av produktdesign, men litteraturen om ämnet ger inte så mycket konkret hjälp när det gäller att applicera denna arbetsmetod. I artikeln Marrying HCI/Usability and Computer Games: A Preliminary Look tar Jorgensen (2006) upp hur det har skrivits väldigt mycket böcker inom HCI/Usability om user interface design, men nästan ingenting i relation till spel, och i boken Designing for Interaction av Saffer (2010:31-32) använder man bara två sidor för att beskriva vad user-centered design är. Om man sedan tittar på litteratur om användarcentrerad design i relation till spel, är urvalet ännu mindre.
15 I läroböcker som handlar specifikt om speldesign, som t.ex. Andrew Rollings and Ernest Adams on Game Design (2003) eller Oxlands Gameplay and Design (2004) tas nästan inga metoder upp för hur man kan involvera eller ta del av användare i designprocessen. I boken Game Design Workshop: a Playcentric Approach to Creating Innovative Games av Tracy Fullerton (2008:248-256) ges emellertid en beskrivning av hur man utför ett speltest. Speltestande är något som utvecklare tillämpar genom hela designprocessen. Det finns många sätt att utföra ett speltest, varav vissa är informella och kvalitativa, andra strukturerade och kvantitativa. För spelet Halo 3 utförde Microsoft Games User Research över 3000 timmars testande med fler än 600 medverkande testare. Men oavsett hur många testare som används är målet med speltestande alltid det samma: att få fram användbar feedback från användare för att förbättra upplevelsen av ett spel.
Speltestande är en av de viktigaste aktiviteterna för en designer, och oftast den som är mest missförstådd. Den vanligaste missuppfattningen när det gäller speltestande är att det helt enkelt betyder att bara spela spelet och samla feedback. I verkligheten är det bara en del av en process som består av mycket förberedelse och djupa analyser.
Rollen som en utvecklare har under designprocessen är att förmedla spelarens behov och uppfattningar till spelets slutliga design. För att inte avvika från denna princip är en ständigt pågående iterativ process (dvs en process där moment görs om gång på gång) av speltestande, utvärdering och revidering nödvändig. Fullerton (2008:249) menar också att det är viktigt att påbörja denna process tidigt i utvecklingen, och påpekar att om man som utvecklare väntar med testande tills man har en beta-version av spelet kan det redan vara försent att göra nödvändiga grundläggande eller dramatiska ändringar till spelet.
16 Figur 2. Iterative Game Design (Fullerton, 2008:249)
Figur 2 visar en tydligare bild av iterativ speldesign. Utvecklaren börjar med en idé, som testas och utvärderas, vilket leder till skapandet av en första prototyp. Denna iteration pågår sedan genom hela projektets utveckling.
Det bästa sättet att utföra ett speltest enligt Fullerton (2008:252-256) är att låta en objektiv person hålla i testet medan utvecklaren själv observerar. Ofta gör utvecklare misstaget att de pratar för mycket om sitt spel innan de utför testet, vilket fördärvar syftet att få ett färskt perspektiv på spelet. Om man som utvecklare inte har möjligheten att låta en objektiv person hålla i testet, menar Fullerton att man kan skapa ett manus för att försöka minimera sin vilja att påverka sina testare. Vidare förklarar Fullerton att det är praktiskt att dela upp ett sådant manus i fem delar:
17
● Introduktion
● Uppvärmningsdiskussion
● Spel-session
● Diskussion om spelupplevelser
● Avslutning (här kan man tacka speltestarna för att de har medverkat)
Fullerton föreslår att man som utvecklare bör börja med att ge en kort introduktion av sig själv, sitt företag och hur speltestet kommer att utföras. Om speltestet spelas in med ljud, video eller om andra observationsmetoder tillämpas berättar man detta för testarna. Vidare förklarar författaren att utvecklaren bör utforma ett antal generella frågor relaterade till liknande spel eller produkter som testarna använder. Exempel på sådana frågor kan vara:
1. Vilka spel spelar du vanligvis? Vilket är din favorit? 2. Varför gillar du just dessa spel?
3. Var får du reda på information om nya spel? 4. Vilket spel köpte du senast?
Efter detta bör personen ansvarig för speltestet påbörja spel-sessionen. Det bör vara tydligt att spelet som testas fortfarande är under utveckling, och att testpersonernas feedback på spelupplevelsen kan vara mycket hjälpsam. Målet är inte att testa deras skicklighet, utan att testa spelet, d.v.s. alla svårigheter som testpersonerna kan ha med spelet kan hjälpa utvecklaren att förbättra spelet. Det är också viktigt att be speltestarna att “tänka högt” när de spelar. Det kan ofta vara svårt att åstadkomma denna monolog, men om det går sakta kan man som testansvarig försiktigt fråga vad testaren tänker eller försöker göra. Spel-sessionen bör pågå i ca 15-20 minuter.
När spel-sessionen är avklarad är det bra att ta en diskussion om testarnas upplevelse av spelet. För denna diskussion bör man som utvecklare utforma ett antal frågor om t.ex. utmaning och generellt intresse. Det är också viktigt att fråga om de har förstått spelets mål och om de lärde sig snabbt hur man skulle spela. Senare i designprocessen kommer denna del av speltestet präglas allt mer av mer specifika frågor. Grundläggande fokus under denna diskussion bör ligga på de viktigaste designfrågorna vid denna tidpunkt.
18 Davis et. al. (2005) försöker i tidsskriftsartikeln A survey method for assessing perceptions of a game: The consumer playtest in game design skapa en metod för att samla information om användarens upplevelse av ett spel i utvecklingsfasen. I artikeln beskriver de att det finns metoder för att erhålla feedback från användare, såsom usability testing, enkätsundersökningar och fokusgrupper, men att dessa har svagheter vilket gör att de behöver kompletteras med varandra. Jag kommer här att kortfattat gå igenom dessa metoder och dess svagheter innan jag ger en beskrivning av författarnas egen utvecklade metod; The Playtest Method.
Davis et. al. menar att fokusgrupper kan vara användbara i de tidigare stegen av utveckling av ett spel, som t.ex. för konceptutveckling och -utvärdering, eller för att i vissa fall få en bättre förståelse av ett problemområde. Ofta handlar diskussionen i fokusgrupper om värdet av ett abstrakt spelkoncept snarare än en praktisk implementation av konceptet. Fokusgruppper kan också lätt bli påverkade av det grupptryck som kan uppstå, vilket kan ha ett inflytande på kvaliteten av den information som kan erhållas.
Enkätundersökningar används i stor utsträckning och av nästan alla företag inom branschen. Vanligtvis används de för att erhålla information om spelares uppfattningar om egenskaper i spelet, t.ex. om de gillar en egenskap eller inte, och varför. Genomförd på rätt sätt kan en enkätundersökning ge betydelsefull information om hur människor tänker kring spel, vilket kan leda till en bättre förståelse över vilka ändringar som behöver göras. Dock menar Davis et. al. att det kan vara svårt att genomföra en sådan undersökning väl, på grund av undersökningens kvantitativa karaktär. Vidare beskriver författarna att det är svårt att göra en betydelsefull statistisk analys eftersom personer som medverkat i undersökningen kan ha upplevt spelet på många olika sätt och det kan då bli svårt att tolka resultaten. Det är också dyrbart att utföra sådana undersökningar. En annan populär form av användartestande är beta-tester. Beta-tester används i alla former av mjukvaruutveckling, och är en nödvändig informationskälla för utvecklare. Beta-testare är frivilliga testare som erbjudits att spela en tidig version av ett spel för att hitta fel såsom tekniska problem eller buggar och ge åsikter om balansfrågor (bland annat svårighetsgrad) och underhållningsvärde. Medan beta-testande är suveränt för att erhålla information om tekniska problem och buggar, är det svårare att genom beta-testande identifiera problem som har att göra med gameplay eller underhållningsvärde.
19 Anledningen till detta är att de som vanligtvis testar spel frivilligt inte fullt ut representerar den målgrupp som slutligen kommer att spela spelet. Generellt sett är beta-testare mycket skickligare än den genomsnittliga spelaren. Den kanske viktigaste anledningen till varför beta-tester som en metod för erhållande av feedback inte är optimala, är att det vanligtvis inte finns något systematiskt sätt att samla all den information som speltestarna kan ge. Det finns heller ingen kontroll över vilken upplevelse speltestaren kommer att få, då miljön i vilken spelaren befinner sig kan variera stort.
Till sist nämner Davis et. al. Usability Testing, vilket jag redan har gått igenom. Deras huvudsakliga kritik till denna form av testande i relation till spel är att det erbjuder mer information om vad spelare gör i ett spel, snarare än hur de upplever spelet, och att det ofta testas på väldigt få användare.
För att utvinna specifik information om hur spelare uppfattar olika aspekter av ett spel, har Davis et. al. alltså arbetat fram en metod som de kallar The Playtest Method. Denna metod är en kombination av enkätundersökningar och konkret speltestande (hands-on gameplay), i syfte att skapa en systematisk metod för att samla information under ett speltest. Målet är att förse spelutvecklare med angripbar (actionable) feedback om viktiga aspekter av ett spel, feedback som har en sådan kvalité att man kan fatta beslut efter den. Författarna menar att deras kombination för att testa nöjesfaktorer i spel är unik, även om metoderna som används inte är det.
Ett vanligt speltest enligt Playtest-metoden utförs genom att ett urval av testdeltagare samlas i en testanläggning, och bemöts av speltest-instruktörer som guidar dem igenom hela processen. Deltagarna börjar med att fylla i ett frågeformulär för att försäkra att de uppfyller kraven (representativa för målgruppen), och eskorteras sedan till en speltestsal med antal teststationer med standardiserad utrustning. Samtliga deltagare har på sig hörlurar och kan inte observera vad andra deltagare gör. Det delas ut en kopia av ett spel och alla tillbehör som behövs för att spela till deltagarna, och de instrueras att spela som de vanligtvis hade gjort i sin egen miljö. När deltagarna har spelat klart efter en förutbestämd tid ombeds de att svara på ett antal frågor om olika aspekter av upplevelsen; nöje, uppfattning om grafik och ljud, handling, och interaktionen. I varje speltest deltar 25-35 testpersoner, och spel-sessionen varar i ungefär en timme.
20 Playtest-metoden har flera väsentliga egenskaper för att erhålla angripbar feedback om dess testares uppfattningar om ett spel.
● Fokus på den första spelupplevelsen
● Större urval
● Standardiserade frågor
● Urval som representerar målgruppen
● Fokus på att identifiera problem
● Kontrollerad testmiljö
● Låg kostnad och snabba resultat
Viktigt här är forskarnas definition av den första spelupplevelsen som den första timmen av spelande. Det är speciellt viktigt att spelet är underhållande under den första timmen, eftersom det är denna tid som avgör spelarens uppfattning om han/hon vill fortsätta eller inte. Med så många produkter och apparater som idag tävlar om konsumentens uppmärksamhet är det viktigt att garantera en nöjesrik första timme av spelande.
En annan av de viktigare egenskaperna i Playtest-metoden är standardiserade frågor. Användningen av dessa gör det möjligt för utvecklare att göra jämförelser med spelares uppfattningar om olika spel. Ännu viktigare är att man som utvecklare kan jämföra uppfattningar under utvecklingen av ett spel från version till version, för att bedöma vilken effekt ändringar i spelet har på bl.a. nöjesfaktorer. Detta sätt att samla feedback ger en systematik som inte riktigt finns med någon annan metod.
5.3 Användarcentrerad design: Principer i praktiken
En stor del av forskningen inom användarcentrerad speldesign görs av forskare som är verksamma på företag. Ovanstående tidskriftsartikel är skriven av forskare från Microsoft Game Studios. Ett annat konkret exempel på en sådan artikel är User Research in Games (Pagulayan et. al., 2003), inom vilken författarna tar upp ett antal exempel på metoder som utfördes under utvecklingen av olika spel av Microsoft Games User-Testing Group (MGUT).
21 På Microsoft Game Studios använder man sig av två typer av formativa studier (d.v.s. studier som görs på produkter under utveckling). Dessa två kallas för Initial Experience Playtest och Critical Facet Playtest.
Det första intrycket är en grundläggande faktor för en spelares belåtenhet med ett spel. För att få reda på vad användares intryck av ett spel är, använder MGUT sig alltså av ett så kallat Initial Experience Playtest. Eftersom de flesta spel upplevs i en särskild ordning (d.v.s. med en början och ett slut), finns det värde i att göra tester som ger information kring hur spelare uppfattar de första timmarna av spelande.
Ett Critical Facet Playtest är ett speltest som fokuserar på kritiska aspekter av den grundläggande spelmekaniken i ett spel. I till exempel luftstridsspel kan det finnas flera valmöjligheter vad det gäller vilket flygplan man kan välja för ett uppdrag, och vilka vapen flygplanet ska vara utrustat med, men spelets grundläggande mekanik, eller de aspekter som är speciellt viktiga, är att:
1. Man kan flyga planet.
2. Man kan flyga planet tillräckligt väl för att vinna en luftstrid.
Även om dessa aspekter kan behandlas i ett Usability test, vill författarna poängtera att uppfattningar vad det gäller spelupplevelsen är lika viktiga i detta fall.
Följande exempel visar hur Microsoft utförde ett Critical Facet Playtest under utvecklingen av Oddworld: Munch’s Oddysee för att bestämma vilken kameravinkel spelet skulle ha, och vilket handlingssätt som skulle användas för kameran i spelet. För testet ville man använda sig av minst 25 deltagare som representerade målgruppen. Deltagarna fick spela spelet i en timme, och ombads sedan att besvara ett frågeformulär. Som vanligt började detta frågeformulär med ett antal standardiserade frågor om generella uppfattningar om spelet följt av mer specifika frågor relaterade till andra intresseområden för utvecklarna. Till slut ställdes frågor som behandlade kameran och dess handlingssätt.
Två analyser gjordes utifrån frågeformuläret. Den första analysen som gjordes var angående kamerans handlingssätt. 46% av deltagarna tyckte att kameran inte gav dem tillräckligt mycket flexibilitet för kontroll. Den andra analysen som gjordes var att gå
22 igenom alla deltagares formulär för att se om de nämnt kameran överhuvudtaget innan frågor om den togs upp i formuläret, och om de hade gjort det i så fall ta reda på om det var en negativ eller positiv kommentar. Man fann att 43% av deltagarna hade nämnt något negativt om kameran innan det att frågor om den togs upp. Utifrån analyserna bestämdes det att det var nödvändigt att ändra på kameran, även om det var omständligt och betydde omkonstruktion av många av spelets redan färdiga nivåer.
5.4 Att designa spel med användare
Ett problem som finns med användarcentrerad design är att man som utvecklare oftast inte tar del av användarens kunskaper och erfarenhet fullt ut i designprocessen. Användarcentrerad design bör inte bara handla om design av produkter för användare, utan om design av produkter med användare. Det som bör stå i fokus är metoder för hur man bäst kan se användaren som en samarbetspartner under utvecklingsfasen. Ett begrepp som används för att beskriva samarbetet mellan utvecklare och användare inom spelindustrin har myntats av Sue Morris (2004): Co-Creative Media.
En intressant synvinkel på design i spel både av och med användare är modding, och många spel har förändrats av dess användare på detta sätt. Modding syftar på ordet modifikation, och att “modda” betyder i ett spelsammanhang helt enkelt att förändra ett spel ifrån dess originalskick (Sotamaa, 2010:240). Det kan handla om att ändra på bland annat spelets grundkod, texturer, spelmekanik, uppdrag och mål i spelet. Total conversion modding innebär storskalig förändring av många eller alla aspekter av ett spel för att skapa en ny upplevelse (Nieborg & van der Graaf, 2008:184). Ett extremt framgångsrikt exempel på sådan modding är Counter-Strike, som utvecklades som en fristående mod till datorspelet Half-Life. Sedan Counter-Strike släpptes 1999, har det sålts i över 27 miljoner exemplar.6 Inom e-sport är det fortfarande ett av de mest framträdande spelen.
På senare tid har företag öppnat upp mer för utvecklingen av användar-anpassat innehåll i spel, och det finns väldigt många exempel där spelupplevelsen tydligt har förbättrats av detta. Blizzard Entertainment skapade till exempel en så kallad “World Editor” till spelen Starcraft och Warcraft, som användare kunde ta del av för att skapa
6
23 egna nivåer (custom maps) med helt nya uppdrag och mål. Det var också denna form av utveckling som först populariserade spelgenren ARTS (action real-time strategy) med spelen Aeon of Strife (Starcraft custom map) och Defense of the Ancients (Warcraft III custom map). Spelet DotA har sedan dess blivit ett fristående spel utvecklat av Valve.7 I en studie har Postigo (2007:309-311) undersökt anledningarna till varför användare skapar mods och anpassat innehåll till spel. I studien beskrivs tre centrala anledningar. Det första skälet är att vissa moddare vill skapa något konstnärligt, och blir inspirerade till att förbättra delar av ett spel. Den andra orsaken är att vissa moddare vill identifiera sig med spel och skapar innehåll som engagerar dem mer känslomässigt. Den tredje centrala anledningen till varför moddare skapar innehåll är att de vill slå sig in i branschen.
5.5 Diskussion: Användarcentrerad design och oberoende spelutvecklare
Det är uppenbart att användartester och användarcentrerad design inom spelindustrin utnyttjas allt mer frekvent under designprocessen, men som jag har visat finns det ganska lite forskning inom området. Den forskning som har gjorts handlar mer om hur man kan gå tillväga än om att analysera resultaten av användningen av särskilda metoder, eller om hur användbara dessa kan vara överhuvudtaget. Personligen tror jag att detta kan bero på att den standardisering av testande som många inom området förespråkar inte används fullt ut, särskilt inte av folk inom spelindustrin. Man låter människor tycka till lite slumpmässigt genom många olika kommunikationsmedier (som t.ex. forum, mail och liknande), vilket inte nödvändigtvis är dåligt, men det skapar en problematik när man försöker analysera metoder och göra forskning kring området. Jag tror dock att ett lekfullt tillvägagångssätt när det gäller testande av det roliga i spel är väsentligt för skapandet av något roligt och intressant.
Eftersom usability har forskats om betydligt längre än användarcentrerad design, är det mycket lättare att hitta beskrivningar och litteratur som handlar om usability. Men det är också klart att usability inte räcker när det gäller produktdesign. I artikeln User Research in Games (Pagulayan et. al., 2003) tar författarna upp just de problem som pekar på varför
7
24 user experience är minst lika viktigt, om inte viktigare, inom speldesign. Man menar att även om usability-metoder är praktiska, tillåter de inte utvecklare att testa för problem som kan uppstå efter längre användning av en produkt. Vidare förklarar man att detta är ett extremt stort problem för spelutvecklare, då en av deras största utmaningar är återspelbarhet, och just återspelbarheten är kanske ett av skälen till varför user experience intagit en mer framträdande roll inom spelutveckling. De aspekter av design som user experience lägger fokus på spelar större roll inom spelutveckling än traditionell usability testing. Upplevelsen av ett spel är viktigare än hur lätt det är att lära sig att spela spelet, eftersom det senare är en del av utmaningen, vilket utgör en del av upplevelsen. Jag har gått igenom begreppet Playtesting utifrån forskning gjord av Davis et. al. (2005). The Playtest Method består av en kombination av olika metoder, och den betonar hårdare än usability testing systematik. Frågan som man som oberoende utvecklare då ställer sig är: hur mycket kan man dra nytta av denna metod?
Playtest Oberoende utvecklare
Fokus på första spelupplevelsen X X
Större urval X
Standardiserade frågor X X
Urval som representerar målgruppen X
Fokus på att identifiera problem X X
Kontrollerad testmiljö X X
Låg kostnad och snabba resultat X (X)
Tabell 1. Playtesting som oberoende utvecklare
Tabell 1 visar vilka av de egenskaper som Davis et. al. har identifierat som man som oberoende utvecklare effektivt kan fokusera på. Som framgår ur tabellen gäller detta de flesta: Man kan fokusera på den första spelupplevelsen, man kan ha standardiserade frågor, man kan fokusera på att identifiera problem och man kan ha en kontrollerad testmiljö. Men vissa av egenskaperna som är förknippade med Playtesting kan vara problematiska för oberoende utvecklare. Det gäller framförallt de egenskaper av speltester som behandlar anskaffandet av antalet deltagare för användartester, och frågan om deltagarna korrekt representerar målgruppen. En anledning till detta är att
25 man som oberoende utvecklare kanske ännu inte etablerat sig själv på marknaden, och potentiella testare inte är medvetna om ens produkt. Vidare kan kostnader vara ett problem. Det är det oftast inte för stora företag vid utgivning av populära titlar, då de ofta bjuder in till beta-tester av ett nytt spel i utbyte mot ett förköp av spelet, men för oberoende utvecklare kan de naturligtvis vara det.
Som oberoende utvecklare kan man ifrågasätta om Playtest-metoden är lämpad för sina projekt, då mycket av dess funktionalitet beror på ett utförande av storskaliga, kostnadskrävande tester. Men lösningen för oberoende utvecklare, som varken har förväntningar på sig eller de resurser som krävs för att locka användare till större speltest, kan vara marknadsföring över internet. Det bästa exemplet på sådan marknadsföring är finansieringsplattformen Kickstarter8, som hjälper utvecklare med finansiering av projekt. Utvecklare pitchar sin idé eller sitt projekt med en video och en beskrivning, och privatpersoner kan då besluta sig för att donera pengar till projektet. Man söker en viss summa inom en förutbestämd tid, och om målet nås betalas pengarna ut för förverkligandet av idén. Oberoende utvecklare som Double Fine Productions, skaparen av Psychonauts (2005), har bland annat använt sig av plattformen, och arbetar nu med ett projekt som blev finansierat genom Kickstarter. Double Fine sökte 400,000 dollars, och lyckades på en dryg månad samla ihop 3,336,372 dollars.
Kickstarter är ett utmärkt sätt för oberoende utvecklare att marknadsföra och finansiera sitt spel. Men innan man har en visualisering av sin spelidé finns det fortfarande en problematik kring anskaffandet av deltagare som representerar målgruppen till användartester. Vid detta steg i utvecklingen blir det kanske i så fall viktigare att hitta potentiella testare genom alla möjliga olika kommunikationsmedier eller mötesplatser. Vänner, skolkamrater, arbetskollegor, och alla möjliga olika andra kretsar måste användas. Det är uppenbart att detta medför vissa problem som bland annat har att göra med representation av målgrupp, men en sak som är bra just vid detta utvecklingsskede är att informaliteten som vänskapskretsar medför kanske lämpar sig för konceptutveckling. Kommunikationen är mer naturlig och ärlig, och tankar kring just konceptets negativa eller positiva aspekter känns mer acceptabelt att tala om. Att utnyttja informalitet är alltså något som oberoende utvecklare kan fokusera på som alternativ till renodlat speltestande.
8
26 Kapitlet har också till viss del handlat om modding och utveckling av spel med användare i designprocessen. Som forskningen visar finns det många goda exempel på varför man som utvecklare bör tänka på att öppna upp sitt spel för modding och hur det kan påverka användare. Jag tror att om man ger användare möjlighet att göra val utanför spelets ramar kan det bana väg för skapandet av en community kring spelet, vilket är något som man kan se på många spel. Detta är också en faktor som oberoende utvecklare utan tillgång till stora resurser kan fokusera på.
6. Redovisning och analys av användartester
Härnäst kommer jag att gå igenom och analysera användartesterna som gjordes under projektets förlopp. Vi skapade fyra prototyper, varav de tre första testades. Jag kommer att gå igenom utformandet av prototyperna och efterföljande användartester, för att till slut redogöra för resultaten av dessa. Jag börjar med en teoretisk förankring och ger sedan en beskrivning av spelet och dess funktioner.
6.1 Teoretisk förankring
I våra användartester har vi framför allt utgått ifrån Fullertons (2008) speltest, och har strukturerat våra tester till den nivå som det har varit möjligt. Vi har hållit oss till det speltestmanus som Fullerton beskriver. Våra tester började med en kort introduktion och uppvärmning, och därefter lät vi våra testdeltagare spela under 15-25 minuter. Under speltestet observerade vi och lyssnade på deltagarna, och avslutade sedan med en diskussion kring de aspekter som vi testade för. I enlighet med Figur 2 utförde vi ett antal iterationer av speltestande, utvärderande och reviderande.
Vi har därutöver valt att särskilt fokusera på ett antal av de egenskaper som beskrivs av Davis et. al. som väsentliga för speltestande. Vi har haft ett antal standardiserade frågor för varje test, och lagt större delen av vårt fokus på att identifiera och testa för kritiska aspekter av spelet. Vi använde oss av testdeltagare som representerade målgruppen, vilken vi hade identifierat som personer med ett intresse för musikskapande och spel. Som det framgår längre ner i texten har prototyperna fokuserat både på usability och user experience.
27 Vi ville använda oss av något liknande det tillvägagångssätt som beskrivs av Microsoft Games User Research Group, men eftersom vi inte hade någon enorm databas över spel med vilka vi kunde jämföra resultat av våra tester, beslutade vi oss för att fokusera på kritiska aspekter och identifiera problem med spelets grundläggande mekanik. Kraften lades på att designa för ett första intryck, och på att skapa en prototyp för det spelkoncept vi kommit fram till. Vi har alltså arbetat på det sätt som är möjligt för oberoende utvecklare att göra.
6.2 Spelkoncept
Syftet med spelet är att som spelare kunna manipulera ljud i spelvärlden för att skapa musik. Tanken är att det ska fungera som ett sandlåde-spel (d.v.s. ett spel utan definierade spelarmål, som t.ex. Minecraft eller Garry’s mod), och att det roliga i spelet ska vara att experimentera med skapandet av musik i en spelmiljö. Vi experimenterade med olika sätt att göra detta genom interaktioner som är typiska för spel (till exempel att skjuta, slå, eller hoppa på olika föremål). Eftersom vi fokuserade på att testa funktioner, utvecklade vi low-fi-prototyper med platshållare (placeholders) för nästan alla våra 3d-objekt i världen. Spelet är tänkt att rikta sig till personer med ett intresse för både datorspel och musikskapande. Vi utvecklade våra prototyper i spelmotorn Unity.
6.3 Prototyp 1
Vår första prototyp skapades för att testa grundläggande spelmekanik. Vi skapade tre olika versioner av ett scenario i spelet. Alla tre versioner hade en sak gemensamt: om man interagerade med ett föremål i spelet började en ton repeteras i långsam takt. Takten ökar om spelaren interagerar med föremålet fler gånger. De tre interaktionerna vi testade var att “hoppa” på föremålen, att “slå” på dem, och att “skjuta” på dem. Jag förklarade de grundläggande kontrollerna för spelarna, och noterade svar från våra testare, Neven Kedza utförde intervjun och Vedran Simicic observerade spelarna.
28
Vilken interaktion var mest passande?
Speltestare A ansåg att det var lättare att hålla takten med tonerna genom att skjuta men att själva interaktionen var tråkig eftersom ens karaktär kunde stå still hela tiden och bara skjuta på alla föremål. Speltestare B tyckte att det var mer intuitivt att slå på föremålen, men att det var svårare än att skjuta. Speltestare C tyckte också att det var lättare att skjuta eftersom man inte behövde röra på sig för att aktivera nya ljud.
Vilken interaktion var minst passande?
Samtliga speltestare enades om att hoppandet var den sämsta interaktionen. Speltestare A sade att funktionen inte fungerade som den skulle eftersom man inte kunde styra karaktären i luften efter att den hade hoppat. Speltestare B hade stora problem med att använda sig av hopp-funktionen, och blev snabbt frustrerad.
Finns det ett värde i den här typen av interaktion? Jämfört med ett instrument? Speltestare A och C tyckte att spelet i första prototypen bara gjorde det svårare att skapa musik jämfört med ett riktigt instrument. Speltestare B tyckte att det var en intressant idé.
Övrigt:
Speltestare A föreslog att spelet hade kunnat vara mer intressant om man kunde dela med sig av musiken man skapade på något sätt.
Speltestare A och B klagade på att spelet inte hade tillräckligt många olika ljud. Speltestare B klagade på att spelet såg tråkigt ut och att det inte var någon variation i föremål och monster. Samtliga speltestare klagade på att det inte gick att stoppa ett föremål från att spela ljud efter att man hade aktiverat dem första gången.
Analys av användartest 1
Prototyp 1 visade att användare förväntade sig ganska mycket av spelet, och det var tydligt att det skulle behövas mycket mer arbete kring alla aspekter av spelets design. Det fanns många svagheter vad gällde interaktionen med spelet, och konceptet behövde utvecklas mer. Testandet av interaktionen i spelet överskuggades lite av andra svagheter i prototypen. Bristen på variation i ljud var stor, och de andra kommentarerna från de standardiserade frågorna pekade också på att utvecklingen behövde gå framåt snabbare.
29 Testet visade på två viktiga saker. Innan man startar speltester måste spelidén vara färdigutvecklad. Annars blir det svårt för speltestarna att ta spelet på allvar och engagera sig. Det är också viktigt att kunna göra tydligt för speltestare vad det är som ska utvärderas. Om det är för många aspekter av spelet som kan kommenteras är risken att svaren blir svåra att systematisera. Prototypen bör alltså kännas färdig i de delar som inte ska bedömas.
6.4 Prototyp 2
Den andra prototypen skapades för att testa ljudet och utseendet av spelet. Den var alltså inte baserad på resultat av användartest 1. Vi ville testa ljud från olika genrer och instrument på samma föremål för att ta reda på vilka som passade bäst. Vi testade tre olika typer av ljud; instrument, chiptune och ljudeffekter. Vi ville även se om spelarna intuitivt kunde associera former och föremål i spelet med specifika ljud. Ett tjockt spöke spelade till exempel mörkare noter än ett smalt spöke. Vi testade även fyra olika kameravinklar för att ta reda på vilken spelarna föredrog:
30 ● Fågelperspektiv - kameran tittar ner och följer spelaren rakt uppifrån.
● Isometriskt perspektiv - kameran tittar ner och följer spelaren snett uppifrån. ● Förstapersonsperspektiv - kameran är placerad från spelkaraktärens perspektiv.
Riktning styrs av musen.
● Tredjepersonsperspektiv - kameran är placerad bakom spelkaraktären och kan flyttas runt karaktären med hjälp av musen.
Här förklarade Neven Kedza kontrollerna för spelarna och noterade svar från testare, Vedran Simicic gjorde intervjuerna och jag observerade spelarna. Jag spelade upp olika melodier på en separat dator beroende på vad spelaren gjorde. Detta gjordes för att slippa skapa flera olika versioner av samma scenario men med andra ljud.
Närvarande vid testet: Speltestare A, D och E. Vilken typ av ljud passar bäst?
Speltestare A och E tyckte mest om chiptune. Speltestare E tyckte att det passade bäst eftersom det påminde honom om när han var liten och spelade SNES. Speltestare D tyckte inte om något av alternativen men tyckte att ljudeffekterna var sämst.
Vilken kameravinkel är lämpligast?
Speltestare A och E tyckte att isometriskt perspektiv fungerade bäst på grund av översikten. Speltestare A tyckte inte att förstapersonsvy funkade särskilt bra eftersom man inte kunde se när spelarens karaktär attackerade. Speltestare E tyckte inte om första- eller tredjepersonsvyn eftersom att världen såg för ful ut. Speltestare D tyckte om fågelperspektivet och det isometriska perspektivet eftersom man fick bra överblick och eftersom spelaren inte behövde använda musen för att styra kameran.
Kunde du förvänta dig ungefär hur ett monster lät beroende på utseendet?
Speltestare A berättade att det var lätt att förutse hur en viss typ av monster lät beroende på storlek, förutsatt att man hade slagit på liknande monster tidigare. Det var lätt att förstå hur man gjorde mörkare och ljusare toner, men inte hur grundtonerna påverkades av fiendernas utseende. Speltestare D lade inte märke till någon skillnad bland fienderna. Speltestare E la märke till storleken på fienderna men tänkte inte på att de skulle påverka ljudet.
31
Övrigt?
Speltestare E tyckte det var tråkigt att allt i spelvärlden stod still. Han tyckte att det hade varit mer intressant om fienderna rörde på sig.
Analys av användartest 2
Till viss del hade kommentarer om brist på variation i ljud minskat, dock förmodligen för att vi testade många olika typer av ljud. Fokus lades istället på kameran och då oundvikligen också på spelets grafik. Det stod klart att spelet kändes stelt på grund av att den enda respons man fick var ljud. En analys gjordes utifrån de olika kameravinklarna och det konstaterades att den främsta anledningen till användarnas åsikter om de egenskaper som var viktigast för perspektivet i spelet var översikten. Det är värt att poängtera att vi inte fick kommentarer om kameran innan det att vi tog upp frågor om den under våra tester, men när vi väl gjorde det var det lätt för våra användare att tycka till. Deltagarna hade även svårt för att förstå poängen med att veta hur monster skulle låta baserat på utseende. Som helhet gick dock användartestet bättre än det första. Det verkade som det var lättare för deltagarna att fokusera på de aspekter vi lyfte fram med frågor. Det var kanske lättare för deltagare att hålla sig till att prata om ljud eller grafik än det var att prata om interaktionen.
6.5 Prototyp 3
Den tredje prototypen skapades utifrån feedbacken vi fick från de första två prototyperna, med mål att utvärdera användbarheten i vårt spel. Vi valde att använda oss av den isometriska kameravinkeln och den enklare och mer FPS-anpassade interaktionen med spelvärlden, d.v.s. att skjuta på föremål. Det bestämdes att spelets ljud skulle vara chiptunes, eftersom det var bättre kopplat till en spelmiljö. Vi lade mindre fokus på att koppla utseende och färg av monster till specifika ljud och mer på att ha en större variation av ljud. Det var viktigt att identifiera våra användares förväntningar, och vilka problem som uppstod för dem vid bruk av vårt spel.
Här förklarade Vedran Simicic kontrollerna för spelarna och noterade svar från testare, Neven Kedza observerade och jag utförde intervjun.
32
Kan enkla uppgifter i spelet utföras utan problem? Vad är oklart?
Speltestare A tyckte att uppgifterna kunde utföras, men att bristen på en förklaring av spelets funktioner vid starten av spelet kunde förstöra upplevelsen för andra. Speltestare B tyckte att spelets mål var oklart eftersom man inte kunde dela musiken med andra, och inget hände i spelet när man skapat ett musikstycke. Speltestare F tyckte att det var svårt att skapa musik och att målen var oklara. Speltestare G ansåg att det var lätt att förstå spelets funktioner, med tanke på att det inte fanns särskilt många. Speltestare G uttryckte också att det var oklart vilka föremål som kunde göra ljud.
Är spelet lämpligt för musikskapande?
Alla speltestare ansåg att det inte fanns tillräckligt mycket valmöjligheter för olika ljud. Samtliga speltestare tyckte att det var svårt att få flera olika ljud att spela i samma takt. Speltestare G och F tyckte att interaktionen fungerade dåligt.
Är det lätt att navigera i spelvärlden? Kan man hitta till olika platser i spelvärlden?
Speltestare A och G tyckte att det var bra att man behövde upptäcka allting själv. Speltestare B och F tyckte att det behövdes något hjälpmedel, som en karta.
Övrigt?
Spelare G tyckte att man borde kunna plocka upp föremål och flytta på dem. Speltestare F tyckte att det var tråkigt att ingenting rörde på sig förutom huvudkaraktären.
Analys av användartest 3
Det var tydligt att det fanns oklarheter som behövde åtgärdas i spelets design, främst med målet med spelet (som var menat att inte vara definierat), men också med vad man kunde interagera med i spelvärlden. Kanske hade dessa kunnat klargöras med en bättre introduktion av spelet och dess funktioner. Det var fortfarande ganska svårt att skapa musik med spelet, och det behövdes en förbättring av interaktionen.
33
6.6 Prototyp 4
Användartestandet ledde fram till en fjärde prototyp, med ett antal förbättringar från de tidigare versionerna av spelet. Utöver analyserna från testerna behandlade denna prototyp mycket av det som vi själva observerat under användartesterna. Bland annat kände vi i gruppen att mycket av upplevelsen försämrades på grund av spelets utseende, och den allt för statiska spelvärlden. För att skifta fokus från den dåliga grafiken till interaktionen med spelet, och behålla den översikt som kändes essentiell för användarna, beslutades det att använda ett fågelperspektiv och en tvådimensionell spelvärld, där statiska föremål och byggnader är något som användare förväntar sig. Även om utformandet av testerna för prototyp 2 inte var i direkt enlighet med Pagulayan et. al.’s Critical Facet Playtest (se kapitel 5.3) är det värt att uppmärksamma att slutsatserna ändå var ganska likartade. Vi lade till effekter för interaktioner med föremål och gav spelare möjlighet att flytta på dessa. Vi experimenterade också med hastigheten som ”skott” rörde sig i, vilket gav spelare möjlighet att skapa kortare melodier genom att klicka i rytm. Ännu en gång använde vi oss av placeholders från Unity-tutorials.
Figur 4. Prototyp 4 - Utseende, effekter och flyttande av föremål
Figur 4 visar hur prototypen såg ut, samt hur interaktionen med föremål i spelet fungerade (till vänster spelas upp ett ljud, och till höger flyttar karaktären på ett föremål).
34
7. Slutdiskussion
Arbetet har utgått ifrån två centrala frågeställningar.
1. Vad säger forskning som gjorts inom speldesign om användarcentrerad design? 2. Hur mycket kan man använda sig av tillvägagångssättet som en oberoende
utvecklare?
Som avslutning på detta arbete kommer jag här diskutera dessa frågor. Jag kommer också presentera ett antal råd som oberoende utvecklare kan dra användning av i utvecklandet av spel.
Jag har påpekat att användarcentrerad design är ett centralt område inom både interaktions- och speldesign. Min forskningsgenomgång har dock visat att det finns ganska lite litteratur som belyser området, och att den kunskap som finns kanske inte används i den utsträckning som den borde. Det är tydligt att usability och user experience är två centrala begrepp för tillvägagångssättet, och att det särskilt har funnits ett behov för user experience inom speldesign. Men kanske viktigare än båda dessa begrepp är hur man kan gå tillväga, istället för vad man kan fokusera på. Playtest-metoden som Davis et. al. (2005) har jobbat fram är ett bra exempel på hur man kan arbeta med användarcentrerad design. De lägger ner mycket mer kraft på att skapa en systematik kring testande, för att kunna få ut mer av varje test. Detta innebär också att ju mer man testar, desto större blir ens databas med vilken man kan göra jämförelser, och desto mer angripbara (actionable) blir resultaten från de tester som man utför. Detta går också att se på den iterativa metod som Fullerton (2008) förespråkar. Utan denna systematik blir det svårt att dra några slutsatser ifrån de tester som man utför.
Det första rådet är alltså: Det är inte bara viktigt att veta vad man testar för, utan också hur man testar för det.
Hur kan man då använda sig av användarcentrerad design som en oberoende utvecklare? Det är kanske inte alltid så lätt som det verkar att applicera alla metoder på de sätt som de är ämnade att användas, vilket gör att den systematiska inhämtning av
35 testares åsikter och uppfattningar som man försöker åstadkomma blir mycket svårare att utföra. Det som blir mest problematiskt är:
1. Urvalet representerar kanske inte alltid målgruppen. 2. Det finns inte tillräckligt många deltagare under testerna. 3. Miljön kan ofta vara okontrollerad.
4. Low-fi-prototyper bidrar till en betydligt försämrad spelupplevelse.
Jag tror att det senare är den främsta anledningen till varför våra användartester var svåra att göra analyser ifrån. Det var ganska uppenbart att det blev svårt för användare att engagera sig i spelet när det inte var färdigt, och detta gjorde att deltagarna inte riktigt levde sig in i spelet under spel-sessionen. Som interaktionsdesigner måste man tänka på detta, eftersom en stor del av interaktionsdesign handlar om att börja tidigt med testande av idéer och prototyper. Jag tror att man inom speldesign ska avvakta med användartester under konceptutvecklingen till den tidpunkt man har en fungerande version av sitt spel. Istället bör man lägga sin tid på att utveckla spelidén.
Det andra rådet är alltså: Prioritera utvecklingen av spelet fram till den tidpunkt då man har färdigställt alla grundliga interaktioner med spelet.
Jag har pekat på hur metoderna jag beskriver i teori-avsnittet kan vara svåra att följa som oberoende utvecklare, och att det kan handla mycket om att dra nytta av resurser som man inte har tillgång till utan stöd av utgivare eller ett större företag. Som oberoende utvecklare har man inte stora databaser med statistik kring vad som gör ett bra spel, eller tillräckligt stort intresse ifrån potentiella användare för att utforma tester med större urval. Däremot har man förhoppningsvis en närmare anknytning till spelanvändare i form av vänner som har intresse, kunskap, och idéer om spel. Denna informalitet kan vara mycket värdefull under utvecklingen av ett spelkoncept.
Det tredje rådet lyder alltså: Ta till vara det öppna kommunikationsklimatet i de vänskapskretsar som du befinner dig inom när du genomför användarstudier, särskilt under konceptutvecklingsstadiet.
36 Jag har diskuterat användarcentrerad design men med utgångspunkt i den sammanställning som jag gjort kan man dock fråga sig själv hur mycket man egentligen involverar användaren i processen. Designar man verkligen med användaren, eller designar man för denne? Självklart lägger man stor vikt vid de åsikter som förs fram under test-fasen, och många förbättringar i spel kommer tack vare användaren. Men åsikter förändras, och användare har ofta väldigt olika uppfattningar. Skulle det då vara bättre att involvera användare genom hela designprocessen, och vad blir designerns roll under utvecklingen i så fall? Jag tror att det är viktigt att kunna överföra sina användares åsikter och uppfattningar till den slutgiltiga produkten, men det är också viktigt att kunna överraska sina konsumenter. Som designer måste man vara öppen för synpunkter, men man måste också ha någon form av kompetens som andra inte har. Det fjärde rådet är: Lyssna på dina användare, men lämna inte över designrollen till andra.
I de fall som företag faktiskt designar med användare, handlar det framför allt om modding. Och snarare än att designa med användarna, låter man de göra lite hur de vill, eftersom det inte påverkar originalet (mods fungerar som tillägg). Däremot finns det många exempel på spelidéer som utvecklats från att vara mods till att bli fristående spel. DotA (Defense of the Ancients) är kanske det bästa exemplet på ett sådant spel, men även andra populära spelserier som Team Fortress eller Red Orchestra började en gång i tiden som mods. Detta är egentligen det som bäst definieras som design med användare inom spelindustrin: Företag erkänner en bra idé och erbjuder moddare möjligheten att förverkliga den som ett fristående spel. Trots detta är det kanske inte så lämpligt för oberoende utvecklare att erbjuda mod-support för sina egna spel, eftersom man troligen inte lockar tillräckligt många användare med kunskap inom speldesign eller modding. Modding är snarare ett tillvägagångssätt för att bli känd som oberoende utvecklare. En designprincip som däremot kan vara viktig att upprätthålla är att ge användare möjlighet att förändra vissa aspekter av ett spel, såsom grafik och gränssnitt. Bland annat gav succé-spelet Minecraft användare denna möjlighet, och det är en stor anledning till varför så många spelare lockas till det.
Det femte rådet är: Öppna upp delar av spelets utveckling för förändring av användare (ge valmöjligheter utanför spelets ramar).
