simonmilfred

[simonmilfred]

[DA] Spildesign til unikke kontekster 9: Kritik af konceptet leveret af eksperter

Som et sidste designtræk i processen sendte jeg mit koncept ud til kritik. Kritikerne var alle i industrien: Én spildesigner fra Funday Factory samt 3 personer fra Ideas Lab alle tilknyttet udviklingen af spil. Det, jeg sendte til dem, var en PDF-version af mit blog-indlæg om det endelige koncept, dog med tilføjelsen af visionen fra indlægget før det.

Jeg bad dem give mig kritik på spildesignet, dog blev meget af kritikken møntet på udformningen af, og det skriftlige indhold i, dokumentet, hvilket delvis må skyldes hvad jeg sendte dem—og hvad jeg ikke sendte dem—og formodentlig også at de alle vidste, at det var en del af et specialeprojekt. Min forhåbning var, at kritikken ville være mere designfokuseret, ikke at sige at der ikke var sådan feedback også.

Én af de mere skriftlige kritikker, som to af kritikkerne begge pointerede, var den manglende argumentation for mine designvalg. Set i retrospekt er dette forståeligt, da de jo ikke havde læst hele min blog, og af gode grunde ikke har læst mit speciale, og dette gør det selvfølgelig også svært at kritisere mine valg, da de jo netop så blot vil være subjektive holdninger—ganske vist baseret i deres erfaring. Dette var klart en fejl jeg gjorde, og havde jeg haft tiden, så havde jeg indskrevet argumenterne i dokumentet og sendt det ud igen. Desværre må jeg prioritere min tid og vælger ikke at gøre dette.

En anden kritik mere fokuseret på udformningen var en ændring af struktur i dokumentet. Dette var dog ud fra industristandarder og ud fra antagelsen, at dokumentet var ment til at være et reelt spilkonceptdokument, hvor dokumentet i virkeligheden blev skrevet til et blog format. Ikke desto mindre havde kritikken valide pointer, såsom at skrive i tredjeperson og at starte med et breakdown af hvad spillet går ud på og dets features, for først bagefter at beskrive situationen og status for projektet hvis overhovedet. Dog vil jeg af hensyn til kontinuitet ikke ændre disse ting. Det blev også foreslået at skrive på engelsk, da det er mere alment i computerspilindustrien, men da mit speciale er skrevet på dansk vil jeg også have konceptet stående på dansk.

Et social spil

Én af kritikkerne påpegede en mulig faldgruppe i spillet, nemlig at spillet er løsbart i sig selv:

“It is a social deduction game so the most important part of the game is that it has to be unsolveable within the game itself. Your decisions should be made on claims from other players and fractured information, if it becomes solveable, then the players do not need to physically or verbally interact, which isn't what you want.”

Med andre ord er det vigtigt, at de sociale interaktioner udenfor det digitale spil er nødvendige, eller i hvert fald giver en stor fordel. Dette er en god pointe, og det vil være nødvendigt at teste dette i spiltest. Omvendt kan netop dette spil, i netop denne situation, ikke være afhængigt af menneske-til-menneske interaktioner hele tiden, da det jo netop er tiltænkt down-time: Hvis kun én spiller er ude, kan han så ikke spille spillet? Det er altså en balance som skal afstemmes, hvilket ville udgøre de næste trin af en hypotetisk designproces.

Interaktioner i spillet

En anden gjorde sig observationen, at flere af spillets nuværende handlinger er uden meget observation og foreslog, at i stedet for at et mordoffer bare har 50% chance for at se morderens navn, så kunne morderen blive præsenteret som et anagram, som spilleren kan løse. Lignende kunne gøres ved handlingen “undersøg” og ved pensionshandlingen, hvor der i det nuværende koncept blot er ventetid, for at gøre spillet mere meningsfyldt. Dog har anagrammet den ulempe, at forskellige navnelængder gør det nemmere eller sværere at gætte dem, men anagrammet kunne selvfølgelig også være et vilkårligt ord, som efter løsning kunne låse op for navnet.

Uanset hvad mener jeg, at det er en væsentlig pointe, at gøre nogle af handlingerne mere interaktive, og dette kunne om noget kombineres med den anden pointe om de sociale interaktioner: Gøre det sociale eller fysiske vigtigt for handlingerne.

Den sidste kritik, som jeg modtog, var mere fokuseret på interface end spillet selv: At flytte ikonet for indstillinger op i toppen, så det kun er de tre ikoner, som spillerne gør brug af det meste af tiden, som er i bunden, og det mere “kedelige” er gemt væk.

Dette konkluderer den modtagede kritik, som i en hypotetisk fortsættelse af processen ville lede mine næste designtræk, og som vil danne basis for refleksion i specialet.

[simonmilfred]

[DA] Spildesign til unikke kontekster 8: LAN-kartellet - Et spilkoncept

Følgende koncept er netop det: Et koncept, og derfor har jeg valgt at holde skitserne simple og i gråtoner, hvor et færdigt spil selvfølgelig ville være stiliseret og gøre brug af farver.

Mit spilkoncept udformer sig som en applikation til LAN-deltagernes mobiltelefoner, således at det kan spilles sideløbende med de andre spil som spilles, uanset om det er på computere, på konsol, eller om der er tale om analoge spil. Spildata skal håndteres på en server, således at spillere kan lukke applikationen når de har lyst, uden at falde ud af spillet—det skal altså kunne gå ind i spillet igen og fortsætte hvor de slap. Serveren kan eventuelt køre på en af computerne til LAN-festen. Hvorvidt notifikationer på mobilen skal tages i brug når spillet er lukket kan være op til den enkelte spiller.

For at differentiere mellem spillere skal spillerne have hver deres brugernavn, men disse kan være definerede per server/nyt spil, da dette spilkoncept ikke lægger op til et behov for at gemme data mellem sessioner. Derudover skal hver spiller have et tilfældigt persona-navn, som er det navn andre spillere kan se, og som ændrer sig hver gang de dør eller pensionerer sig i spillet (mere om det senere i konceptbeskrivelsen). Disse informationer skal altid stå i toppen af skærmbilledet sammen med hvor mange penge spilleren har til rådighed (virtuelle penge).

Scroller spilleren helt ned i bunden af spillet (hvis der er mange informationer at vise, ellers bare i bunden af skærmbilledet) skal der fremvise serverens IP, således at man let kan fortælle den til andre spillere så de kan deltage i spillet. Den behøver dog ikke at være i toppen, da det ikke er en information som skal bruges hele tiden. Dog er der i bunden—fastsat helt forneden—fire menuknapper som refererer til spillets tre hovedsider samt en hovedmenu hvor spillet kan afsluttes og indstillinger kan indstilles.

De tre hovedsider repræsenterer applikationer på en mobiltelefon, og er “kontaktlisten”, “bank”, og “pension” hvoraf den tredje selvfølgelig ikke er baseret på en reel applikation men i stedet på en typisk highscore liste.

Kontaktliste

På kontaktlisten skal spilleren kunne se samtlige personaer der har været i spil, på nær dem som er gået på pension, og dem som spilleren ved er døde. Ved at trykke på en kontakt, skal spilleren have en serie af valgmuligheder: “Snigmyrd” for at forsøge at dræbe den anden persona, “lej mord” for at udlove en dusør henover en tidsperiode og “undersøg” for at finde ud af, om de stadig er i live, og hvis de er, hvor mange penge de har, og hvilken bruger der står bag personaen.

Snigmyrd

Når en spiller (”snigmorderen”) dræber en anden spiller (”offeret”), så dukker snigmorderens navn med 50% chance op på offerets skærm (hvilket symboliserer at en fiktiv “nogen” så det) indtil de vælger at tilslutte sig spillet igen som en ny persona. Dette betyder at offeret kan sige dette højt, og alle andre ved så, hvem der muligvis er værd at gå efter—dette er helt okay og meningen i dette spil. Derudover går hele offerets formue som basis* til snigmorderen, hvilket igen giver incitament for andre til at prøve at dræbe ham. Dette gør det farligt for en spiller at dræbe andre hele tiden, med mindre spilleren er meget heldig. Ligeledes er der 10% chance for at det slår helt fejl—offeret bliver ikke dræbt, men får at vide hvem der har forsøgt at gøre det. Offeret kan i 30 sekunder herefter ikke blive angrebet af snigmorderen.

*Hvis snigmorderen er blevet lejet til mordet (Lej mord), så går halvdelen af formuen til denne anonyme person, og halvdelen går til snigmorderen, som dertil modtager den udlovede dusør.

Hvis spilleren snigmorderen forsøger at dræbe allerede er død, så får spilleren ikke noget ud af det—medmindre han var blevet hyret. Hvis dette er tilfældet får han sin hyre, men der er ingen formue at dele. Men nu ved begge spillere at denne person er død, og personaen bliver fjernet fra de indblandedes kontaktlister.

Lej mord

En spiller kan til hver en tid hyre én til at snigmyrde en anden (medmindre han ikke har nogle penge at bruge/alle spillerens penge er reserveret). Spilleren trykker på personaen, som han ønsker at hyre som snigmorder, og en ny liste dukker herefter op, hvor han kan vælge, hvem der skal dræbes. Herefter vælger spilleren dusørens størrelse, og den tid den valgte lejemorder har til at gøre det. Pengene vil blive reserveret på spillerens konto, og hvis tiden udløber, er de igen hans. Men hvis lejemorderen vælger at acceptere*, og de dræber en anden for spilleren, så får de selvfølgelig pengene så snart handlingen er gjort, og de deler som før beskrevet formuen (hvis ikke han allerede var død).

*Når en spiller bliver hyret, dukker en besked op om jobbet, og spilleren kan vælge at acceptere. Hvis han accepterer, er der ingen straf for ikke at gøre det, og der bliver aldrig sendt besked tilbage med spillerens svar. Spilleren kan dog ikke ombestemme sig, så hvis han siger ja, men så hellere vil dræbe målet selvstændigt, så må han vente til tilbudet udløber. Ligeledes, hvis han siger nej, kan han ikke ombestemme sig.

Hvis en spiller accepterer, men han allerede ved, at målet allerede er dødt, så modtager han dusøren det øjeblik han accepterer.

Når en spiller accepterer at dræbe nogen, vil en bar dukke op ved målet i lejemorderens kontaktliste, så han kan se hvor længe han har tilbage. Ligeledes vil der stå hvor mange penge dusøren er på. I lejerens kontaktliste vil lejemorderen have “lejet” stående ved sit navn samt hvor lang tid der er tilbage.

Undersøg

Spilleren kan undersøge forskellige personaer for at rydde ud i sin kontaktliste, eller for at finde ud af, om de er værd at snigmyrde. At undersøge er en proces der tager tid, og som stopper den undersøgende spiller fra at gøre andre ting i mellemtiden (med mindre de afbryder). En overlægningsgrafik vil dukke op med fremgangen og hvad spilleren har fundet ud af. Der er her en afbryder knap, så spilleren kan stoppe når han vil. Hvis noget sker i mellemtiden (spilleren dør, målet går på pension eller dør—alt efter hvor langt den undersøgende er), så afbryder spillet automatisk handlingen.

De første 15 sekunder af efterforskningen går ud på at finde personen. Når denne tid er gået, får spilleren at vide, om målet lever eller er dødt. Efter dette stykke tid vil den undersøgende blive afbrudt hvis de dør, da han jo holder øje med dem. Ligeledes afbrydes det selvfølgelig hvis han finder ud af at de er døde, eller når som helst de lykkedes i at gå på pension.

Efter i alt (altså inklusiv de 15 sekunder) 1 minut, finder den undersøgende spiller ud af hvor mange penge de har. Til gengæld får målet også besked på, at de føler sig forfulgt. Målet ved endnu ikke hvem der undersøger dem, men det kan være, at det får dem til at gå på pension.

Efter i alt 2 minutter, finder den undersøgende ud af, hvilken bruger der står bag personaen, men til gengæld finder de også ud af, at det er dig som efterforsker dem (kun din persona).

Bank

I banken kan spilleren se sin økonomi. Han kan se både sit rådigheds- og totalbeløb samt sin historik for overførsler. Det fungerer altså som en form for oversigt over spillerens aktiviteter.

Pension

Når spillerens formue er større end den tidlige har været, kan han vælge at gå på pension. Det vil sige, at han registrerer sin score som en highscore og starter forfra under en ny persona. Dette er en proces som varer 20 sekunder, og det øjeblik spilleren starter den, notificeres andre aktive spillere om, at en spiller (han er anonym) er ved at gå på pension. Dette giver dem en sidste chance for at stoppe spilleren.

Pensionssiden viser alle pensionerede personaer. Når en spiller tilføjer en ny highscore slettes den tidligere (hvis spilleren allerede har en).

Situation og samtale

Et vigtigt aspekt af spillet skal være, at spillerne sidder i samme rum og kan snakke sammen. Hvis en spiller finder ud af, hvem en anden spiller er, så kan han sige det højt for at gøre situationen sværere for den anden spiller. Han kan også lyve, eller han kan vælge at bevise sit udsagn ved at vise sin skærm, men så viser han også hvem han er—medmindre han selvfølgelig dække denne del af skærmen til. Spillere kan kigge hinanden over skuldrende og få informationer på denne måde, eller de kan udnytte at en person er på toilet eller spiller et spil i en turnering til at lave et midlertidigt mere sikkert mord, hvor spilleren er gået på pension når den myrdede når tilbage for at fortælle hvem der gjorde det.

Viderebyggelse af konceptet

Ovenstående er basisspilkonceptet, og det kan videreudvikles på forskellige måder, hvilket kan balancere spillet og gøre det endnu mere interessant. Disse viderebyggelser vil jeg dog vente med at implementere til når basiskonceptet er blevet testet, og da jeg ikke tester spillet, skal disse viderebyggelser anses som mulige, fremtidige design træk, alt efter hvad en test ville finde ud af—og selvfølgelig ikke de eneste mulige træk.

Klassesystem

Én retning der kan skabe adspredelse ville være muligheden for at vælge en klasse når en ny persona laves. Disse klasser ville kunne ændre spillets balance—en spiller kunne for eksempel have en dedikeret lejemorder-klasse, hvor chancen for at blive opdaget og fejle er minimeret, men hvor spilleren til gengæld kun kan dræbe hvis han er blevet hyret, eller man kan have en mafiaboss: Alle kan se hvem brugeren er, men der er større risiko for at fejle imod ham. Man kan ligeledes udbygge pengesystemet med det, og have en bogholder-klasse, som er dårligere til at dræbe, men som generere penge lige så stille. Der er mange muligheder, men alle skal selvfølgelig testes og afbalanceres i forhold til hinanden og grundspillet.

Køb

En anden retning ville være at udbygge banken og tillade spilleren at købe også. Disse køb ville gøre indhug på deres økonomi, men vil til gengæld give fordele. Man kunne for eksempel gøre det muligt, at købe et nyt alias, så en spiller kan skjule sig efter at være blevet opdaget. Eller man ville måske kunne hyre bodyguards hvilket kunne beskytte en spiller fra mord-forsøg. En spiller kunne måske betale for at flytte penge over i en arvefond, hvormed disse penge er sikre og ude af spillerens hænder, og bliver givet til spillerens næste alias, eller blot gøre det muligt at putte penge i banken, og disse penge er så bare ikke brugbare, men hvis spilleren dør, så forsvinder de bare? I dette tilfælde skulle det måske også være nødvendigt at tage pengene ud sin konto for at gå på pension, hvilket kan gøre spilleren kortvarigt skrøbelig. Igen skal dette dog testes og balanceres, så spillerne ikke bare konstant lægger penge til side uden risiko—et modkøb til dette (eller endnu en klasse, hvis de to systemer begge er taget i brug) kunne være muligheden for at røve banken, og dermed stjæle fra alle som benytter sig af den.

Næste skridt

Dette udgør mit endelige spilkoncept for specialet, men som en forberedelse til videre design træk vil konceptet blive sendt ud til kritik, og denne kritik vil blive samlet i mit næste opslag.

[simonmilfred]

INFP-A: “The Mediator” (16Personalities personality typing)

I tried out the 16Personalities test to check what it have to say about my personality, and it categorized me as “the mediator”, which is the personality of only 4% of the world population.

Below is the introductory description of the personality type, and you can read more about it here, check out my exact score or try out the test yourself on their website.

Mediator personalities are true idealists, always looking for the hint of good in even the worst of people and events, searching for ways to make things better. While they may be perceived as calm, reserved, or even shy, Mediators have an inner flame and passion that can truly shine. Comprising just 4% of the population, the risk of feeling misunderstood is unfortunately high for the Mediator personality type – but when they find like-minded people to spend their time with, the harmony they feel will be a fountain of joy and inspiration. 

Being a part of the Diplomat Role group, Mediators are guided by their principles, rather than by logic (Analysts), excitement (Explorers), or practicality (Sentinels). When deciding how to move forward, they will look to honor, beauty, morality and virtue – Mediators are led by the purity of their intent, not rewards and punishments. People who share the Mediator personality type are proud of this quality, and rightly so, but not everyone understands the drive behind these feelings, and it can lead to isolation.

According to the website, examples of famous people categorized as this type are William Shakespeare, J.R.R. Tolkien, Tom Hiddleston, and a bunch more (also quite a few fictional characters). I am not typically doing a lot of personality tests, but I had heard good things about this one, and it is always nice to know good tests especially when working user centered design processes, as it can open up for ways to look at the users of a product.

It is a quite in-depth personality test and while the results where not 100% spot on (they never are), it was quite descriptive, and the writing did not feel like the typical fits-on-everybody which is often used in not-so-great personality tests or horoscopes.

[simonmilfred]

[DA] Spildesign til unikke kontekster 7: Udvikling af designproblem og mål for spillernes oplevelse

Følgende er en refleksion over den indsamlede og analyserede data, og hvilken retning designet skal tage. Det er altså i dette opslag, at jeg indsnævrer til et specifikt designproblem (altså, ikke et “problem” i normal forstand, men derimod noget i situationen, jeg vil forsøge at ændre), samt opstiller målene for spilleroplevelsen. Jeg vil gøre dette ved at belyse diverse, mulige problemer, og fremstille en vurdering af, hvad jeg om muligt får ud af at løse de problemer. Dette er med formålet at finde det mest interessante problem at løse. Generelle problematikker eller andet nøgledata som kan optræde i flere designproblemer vil blive fremhævet undervejs. Ligeledes vil jeg sørge for at opsummere hvert designproblem i én sætning og sætte denne i fed kursiv.

Første indsnævring—som kort beskrevet i et tidligere oplæg—er, at mit design skal være tiltænkt de mindre, private LAN-fester. Denne vil jeg nu slå nærmere fast som LAN-fester med 10-35 deltagere, altså ikke hall-LANs. Dette udgør lige under halvdelen af besvarelserne på mit spørgeskema—af dem som har deltaget i en LAN-fest. Det er desuden ikke at sige, at mit spilkoncept ikke må være spilbart til større LAN-fester, det er bare ikke et krav.

Mulige designproblemer

Den store fællesnæver ved mine observationer, mit spørgeskema, samt “Gaming at a LAN Event”-teksten, er at deltagerne er tilhængere af spil, hvor to hold bekæmper hinanden enten balanceret eller asymmetrisk. Det ville være muligt at designe et sådan spil. Dog er der allerede mange af disse spil på markedet, og at antage at jeg kan gøre det bedre end de spil gør det, går udover mit ego. Mit spilkoncept må helst ikke være en kopi af et andet spil—det skal tilbyde noget nyt. Men dette udelukker ikke denne vinkling: Jeg kan gøre det anderledes, hvilket LAN-situationen tillader mig. Mange af denne type spil er lavet til at blive spillet online, hvor hver spiller har hver deres skærmbillede, og hvor man ikke nødvendigvis har en fordel ved at sidde i samme lokale. Men LAN-festen tilbyder unikke muligheder: Hver spillers skærmbilleder er til stede i samme lokale, spillerne kan tale direkte til hinanden og de fleste hvis ikke alle deltagere har en sekundær enhed som kan tages i brug i form af deres mobiltelefoner. Én retning kunne være, at bruge mobiltelefonerne som kontrollere, og koble alle computerskærme sammen til ét spilbart rum. Dette er dog ikke uden problemer. Man kan ikke være sikker på at alle vil være med og der er ofte ikke meget plads at løbe rundt på. For meget fysisk løben rundt i lokalet kan være til gene for andre. Dette skal være i mente, hvis denne designretning skal følges. Opsummeret er designproblemet: “LAN-festen giver unikke muligheder for interaktion i spillet og mellem spillere, hvilket kan anvendes til at lave et anderledes spil.” Jeg vil ikke nødvendigvis begrænse problemet til et hold-mod-hold spil, i hvert fald ikke før jeg er låst fast på denne retning.

Det, at spillerne kan tale direkte til hinanden, kan også være medskabende for nogle spilidéer, især i et kompetitivt spil. Man kunne spille hold mod hinanden, hvor spillerne har forskellige roller, og derfor må snakke sammen udenom spillet, men samtidig passe på ikke at give for mange informationer til det/de andet/andre hold. Et simpelt eksempel på dette kunne være, at ét hold var indbrudstyve, og et andet var vagter for det sted tyvene skal bryde ind. Én spiller på hvert hold styrer en avatar som kan bevæge sig rundt i banen, og øvrige spillere har adgang til sikkerhedskameraer spredt ud i banen. Tyvens hold skal så guide tyven forbi vagten uden at blive opdaget ved at holde øje med tyvens og vagtens position, og ligeledes skulle vagtens hold guide vagten hen for at fange tyven. Dette koncept har sine faldgruber, men det illustrerer den overordnede designretning: “Spillerne kan arbejde imod hinanden i hold, men hvor hver deltage på holdet har forskellige roller og evner for at skabe noget asymmetri og variation og udnytte muligheden for samtale.”

En tredje mulighed kunne være at spille på LAN-festens transformative natur og lave et alternativt spil og spilrum. Dette kunne være i form af en arkademaskine eller et spil som spilles omkring én skærm, men med en alternativ styreform. I LAN-festens ånd ville dette betyde at man skulle medbringe og opstille dette, men omvendt medbringer deltagerne i forvejen computere, og det er irriterende at skulle medbringe for meget. Men opsummeret er denne idén til et designproblem altså, at ”Man kan opbygge et alternativ spilrum udover et spil alene for at skabe noget afveksling for deltagerne.”

I mit spørgeskema blev jeg gjort opmærksom på, at der i nogle spil kan være “down-time”, for eksempel når man er død, og venter på at rundten er ovre. Det er godt at undgå eller fjerne down-time. Dette kunne også være et muligt designproblem, som muligvis ville kunne løses ved at lave et spil, som spilles parallelt med de øvrige spil. Her ville det være vigtigt, at man kan starte og afbryde spillet let. Mulige kilder for inspiration kunne være spil som Varulv—det analoge spil jeg så blive spillet til den første LAN-fest—da denne type spil kan spilles relativt hurtigt. Her kunne mobilen igen være en mulighed, og at deltagerne befinder sig i samme rum kunne igen blive aktuelt. ”Der er pauser mellem spil, og denne tid kan blive fyldt ud.”

Lignende den førnævnte, mulige designretning, kunne man undgå det digitale, og lave et meta-spil som ligeledes foregår sideløbende med de øvrige spil. Dog er der problematikken med denne type spil, at spil bundet op på sociale regler kan være sværere at administrere. Her ville designproblemet være det samme som det tidligere, men bare med et ikke-digitalt fokus.

Selvom størstedelen foretrækker versus-spil, er der stadig mange som rigtig godt kan lide at spille kooperative spil. Kooperative spil kan give en følelse af sammenhold, og ”At lave et kooperativt spil kan give afveksling fra de mere konkurrenceprægede tidspunkter.”

Jeg ved, at mine foreslag synes at blive beskrevet mere og mere kortfattet, men dette er alene fordi jeg ikke ønsker at gentage alle mulighederne som er beskrevet i tidligere forslag. Flere af disse muligheder fungere på tværs af flere designproblemer. Der er selvfølgelig mange flere retninger at bevæge sig, men jeg vil mene, at jeg har fået nedskrevet nogle af de både mere eller mindre åbenlyse retninger projektet kan gå, og det er på tide at få indsnævret.

En vej skal vælges

Men før vejen skal vælges, vil jeg kort opsummere de generelle problematikker og noter, som er værd at have i mente:

Mit spilkoncept må helst ikke være en kopi af et andet spil

Man kan ikke være sikker på at alle vil være med

der er ofte ikke meget plads at løbe rundt på.

det er irriterende at skulle medbringe for meget.

Det er godt at undgå eller fjerne down-time.

spil bundet op på sociale regler kan være sværere at administrere.

Hver spillers skærmbilleder er til stede i samme lokale

spillerne kan tale direkte til hinanden

de fleste hvis ikke alle deltagere har en sekundær enhed som kan tages i brug i form af deres mobiltelefoner

man kan starte og afbryde spillet let

Man kunne spille hold mod hinanden, hvor spillerne har forskellige roller

man kunne spille på LAN-festens transformative natur

Nogle af disse noter er selvfølgelig ikke gyldige for alle designproblemer, men de giver mig noget at tænke over, og jeg kan bruge dem til at italesætte hvad jeg især synes er vigtigt, og hvad mine undersøgelser har vist mig er vigtigt. Jeg synes, det allermest interessante punkt er pointen om down-time, og jeg tror, at det er der, at der er det største potentiale for noget unikt, men så er det også især vigtigt, at spillet kan startes og afbrydes let. Hertil tror jeg, at det, at man kan tale direkte med hinanden til en LAN-fest, kan åbne op for nogle spændende dynamikker, også selvom det åbner op for mere socialbundne regler. Da deltagerne sidder og spiller spil på deres computere, vil jeg mene at mobiltelefonen er den rette enhed for spillet, og det bliver dermed mindre vigtigt, at alle computerskærmbilleder er til stede i samme lokale—selvom spillet selvfølgelig sagtens kan gå på tværs af medier.

Designproblemet jeg vælger at bearbejde er altså, at ”der er pauser mellem spil, og denne tid kan blive fyldt ud.”

Mål for spillernes oplevelse

Det er allerede beskrevet implicit i de ovenstående problematikker og noter samt designproblemet selv, men jeg vil nu formalisere mine mål for spiloplevelsen i en form for vision:

Mit spil skal være et spil, som spillerne kan spille til en mindre LAN-fest i de pauser som opstår mellem spil eller runder i spil—den såkaldte “down-time”. Spillerne skal kunne tilkoble sig og afbryde spillet let og uden frustration, og det skal kunne være frivilligt for hver spiller at deltage i det. Spillet skal ikke være afhængigt af eksternt udstyr der skal medbringes, men skal benytte sig af de genstande, man kan forvente at finde til en LAN-fest. Ligesom spillet skal være baseret i LAN-festens implicitte genstande, skal spillet også være afhængigt at LAN-festens sociale opbygning: Det skal være en fordel at spille spillet i netop denne situation, hvor spillerne kan tale sammen direkte. Og slutteligt—netop i spillets integration i LAN-festen—skal spillet heller ikke være af generende natur, og det skal tage højde for, at der ikke nødvendigvis er meget plads at bevæge sig rundt på.

Næste skridt

Med en retning for mit spil og en række af krav, jeg gerne vil have at det opfylder, er næste skridt at designe spillet med alt dette i mente. Dette vil være mit næste og muligvis endelige opslag. Jeg vil gøre mit bedste for at beskrive designet i dybden og illustrere nogle af de situationer der kan opstå. Men trods at det vil være dybdegående, vil det stadig være et koncept der vil fremgå, og det vil ikke være testet.

[simonmilfred]

[DA] Spildesign til unikke kontekster 6: Rumlig analyse af LAN-fester.

Med basis i de arkitektoniske begreber præsenteret i kapitlet “Functionality” i Michael Nitsches Video Game Spaces. Image, Play and Structure in 3D Game Worlds, The MIT Press, London, England, 2008, vil jeg følgende lave en rumlig analyse af den generelle LAN-fest. Jeg vil basere dette i de tidligere observationer samt min gennemgang af teksten “Gaming at a LAN Event”. Om end Nitsche approprierer begreberne til at beskrive de digitale rum i spil, så anvender jeg dem her i noget der ligner deres originale brug, da det er et fysisk rum jeg undersøger.

LAN-festen som rum og sted

Jeg vil starte fra “toppen” med Christian Norberg-Schulz’ human-made space og natural space. På overordnet plan er det første der sker til en LAN-fest, at man gør rummet til et sted for LAN-festen. Ved de kæmpemæssige LAN-fester—dem med tusindvis af deltagere hvor telte slås op i naturen eller på marker magen til ved festivaller—kan man i bedste fald føre Norberg-Schulz’ koncept helt til døren: Et naturligt rum bliver gjort til et menneskeskabt rum. Men ved mindre LAN-fester er det mere typisk at det sker som ved de to LAN-fester jeg selv deltog i: Et menneskeskabt rum bliver transformeret. I begge tilfælde er det dog noget lignende som sker. Man præciserer, komplimenterer og skaber symboler af rummet, og det er ved at gøre dette, at rummet bliver et sted.

Et eksempel på en præcision kunne ses i den anden LAN-fest jeg besøgte: Hvor der var borde og stole og god plads, blev disse samlet til bordrækker. Hvor der var opsat en projektor blev der sat en Playstation 4 op, og der blev rykket en sofa derhen. Et lignende storskærms-setup så jeg også ved den første LAN-fest jeg observerede. Her var det blot en Switch der var tilsluttet, og på lignende vis var der gjort bordplads, soveplads, samt område for analoge spil hvor det gav mening.

Herunder er vedlagt de tidligere udviklede skitser for de to LAN-fester:

På lignende vis blev rummet også komplimenteret ved anden LAN-fest: Lys-sensorer blev dertil overdækket, således at belysningen blev mere neddæmpet og projektorens billede stod skarpere, således at rummet blev ændret til bedre at afforde Playstation 4 setup’et. Desuden medbragte flere deltagere stikdåser, for at gøre det muligt at samle deltagerne. Sidstenævnte var også gældende for den første LAN-fest, og for begge LAN-fester gjaldt det også, at deltagerne selv komplimenterer rummet ved at opsætte deres computere.

Visuelle karakteristika

Næste led er Francis Chings visuelle inddelinger. Især ved de store LAN-fester—men også ved de små—synes det at give mening at beskrive LAN-fester helt visuelt: Rækkerne af borde med opstillede computere kan beskrives som et datum som udgør et større hele, men det er også værd at skilre det mere præcist. De variable antal af bordrækker alt efter LAN-festens størrelse synes at medbringe et praktisk rytme af akser, som ofte er både symmetrisk og transformativ af natur. De er tæt pakkede, og fylde ved den første LAN-fest jeg deltog i, hele det rum de var opstillede i. Disse akser er fremhævet med lilla herunder på skitsen for den første LAN-fest.

Ligeledes var den første LAN-fest bestående af en sal delt i to: I den ene ende de adskillelige computere, i den anden ende sovesal. Salen var altså nærmest spejlet i to gøremål: Den aktive, spillende ende, og den afslappede, anden ende. En ende med struktur, og en ende i roligt kaos. Jeg har fremhævet denne akse herunder:

Helt i enden af sovesalen var der en desk, hvor bestilt mad blev placeret, endnu engang pegende på dette som en mere afslappet ende. Imellem disse to dele var en trappeopgang til en hems, hvoroppe analoge spil blev spillet, afskærmet fra resten af LAN-festen��dog ikke absolut—og fungerende som den spejlende akse mellem de to ender. På denne konstruktions væg vendende mod var storskærmene og sofaerne placeret, som en overgang til det afslappende område. Dette gave et hierarki af afslappethed og måske endda af vigtighed: Computer-enden var hvor der skete mest, og så kunne man bevæge sig mod den anden ende når man havde brug for forskellige grader af pause.

Modsat var den anden LAN-fest jeg observeret nærmest én akse, da der kun var én række af dobbelte borde, så deltagerne kunne sidde overfor hinanden. For enden af denne række af borde var så sofaen og projektoren. Dette gav ikke den samme følelse af hierarki, men gav derimod et indtryk af sammenhænge. Se skitsen herunder.

Ved begge LAN-fester observerede jeg desuden rummets transformative natur: Selvom rummet er delt op i forskellige dele, og for det meste af tiden er konsistente (illustreret som ”normalen” herunder), så skaber forskellige begivenheder i rummet transformationer. Når det er spisetid, bliver der gjort plads til spisning. Ved den første LAN-fest blev enden med soveområdet omdannet til spiseområde når folk spiste mad (”udvidet spiseområde” herunder), og ved den anden LAN-fest blev der skabt nye områder for spisning. Herefter transformerede rummene sig tilbage igen (”normalen” igen). Ligeledes blev både dele af computerområdet og Switch-sofaerne omdannet til arenaer for konkurrence ved den første LAN-fest (illustreret som ”turneringer” herunder). Igen transformerede rummet sig tilbage igen bagefter.

Normalen:

Udvidet spiseområde:

Tourneringer:

Dette leder til Kevin Lynchs cognitive maps. Hver deltager skaber sig et indre kort over LAN-festen, hvilket ligeledes er med til at gøre rummet til et sted. Når transformationerne finder sted, ændre de edges mellem områder som tidligere er etableret, og ligeledes gør de eksisterende paths. Computeropsætningen skaber et naturligt district og dikterer paths igennem det, men transformationerne bryder nogle gange disse op. Jeg vil ikke gå for meget i dybden med dette, men det er vigtigt at vide, at LAN-festens transformative natur ligeledes gør de kognitive kortlægninger foranderlige. Herunder er vedlagt eksempler på paths ved de to LAN-fester.

Endelige mønstre

Endelig kommer vi til Christopher Alexanders pattern language. Bordrækkerne med de opstillede computere kan siges at være en fællesnævner mellem de forskellige LAN-fester og et mønster, der er essentiel for LAN-fester, selvom størrelsen kan være markant forskellig. Det ekstreme yderpunkt af mønstret er hvad der lægger navn til de store LAN-fester, hall-LAN, og selvom jeg selv fokuserer på de mere intime, private LAN-fester, vil jeg derfor vælge at navngive dette mønster “computer-hallen”. Dette var området markeret med rødt i de originale optegninger:

Ved de fleste LAN-fester som varer mere end én aften, er der ligeledes også typisk et soveområde, ligesom jeg markerede med cyan i skitsen for den første LAN-fest. Dette kan altså siges tilsvarende at være en fællesnævner for LAN-fester med overnatning, dog kan man forestille sig, at der ikke nødvendigvis er sovepladser når det drejer sig om én nat. Ikke desto mindre er det et gyldigt og vigtigt mønster, da mit spørgeskema påpegede, at en stor del af LAN-fester foregår henover flere dage.

Jeg vil også vælge at kalde et mønster for “spiseområde”. Dette er ganske vist et midlertidigt sted, men det bliver ikke desto mindre genereret ved de fleste LAN-fester, da deltagerne jo skal have mad.

De resterende mønstre synes at være mere valgfri og er ikke nødvendigvis bestanddele i mange LAN-fester. Ikke desto mindre synes de at opstå hyppigt. Det første af disse vil jeg kalde “sofaspil” mønstret, hvilket er indtegnet med gul på begge skitser. Denne fordrer samspil på én større skærm, og giver dermed noget andet end computer-hallen hvor de fleste spil spilles online.

Den næste virker relativt unik for den første LAN-fest jeg observerede, så at kalde det et mønster i sig selv er måske overilet: Det analoge spilleområde markeret med grøn i skitsen. I stedet vil jeg måske slå denne sammen med “sofaspil” og omdøbe denne til “alternative spilleområder”.

Slutteligt er der “konkurrencepladser”, som opstår undervejs, og kan byde på turneringer eller lignende. Disse er nogle gange fysiske, men kan også eksistere fuldkomment i den digitale verden.

Næste skridt

Nu har jeg undersøgt domænet på forskellig vis, og mit næste skridt er nu at udvælge hvad jeg tror, er det bedste designproblem at løse. Mine overvejelser og mit endelige val vil forekomme i næste opslag.

[simonmilfred]

[DA] Spildesign til unikke kontekster 5: “Gaming at a LAN Event”

Som en ekstra referenceramme foruden mine egne feltstudier, vil jeg inkludere teksten “Gaming at a LAN event: the social context of playing video games” fra New Media & Society skrevet af Jeroen Jansz og Lonneke Martens i 2005. Denne tekst tilbyder ligeledes et studie af en LAN fest, dog en LAN fest i endnu større skala, nemlig med omkring 1200 deltager (p. 341). Formålet med artiklen er en udbyggelse af vores viden om at spille computerspil socialt, hvormed den dykker ned i flere områder der kan være interessante i forhold til at lave et spildesign. Lad det dog være i mente at artiklen er over et årti gammel, og LAN konceptet er dermed ikke helt det samme — LAN-delen, at bruge et Local Area Network, var for eksempel ikke aktuel i mine egne studier, hvilket det i højere grad var dengang (p. 335). Ligesom mine egne studier, var studiet desuden af eksplorativ karakter (p. 341).

Pointer og findings i teksten

Teksten opstiller fra start af påstanden, at multiplayer spil, især FPS spil og ikke mindst Counterstrike, dominerer når det kommer til, hvilke spil der bliver spillet (p. 339). Påstande er farlige, men de bekræftiger deres påstand senere i teksten (p. 345), og derudover understøtter mine egne studier også dette. Dette viser, at det næppe er en farse, at netop denne type spil bliver spillet, hvilket kan have stor vigtighed for et muligt design.

Teksten anerkender også at LAN-fester findes i forskellige størrelser og varigheder, men synes ikke at differentiere mellem dem (p. 340). Der er mange fællestræk på tværs af LAN-typer, men der er også markante forskelle - (min påstand) De store LAN-fester er næppe så intime som de små, men kan måske fordre mere konkurrence og forskellige aktiviteter, da der er flere mulige deltagere til aktiviteterne. Det betyder også, at når nu jeg udvælger den intime LAN-fest som mit endelige domæne, så skal jeg passe på ikke at komme til at designe til hall-LAN-fester.

Teksten udpeger fire motivationer til at deltage i en LAN-fest: Konkurrence, socialitet, interesse og afslapning (p. 342). Socialitet var hvad der scorede højest i gennemsnit efterfulgt af interesse, afslapning og til sidst konkurrence (p. 346). De kunne dog ikke finde en sammenhæng mellem socialitet og hvor meget tid man bruger på computerspil, til gengæld havde det stor betydning for, hvor ofte man tog til LAN-fester (p. 348). Tre grupperinger havde en høj score i konkurrence: dem som hyppigst besøge LAN-fester, dem som blev grupperet som ‘heavy gamers’, og dem som beskrev, at de ‘altid’ spillede online (p. 349). Teksten opstiller en hypotese, at første gangs besøgende er motiveret af LAN-festens unikke karakteristika: At man spiller spil i en social kontekst. Hvis de synes om dette vil de vende tilbage, men hvis de bliver ‘stamkunder’ begynder de måske at ville udvikle deres kompetencer og gå mere efter konkurrencerne (pp. 349-350).

De finder også ud af, at mere end halvdelen af deltagerne er med i en form for spilfællesskab (p. 345): “54.5 percent of the visitors said that they were members of a clan” (ibid.). Dette så jeg ikke noget af i mine feltstudier, dog var det heller ikke noget jeg undersøgte.

Næste skridt

Næste opslag vil være en rumlig analyse af LAN-fester.

[simonmilfred]

[DA] Spildesign til unikke kontekster 4: Spørgeskema besvarelser

I dette indlæg vil jeg redegøre for mit spørgeskema og dets i alt 58 besvarelser (på dags dato). Dette er linket til spørgeskemaet.

Spørgeskemates struktur og de overordnede resultater

For at filtrere individer fra, hvis svar ikke ville gøre gavn for designprocessen, delte jeg spørgeskemaet op i afsnit, hvor første afsnit var det lavpraktiske ja/nej spørgsmål, om besvareren nogensinde har deltaget i en LAN-fest. Kun ja-besvarelser bliver sendt videre til de næste spørgsmål, da det er disse som kender til det. For ja-besvarelserne følger så spørgsmålet, om de kunne tænke sig at taget til en LAN-fest igen. Her gav jeg foruden “ja” og “nej” også muligheden “ved ikke”, og både ja’er og ved ikke’r bliver sendt videre til de næste spørgsmål.

Efter denne filtrering, hvor der nu er 46 besvarelser tilbage, begynder så de mere nærværende spørgsmål, startende med “Hvad er en LAN-fest, hvis du skulle beskrive konceptet med egne ord?” Her har besvareren mulighed for at skrive et langt, frit svar. Der var blandt besvarelserne bred enighed om, at det var en social begivenhed, hvor en gruppe af mennesker mødes fysisk og spiller computer sammen. Nogle forbandt også LAN-fester med muligheden for konkurrencer, og mange lagde fokus på, at man spiser forskellige snacks og drikker sukkerholdige drikke. Flere understregede også, at LAN-fester byder på “nørderi”, men få understregede også, at det er for både gamere og ikke-gamere. Der blev på tværs af svar også differentieret mellem to forskellige typer LAN-fester: Større LAN-fester — Hall-LANs som én beskrev det — og mindre, mere intime LAN-fester. Flere pointerede, at LAN-festen kom fra, at man koblede computere sammen over LAN for en hurtigere forbindelse, men der var også bred enighed om, at dette ikke var nødvendigt længere.

Næste spørgsmål var “Hvor mange deltagere er der typisk i de LAN-fester du har deltaget i?” hvor svarmulighederne er intervalopdelte. Den største gruppe var “6-10” som udgjorde 16 af besvarelserne, og sammenlagt med “3-5” (8 besvarelser) var halvdelen af besvarerne altså mest vant til meget små LAN-fester. Der var dog besvarelser henover alle intervaller, med 4 besvarelser i “200 eller mere” som det højeste interval.

Næste spørgsmål var “Hvad er den typiske længde på de LAN-fester du har deltaget i?” hvor svarmuligheder var “én dag/aften”, “to dage”, “tre dage” og “fire dage eller længere”, og her lå én, to og tre dage næsten hel lige fordelt, og kun én besvarelse var vant til fire-dags (eller længere) LAN-fester.

Hvor de første spørgsmål var af definerende karakter, var de næste spørgsmål beregnet til at gå lidt dybere, så jeg kunne finde ud af hvad der gør, at LAN-fester er en ting. Første spørgsmål her er “Hvad er det, der får dig til at tage til LAN-fester?” Her gav jeg igen besvarerne mulighed for at friskrive deres svar, så jeg ikke pålagde dem et bias. Her er den overordnede konsensus, at det er det sociale, hyggen og fællesskabet som trækker, ikke mindst til de mindre LAN-fester. Nogle få var, her især til de større LAN-fester, mere tiltrukket af turneringer og andre konkurrencer. Dertil var der flere som brugte det som et afbræk og en pause fra hverdagen, og en lille gruppe som blot så det som en undskyldning for at spille eller for at se venner og bekendte.

De næste par spørgsmål var et forsøg på at finde ud af, hvilken type spil deltagerne godt kunne lide at spille til LAN-fester, og hvilke spil de spillede. Det første af disse spørgsmål var “Hvilke spil spiller du oftest til LAN-fester? Hvorfor?” En serie af spil blev nævn, men nogle spil blev skrevet ekstra hyppigt. Counter Strike blev nævnt af 13 besvarere, og Warcraft 3 blev nævnt at 8 besvarere. Herudover blev Left 4 Dead, Worms, League of Legends, Rocket League og Team Fortress også nævnt i flere besvarelser. Andre spil blev også nævnt, men kun enkeltvist. Flere af besvarelserne var også mindre specifikke, og flere påpegede realtime strategy spil og first person shooters som favoriserede. Flere beskrev også, at de normalt spillede multiplayer spil, og nogle specificerede yderligere at det ofte var enten versus spil, competitive spil, eller spil som handlede om samarbejde der bliver spillet. Én deltager påpegede at de plegede at spille på konsol, og at han/hun foretrak at spille sådan, og et par deltagere beskrev at de normalt spillede mindre intensive spil, da deres computere ikke kunne trække så meget.

Herefter forlød spørgmålet sig: “Hvilken type spil ville du foretrække at spille til en LAN-fest?” Her havde jeg præ-defineret nogle typer af spil baseret på spiltyperne defineret i Game Design Workshop (Fullerton, p. 57-62), og besvarerne kunne vælge mere end én mulighed.

41 havde valgt “Versus-spil hvor to hold spiller mod hinanden (Counter Strike, Overwatch, League of Legends, etc.)”

29 havde valgt “Cooperative spil hvor alle skal arbejde sammen (Castle Crashers, Keep Talking and Nobody Explodes, Don't Starve Together, etc.)”

24 havde valgt “Versus-spil hvor alle spiller mod alle (Speedrunners, Super Smash Bros., Towerfall Ascension, etc.)”

20 havde valgt “Cooperative spil hvor de fleste skal arbejde sammen mod én eller en lille gruppe (The Hidden, Trouble In Terrorist Town, etc.)”

11 havde valgt “Versus-spil hvor to spillere spiller mod hinanden (Hearthstone, Tekken, etc.)”

5 havde valgt “Spil hvor man spiller alene (Assassin's Creed, Portal 1, etc.)”

1 havde selv skrevet svaret “Semi-cooperative spil som point-and-clicks hvor man kan diskutere med andre hvad man kan gøre, selv om kun en person har controlleren”

Besvarerne havde herefter mulighed for at begrunde deres svar, og her var de fleste besvarelser i konsensus: Det er sjovere at spille sammen med de andre og helst flere. Én besvarede “Det skal være et spil hvor der ikke er meget "down-time" forstået på den måde, at hvis en spiller dør på et hold, så skal man ikke bare vente og sidde og glo for længe til det bliver ens tur igen. Så typisk FPS spil hvor man respawner ret hurtigt.”, og flere var enige i, at alle gerne skulle være aktivt med. Få beskrev dog også, at de også godt kunne lide at spille et spil alene, hvor det sociale omkring dem var nok.

Det sidste spørgsmål var om jeg måtte få besvarerens mail, så jeg for eksempel kan opsøge uddybende svar.

[simonmilfred]

[DA] Spildesign til unikke kontekster 3: Observationer fra en (mindre) LAN-fest

Den 23. februar tog jeg atter i felten for at undersøge en LAN-fest. Denne gang var det som deltagende observatør, og det var en noget mindre LAN-fest med kun 6 personer, altså færre end jeg er vant til selv. Alle deltagerne kendte mindst én anden, og vi var alle tilknyttet samme studie, men vi var ikke tilknyttet samme årgang. LAN-festen var desuden en én-aftens-begivenhed, og deltagerne var studerende på universitetet. LAN-aftenen var åben for medstuderende.

Mine observationer

Endnu engang en skitse baseret på hukommelse.

LAN-festen blev afholdt i universitetslokaler, hvor borde var stillet op på en række (spilleområde, rød på skitsen). En Playstation 4 blev sat op til en projektor for enden, og i begyndelsen af LAN-festen blev der her spillet spillene Ultimate Chicken Horse og Injustice 2, hvilket jeg deltog i (gul på skitsen). I mellemtiden sad øvrige spillere ved deres computere og spillede diverse spil såsom Hearthstone.

Lidt senere på aftenen samledes vi alle omkring computerne, hvor vi spillede spillet Brawlhalla sammen. Vi spillede det i ret lang tid, og vi snakkede undervejs henover bordene. Intentionen var først at afholde turnering i spillet, men da kun få af os spillede spillet hyppigt blev vi enige om, at det var bedre bare at spille alle mod alle. Mens vi spillede kom der pludselig en flok forbi fra et andet studie, som tilfældigvis havde set os spille, og som var nysgerrige. Vi snakkede med dem en stund, hvorefter de så gik videre til en fredagsbar. Vi fortsatte herefter med Brawlhalla i et stykke tid.

Undervejs blev der spist lidt, hvilket foregik enten ved computerne eller ved lokalets øvrige siddeområder (cyan på skitse).

Da vi ikke gad Brawlhalla mere, søgte vi at spille andre spil, men vi løb ind i problemer, da de spil vi fandt, ikke kunne køre på alle computere. Min egen computer var især et problem, og efter et stykke tid valgte et par stykker af os at tage hjem.

Næste skridt

Da denne LAN-fest blev mindre end forventet, vil mine næste skridt være — foruden at sammenligne data med mit spørgeskema — at samle lignende studier af LAN-fester for at opbygge mere empiri. Altså vil næste blogindlæg være en opsamling af resultaterne for mit spørgeskema, og indlægget efter dette vil være en sammenfatning af én eller to lignende studier. Herefter vil jeg sammenfatte mine opdagelser og begynde at designe.

[simonmilfred]

[DA] Spildesign til unikke kontekster 2: Observationer fra en LAN-fest

Den 20. januar tog jeg i felten for at undersøge mit valgte domæne: LAN-festen. Jeg har forudgående kendskab til domænet, da jeg selv har deltaget i LAN-fester før, men jeg mener ikke det er givtigt for mig at tage udgangspunkt i mig selv, hvorfor jeg valgte at besøge en LAN-fest hos nogen, som jeg ikke allerede kendte. LAN-festen var også af en anden karakter end hvad jeg selv er vant til. Der var lige over de 100 tilmeldte, hvor jeg typisk deltager i noget mindre LAN-fester (10-20 personer). Hertil foregik LAN-festen henover 3 dage, hvor jeg selv typisk deltager i LAN-fester som varer én aften/nat. LAN-festen var for HTX elever. Jeg undlod at tage billeder grundet den unge aldersgrænse.

Jeg var ikke deltager til LAN-festen, men havde derimod fået lov til at observere og interviewe deltagere hvis det havde min interesse. Jeg var der i lidt over en time, hvor jeg til dels interviewede nogle af arrangørerne, et par andre deltagere, og ellers blot observerede.

Mine observationer

Herover en skitse fra hukommelsen. Skitsen er ikke ment til at være skaleret korrekt, men er alene for et overblik.

LAN-festen var delt op i tre forskellige hovedområder (som kan videre inddeles). Det første jeg kom ind til var soveområdet (cyan på ovenstående skitse), hvor soveposer lå spredt udover gulvet. I dette område stod også et et langt sofaparti pegende i retning af en storskærm hvor de havde tilsluttet en Switch konsol (gul på ovenstående skitse). Da jeg ankom sad et par deltagere og spillede Picross S.

Det andet område var spille-hallen (rød på ovenstående skitse), hvor der stod rækkevis af borde alle besat af computere og deres ejere. Langt de fleste sad med stationære computere, men der var også en god del som benyttede sig af bærbare computere. Et skøn ville umiddelbart være 35% af dem. Langt størstedelen af deltagerne var drenge, men jeg talte at der var omkring 20 piger til stede også. Der blev spillet en del forskellige spil, men langt de fleste skærme viste ESport spil - især førsteperson skydespil såsom Counter Strike: Global Offensive. Kun enkelte spillere spillede spil alene/singleplayer spil. Resten spillede spil for flere spillere. Ét spil var helt ukendt for mig, Moon Hunters, og da jeg spurgte spillerne om det blev det beskrevet som et co-op rougelike spil.

Det sidste hovedområde var på en bred hems, hvor der var gjort plads til at spille analoge spil (lime på ovenstående skitse). Da jeg var oppe og observere spillede de Varulv, et spil hvor spillerne hver især er beboere i en landsby og skal finde ud af, hvem af deres medbeboere i virkeligheden er varulve.

Det var altså overordnet set sociale spil der blev spillet. Nogen spillede co-op spil, men langt de fleste spille hold vs. hold/ESport spil.

I enden modsat spille-hallen var en kantinedesk (blå på ovenstående skitse). Her blev der bragt mad til.

Uddybelse fra arrangører og program

Både den sociale og kompetetive tendens blev også bekræftet af de interviews jeg foretog. Alle de interviewede lagde stor vægt på, at de var der for det sociale: For at kunne spille spil med venner og bekendte og snakke løst om skolegang og livet generelt imellem spil. Flere gav udtryk for, at de kun deltog i LAN-fester hvis der var folk de kendte der, og kun enkelte af dem jeg talte med havde været til andre LAN-fester end HTX's LAN-fest. En LAN-fest som jeg fik at vide havde eksisteret i 4-5 år, og nogle gange havde været med langt flere deltagere end de 100. Jeg fik at vide, at der eksisterede en lignende LAN-fest ude i Viby som nogen nogengange deltagede i.

Da jeg interviewede nogle af dem som arrangerede LAN-festen, var det også kun bekræftende for mine observationer. De beskrev, at det for det meste af tiden var helt frit hvad der blev spillet, men at de arrangerede tourneringer i de spil deltagerne efterspurgte turneringer i. De beskrev også at de køber præmier til disse turneringer, for at gøre det lidt ekstra spændende. Der var arrangeret turneringer i Counter Strike: Global Offensive (2v2), Overwatch (5v5), Hearthstone, Mario Kart (på Switch), League of Legends (1v1 & 5v5), Cards Against Humanity (analogt kortspil) og PlayerUnknown's Battleground (solo og squad).

Næste skridt

Som jeg beskrev i mit tidligere opslag, har jeg sendt et spørgeskema ud forinden denne feltundersøgelse. Når en tilpas mængde feedback er givet på denne, vil jeg analysere det, samt holde denne feedback op imod mine observationer ved denne feltundersøgelse. Derudover har jeg fundet endnu en LAN-fest i februar, som jeg tager til - denne gang som deltager. Denne er med folk jeg kender.

Tilføjelse (25-01-18): Jeg glemte en uddybelse af opsætningen af "spille-hallen", men jeg mener denne er værd at indskrive, da det kan have stor betydning for et muligt design. Bordrækkerne stod relativt tæt på hinanden, for at gøre plads til alle. Det var til at komme rundt, men flere steder var det meget trængt, og få steder var man nødt til at gå en længere vej udenom. Dette kan have betydning for det fysiske aspekt af et muligt spil: Folk kan ikke løbe rundt og lege fange (for eksempel).

Derudover formåede jeg ikke at undersøge en bestemt del af LAN-kulturen: Om folk snakkede på kryds og tværs af borde, eller om de blot snakkede med de nærmeste. Jeg mindes ikke at der var råben på tværs af lokalet, men det er noget jeg må undersøge næste gang jeg går i felten.

[simonmilfred]

[DA] Spildesign til unikke kontekster 1: En introduktion

Hello, this thread of blog posts will be in Danish as they are tied to my Master’s thesis which will be written in Danish as well.

Hej læser, Denne tråd af blogindlæg vil være fokuseret omkring den spildesignprocess som er omdrejningspunkt for mit speciale. Jeg vil altså ikke beskrive mit speciale i disse opslag, men vil derimod lade spildesignprocessen stå alene.

Jeg vil tagge opslag i denne serie med #AUSpeciale.

Mine første skridt

Det første punkt på min agenda er at undersøge konteksten for mit fremtidige spildesign: LAN-festen. Jeg er i færd med at udvikle et spørgeskema, således at jeg kan undersøge LAN-festen bredt og danne mig et billede af de fællestræk der er på LAN-fester, eller alternativt om der er behov for en indsnævring til en bestemt type af LAN-fester. Jeg har sendt den første pretotype af spørgeskemaet til en lille gruppe af venner, så jeg kan få feedback på det, inden jeg sender det ud til flere.

Herudover er jeg i gang med at opsøge muligheder for at møde op til rent faktiske LAN-fester, således at jeg på førstehånd kan lære om dem, se hvad der gør sig gældende, og snakke med deltagere.

Jeg håber på både at kunne deltage i LAN-fester som udenforstående observatør/interviewer og som deltagende observatør/interviewer.

[simonmilfred]

Still Here - A DADIU Production

The six weeks long graduation production at DADIU is now over with. It has been a great challenge and an awesome experience. Check out the trailer for the game below, and maybe go check out the game on Play Store?

You can find the game on Play Store.

I have learned a lot from being a QA and UR manager. The biggest lessons being something along the lines of “be creative with what you got”, “be loud and everywhere” and “be autonomous”.

More often than not you do not have time to do proper UR workshops, the build will be delayed, or it will not be what you were promised by the developers. At least that is what I experienced at DADIU, and it makes sense to me that this will be mirrored in the industry. You are working in a fast paced process on a tight schedule, and it is almost impossible for the process to run smoothly all the time. The only thing you can do, is do your best to bring value from what you got.     Doing QA or UR has shown to be a constant juggling of extracting valuable information from whatever you have access to. This can be a build (broken or working), people (inside or outside the target audience), concept art, audio clips, documentation, abstract ideas… Anything really. A big part of the job is figuring out what makes sense to test or research, and to consider were the next nugget of value lies.

However, because of the busy work environment you have to be loud. You have to be loud, so that the development team hear, what you have to say, before it is too late, but also so that you get as much material from the team as possible. While it may be extra work on your part, it goes a long way to make your work visible. Take the time to enquire, have meetings to get to know the needs of the team, and make sure to ask for things: The artist, for example, can easily send you his concept art, but he might not think about doing so himself, as he is busy with developing it further. Likewise, it only takes so long to print out some copies of your report and place around the building, but it makes it so much easier for the team to access the information.

After I started doing these things myself, the team were also a lot more interested in my work and opinion. I had great conversations with both artists and programmers, and the game designer sparred with me on multiple occasions. Even the game’s name was the result of my work, as I chose to do some guerilla testing during the weekend towards the end of production. The game director had just settled on a name, then changed her mind based on my findings.

Generally it is also a good idea to take charge sometimes. Of course you should not ignore management or go completely rogue, but sometimes it is more valuable to just walk out and do the guerilla testing without asking first - the team does not always know what they need. This is not something I dared do in the beginning of the process, and even when I dared to, I did not do it a lot. But when I did, it did not end out badly. On the contrary.

[simonmilfred]

“Still Here” Is Released!

The game I have spend my last six weeks doing QA and UR on are now released and available on the Play Store. Maybe check out the teaser first?

Find it on Play Store for Android Devices. Best played on tablets with headphones.

[simonmilfred]

The above sub-chapter of the DADIU saga is written wholly in relation to my project Tale of Omni. However, it is still my own, personal reflections.

A DADIU Post Mortem

Earlier this year I wrote about some big changes that had entered our project and lives. One of these changes were that both the Artist, the Oracle and I, the Architect, are attending DADIU (The National Academy of Digital Interactive Entertainment) this semester. While we are not fully finished yet (there is still one week left of productions at the time of writing this), I believe it is time for me to reflect on it all in relation to Tale of Omni.

QA & UR Manager

As I mentioned in the previous post of changes, my role on DADIU is Quality Assurance & User Research Manager (QA & UR Manager). As I have written before in personal ramblings on the matter, I were skeptical of entering this role in the very beginning, however, I have been learning a lot, and I am thankful, I got the opportunity. In the following I want to go through the main lessons, I have learned.

As a QA I have learned, that something does not have to be done to be tested. Or, well, I knew that already (I often prototype things), but I have really gotten the lesson under my skin now. By not being the one actually developing the games I have been able to see the value of testing things from a whole other perspective. I am a changed man. This has lead me to begin uploading weekly builds to the team, so that they can follow progress, and so that the Oracle can QA the shit out of the project as we go.

Closely tied to this lesson I have also learned, the importance of documentation. Yes, I touched upon this last time, I wrote, but it sticks deeper than the things, I wrote about then: I have now experienced first hand how troublesome it is to judge, whether things are like they should be, while not being close to the code. I have always been the programmer and designer, and I have always known my projects by heart, but for everyone else, it is much harder to know what happens. We already do meetings on the team, and as I explained in the post about documentation, I am also working iteratively on a game design document now - but I have also begun writing release notes for each build. This allows my fellow team members to know every small change happening to this part of the project, and it allows me to track what work, I have been doing, and what needs fixing.

When it comes to user research, my whole world view has been changed. As a Digital Design student at Aarhus University, I have been taught a whole lot about “the good design process”: How to plan and execute workshops, iterations, mock-ups, prototyping, etc.. These has been good lessons, but “the good design process” as I knew it is utter utopia. Nobody have time to do prober cycles of iterations and develop ideas with user input in every single step. It simply takes too long. As UR I have learned, that the real challenge of user research is, to extract as much value from very little. ​ This does not mean the users should not be heard, but simply that you shall pick your battles, and not suggest a full blown workshop in each and every step of the process. Sometimes it gives more value to the team not to ask the users, sometimes guerilla-testing on the street is enough. You just need an approximation of the users’ needs - even the best of workshops would not give you the full picture anyways.

Following a Production

I did not only learn things as a QA and UR Manager. I knew from the beginning of the semester, that I would get most out of DADIU, if I were to learn from multiple other roles as well. So I tried to continuously look at the mistakes and victories of my team mates.

Learning from the programmers, I have further divided my code into individual systems, so that one system may be fully revamped without having to edit the whole code base. One of the recent changes, this has lead to, is a full-screen shader manager to keep track of various effects (bloom, day/night, saturation, etc.).

From seeing the Game Director and Project Manager do their work, I have also learned a lot. I have seen how important it is to be able to delegate work to my team mates, but also how important it is to always stay in the loop. It is okay that I have vision, but it should never be reason to push aside my team’s needs. A team works better when the outcome is in line with hopes of the individuals. On the other hand I should not be afraid to demand things from my team. Sometimes you have to be less soft. But for God’s sake, do not confuse that with being unfair.

Watching the Game Designer taught me a lot about the importance of being precise. Illustrate what you mean and try to think every little detail into it. But also ask for feedback and improve. Knowing, that what you make is not perfect, and letting the team know that you know this, is valuable.

I have also had the honor to work with some very talented artists, both in terms of visuals and audio. From the visual artists it became even more clear to me, how important it is to work out a direction for the art (and I saw how well such things could be made). I also learned that each piece of concept art should be made with purpose. From the Audio Designer I learned that maybe it is time to add some audio to Tale of Omni again. Because it does not have to be finished. It may even be crude. But it gives much more sense of the direction to iterate on the music and sound effects from early on.

To Conclude / tl;dr

Being part of DADIU has been a rich experience. I have learned a lot, grown, met great people, and had great fun. In about a week we are done, and the whole team (almost) will once more be in Aarhus, ready to continue work on Tale of Omni. It is going to be great, and it is something, which I look very much forward to. Have a good one.

Sincerely The Architect

[simonmilfred]

The DADIU Sage pt. 2 - Halfway There

More than 8 weeks have past now, which makes the saga halfway complete. Development on the graduation game has begun. We have spend our first time at DADIU with workshops, two 8-days productions, more workshops, and for us the QA and UR managers: A few weeks of nothing.

Last time I wrote, I were quite skeptical of my role as a QA and UR manager. One of my concerns were, that it could lead me astray in terms of getting into the business of game design and development. I am less concerned now. I have now found, that the position is a proper door-opener in the gaming industry. As it was relayed onto me: It is hard to land a position as a game designer (unless you are a startup, of course). The big companies want people with experience, and the small indies usually start up with a game design in mind, ie. the ideas and design are not what they search for people to aid them with. QA and UR is however needed on all levels of production (and not only in the game design field), and this could allow me footing in the industry. Granted, I will then have to showcase my skills somehow as a game designer to change course, which will indeed be a challenge, but which has been done before. And I am not necessarily saying that it is my "plan A" to start out as QA and UR, but it does broaden the possibilities.

Being QA

During the first weeks of DADIU it was told to us a multitude of times on the QA and UR team, that we were to be hated. Hated by everyone. And that production teams would only understand our use and value at the very end of the graduation game production. Until then we would just be this tiresome group adding to their work load. Luckily this has not been the exact case: I have not felt hade towards me by the production team I am managing at any point of time. However, it is hard work to get to do your work as a QA.

In the two 8-days productions we have been focusing on QA only, and the matter of simply getting builds to test from the production teams has been a challenge to say the least. The production teams have promised deadlines time upon time for when a build would be ready. And then pushed them. And pushed. And pushed them. And it is fair enough - the production teams needed to learn the ins and outs as well, and the two mini productions were exactly made to allow for error. Only problem is, that whenever they pushed a deadline, it was time wasted for us. Time we could have spend on better things. Also it limited how much we got to practice and iterate on how we do our QA.

But it is, what it is. At least communication with the production team has been pleasant, and they did supply some builds to test - they were not trying to ignore QA.

Being UR

After the two mini productions we had a workshop in UR. It was quite fine. Our workshop keeper were the very competent Dana Popa, and she adapted very well to what we needed. A lot of the things to learn were things a lot of us already knew. I have personally done plenty of user research as part of my study: Surveys, interviews, cultural probes, ethnographically inspired field studies, etc., so not much new here. But she did help us learn some nuances of the different methods, and she had some nice tips and tricks from experience. One thing she brought to us was the concept of pretotyping, which I believe is quite valuable. I will not flesh out what it is, as it can be easily googled.

The following weeks were barely planned by DADIU. We had to go practice our skills a little by doing UR on the mini productions, but after doing that: Nothing. The production teams had this time period fully planned out, but QA and UR was neglected. We tried to push for doing some pretotyping on the game ideas as they were fleshed out by the teams, and got permission to suggest it to our teams. My team did not want it. So nothing to do for me for now. Now I hope I can persuade them to let me do some work, so that I do not have to wait until they got their first build. Yes, there is paper work to be made, but not enough to fill out the next three days.

Anyway, it seems this post has caught up to the now. Time to see what the final 6-7 weeks bring.

[simonmilfred]

The DADIU Saga pt. 1 - First Encounters

From the 30th of August to the 1st of September my semester at DADIU was kick-started with an introductory workshop. The workshop was a get-to-know-your-team-and-each-other kind of deal, were we did a lot of social exercises and also made our own tabletop games. It was some good days settling my mind quite a bit.

When applying for DADIU I was hoping for the role Game Designer. I strongly believe it to be a role I fit very well, and I would hope to be working in such job position sometime in a not too distant future. I make games in my spare time, I scribble down game ideas all the time, and I teach children how to make games via voluntary work. However, I ended up in the QA (Quality Assurance) and UR (User Research) Manager position, which I have had a hard time turning into something positive. Not because it is not an important role, but simply because it is not a job I wish to have - it is not what I want to earn my money doing. I want to be part of the production team, I want my hands on the project, and I want to be able to point at it and say "I made this". I am a maker, and I always have been. I were honestly quite bummed about not getting the position I hoped for, and I feared it would be a wasted semester, only opening QA and UR doors.

But the course was set. And while the semester could very well be a waste in terms of opening for more game designer doors (I hope not, though), I would not allow it to be a waste in terms of actual, acquired, useful skills. I want to get most of it, learn what I can from my position, as well as play my part in the whole.

Then came the day of first encounters: The introductory workshop. A couple of much eventful days, mostly focused on socializing, being welcomed, and information. My team is composed of good people, at least that is my impression, and while we were often forgotten when it came to given information and calling out groups, Thomas (both a teacher at, and a founder of, DADIU) made sure we also felt welcome, and that our role where somewhat understood and respected by the production teams. He spoke highly of the role, and while a lot of it felt like fluff to make us feel better about being QA and UR managers, he also had much reason and experience behind his words. For better or worse he made the role feel more like a viable route to what I want to be and do.

As part of the socializing (and to get into DADIU spirit) we made our own tabletop games, and here the QA and UR manager team also got to participate and design a little. The task was to turn a digital game into an analogue one, and we ended up making a tabletop version of Overwatch, where you were two players against each other, fighting with three characters each: Soldier 76, Pharah and Roadhog. I do believe the game was much fun to play, and we could easily had extended it further, by adding more maps and characters.

At the time of writing this I am on my way to Copenhagen by train. The next couple of days we will have QA-workshops there. I look forward to getting started, and I look forward to tell you how everything turn out.

[simonmilfred]

Welcome to SimonMilfed.dk

Hi!

My name is Simon Milfred, welcome to my site. I am young man from Denmark (hence the .dk domain) who enjoy doing an abundance of things: Game development (design, programming and art), graphics design, pixel art, 2D animation, video editing, tutoring others in these things, and a lot more!

As you may notice, all of these things (save tutoring) is very much visual things. At least it is especially the visual aspects of the things that speak to me. The visual focus is something, I grew up with. My father has always been good with a pencil, and has always been a great source of inspiration (he has written comics, painted signs, drawn portraits, and much more), likewise I have always felt my mother had a greatly creative mind (which I based almost solely on her doodles from when speaking on the telephone - in recent years she has begun embracing being creative in a multitude of ways), and I multiple creative aunts (especially one of them has been a huge part of my childhood - I spend many a Tuesday oil painting with her, watching her Bob Ross VHS tapes).

I used to draw a lot. Like, pencil drawings. It is not something, I do a lot any more. I still sketch and things like that, but it has been quite a while since I have spend hours on a drawing. You can, however, see some of my works by scrolling down my art portfolio. Today I am mostly working digitally, though I am still using the things, I learned from the more analogue arts.

Digital art allows me to do a lot of things, I cannot do with paper (at least not with the same speed). More importantly I can better use the digital graphics when working on video games. I began making my own games for the computer when I were ~11 years old. I searched Google for "make games" (or something like that), found Game Maker, and have used it ever since (newest iteration of the software at the time of writing is called GameMaker:Studio 2). Because I did not know others, who wanted to make their on games, I had to draw everything myself, program everything myself, and make the audio myself - so I slowly learned how to do all these things (however, I rarely ended up putting music in my small games, so I never learned to make music. I rely on others for that).

When I were about 14 years old (from memory, not too sure of the exact age) I began playing around with Photoshop as well. I ended up being quite good, and earned some money making graphics (logos, posters, etc.). I still to this day use Photoshop regularly. I make graphics (both for myself and others), but I also make photo-manipulations. To keep in "shape", I make a new profile picture or cover art for Facebook, whenever I have been at the cinema.

In December 2012 I began work on the YouTube channel Bless Hay Gaming. Back then it was meant to be a project shared by my brother and me - a simple gaming-channel (I know, how unique..). However, after running it for a while, I began also uploading GameMaker-tutorials, and slowly it became the main thing I uploaded! I began using "Bless Hay Gaming" as my general game developer name, and while I still make tutorials both for the channel and in blog form, Bless Hay Gaming is no longer limited to YouTube, gaming and tutorials. It is still a hobby project, but it is slowly growing.

The whole helping-others-to-learn is, however, not confined to the internet. In recent years I have taught courses in Photoshop, and for the last couple of years I have been an active member of Coding Pirates, an organization focused on teaching children about technology through working/playing with it. Here I helped making the GameDev department a thing, and as a part of my work in Coding Pirates I have even held workshops in London with my fellow pirates, and collaborated with D.A.R.E.. The GameDev department is where I currently volunteer, and here we, funny enough, make video games with the children.

This leads me to my current, main, big project: Tale of Omni. Tale of Omni started as a small, game-jam entry in the GM48 jam (it was just called Omni). The game won the innovation category, and I thought, it was a concept with potential. I quickly dragged a friend into the project, Joe (he is in the Coding Pirates picture, the left-most person), and later a dragged in another friend, Ric. The three of us has worked on the game for some years now, even came out with a short demo a year ago.

The game is a huge project, and I do believe it will take some more years before it is done, but we work on it with passion. Some weeks ago we invited a fourth member to the project, Magnus (he also is in the picture above, the guy to the right of me, looking in my direction). While the game is still very much a child of my imagination, it has been a huge help to have a team, which can contribute with, and refute, ideas, and help with some of the work load. Joe has been a huge help with his graphical works, Ric has contributed lots when it comes to story, and he will also be in charge of the music of the game, and Magnus will soon contribute greatly, I am sure, in his role of QA-manager.

SO now you know a little about me, now it is time to explain, what this blog is all about. This blog is meant to be a place for me, to write about anything I want - this could be what is going on in my life, small tips and tricks (maybe some pixel art tutorials?), or just my humble opinion on something. In short: This blog is not limited to any one subject. Some things I will not cover, are things I cover on other blogs - no reason for me to repeat myself. I will still make portfolio-posts on my portfolio, art in my art-portfolio, and so on.

I guess this is everything I have for you today. I hope you enjoyed the read. Until next time, Simon Milfred