samuelmanolakas

Block_Manolakas_Samuel_projektportföljsdokumentation

Eighth Realm är ett souls-like, multiplayer-spel där du och upp till tre andra spelare försöker besegra The Eighth Lord. Du kan välja mellan tre olika vapen-varianter; Sword and Shield, Great Sword eller Bolter.

Kärnan i det här spelet är karaktärskontrollen. I souls-like-spel är det väldigt viktigt att karaktären känns tung och avsiktligt långsam, men samtidigt rättvis och balanserad. För att säkerställa att jag uppnår de här målen utgår jag ifrån Steve Swinks Game Feel: A Game Designer’s Guide to Virtual Sensation.

Spel-komponenten

Jag har utgått från Swinks bok sedan projektets start och det har legat till grund för hur jag har strukturerat och motiverat mina designbeslut längs med vägen. För att skapa en karaktärskontroller behöver karaktären kännas bra att styra, men att definiera spelkänsla är svårt. Det är här Swinks bok kommer in. Han delar upp känslan i ett spel i sex delar; Input, Response, Context, Polish, Metaphor och Rules. Swinks bok gav mig ett ramverk för att analysera och motivera varje beslut istället för att skapa karaktärskontrollern intuitivt och hoppas att det skulle kännas bra. Varje mekanik hade ett syfte kopplat till spelupplevelsen, inte bara teknisk funktionalitet. Mitt fokus var att det skulle kännas rätt, inte bara att det skulle fungera. I souls-like spel är det skillnaden mellan en kontroller som känns bra och en kontroller som bara tolereras.

Input

Souls-like spel är kända för att ha minimal input när det gäller combat. Det finns en light attack, en heavy attack samt block och dodge; det är grunden för souls-like combat. Därför är det väldigt viktigt att varje knapp har sin egen funktion istället för att en och samma knapp ska ha flera funktioner. Jag kollade på flera souls-like spel som Demon Souls, Dark Souls, Elden Ring och Bloodborn för att bestämma knapparnas funktion beroende på dator eller konsol. Jag gjorde några små ändringar efter det första speltestet eftersom många som spelade med tangentbord tyckte att lock-on knappen skulle kopplas till mellersta musknappen istället för Tab-knappen.

Response

Input buffering fungerar genom att spara det senaste knapptrycket under ett kort tidsfönster, specifikt de sista 0.3 sekunderna av en animations återhämtningsfas. Attacken körs automatiskt så fort karaktären tillåter det om spelaren trycker på attack-knappen under det tidsfönstret.

Utan det systemet kändes attackerna döda – spelarna upplevde det som att spelet inte registrerade input när de tryckte på knappar och ingenting hände. För att spelaren ska känna att varje knapptryckning är responsiv utan att tappa sin tyngd behövs input buffering. Även om det är en av de minst synliga mekanikerna är det en av de viktigaste mekanikerna för att combat ska kännas flytande.

Nedan är ett exempel på Response. Även när karaktären inte kan agera direkt ska spelaren känna att deras input registreras.

Acceleration och inbromsning ger vikt till spelaren – om det är för långt känns spelaren trög och om det är för kort känns spelaren arcade-y. Rörelsen styrs av en målhastighet som karaktären interpolerar mot med Vector3.MoveTowards. Karaktären accelererar gradvis upp till maxhastighet när spelaren håller in framåt-knappen, och bromsar in på ett naturligt sätt när spelaren släpper. För att ge en känsla av kontroll utan att det skulle kännas trögt valde jag att ha kortare inbromsningstid än uppramptid. Det första speltestet visade att spelare tyckte att karaktären gled som att den stod på is när de släppte framåt-knappen.

Jag valde också att hantera rörelsen manuellt istället för att använda Unity’s inbyggda physics för att ge en mer designbar och förutsägbar känsla. Det är viktigt i souls-like spel där varje rörelse måste kännas avsiktlig och rättvis.

Nedan är ett till exempel på Response – karaktärens reaktion på input ska kännas tydlig och proportionerlig.

Commitment Windows innebär att spelaren kan inte avbryta en attack innan de har genomfört attacken, vilket tvingar dem att tänka innan de attackerar. En dodge kan avbryta återhämtningsfasen men inte en ny attack. Jag valde att göra det för att det förhindrar att spelaren spammar attacker utan konsekvens.

Animationen vår designer skapade hade ingen återhämntningsfas. Det hade ingen konsekvens eftersom spelaren kunde dodga eller springa iväg direkt efter de hade attackerat. Istället för att justera om alla attack-animationer bestämde vi oss att förlänga attack-tillståndet spelaren befinner sig i när den attackerar samt att frysa animationen vid sista framen som gav ungefär samma känsla som när karaktären återhämtar sig.

Förlängningen av attack-state behövde justeras efter det andra speltestet eftersom många speltestare tyckte att det tog för lång tid för karaktären att återhämta sig, och att karaktären inte kändes responsiv.

Context

Kameran följer spelaren med en fast offset bakom och ovanför karaktären. Kameran flyttar sig framåt längs siktlinjen mot spelaren när ett objekt hamnar emellan, i stället för att kameran klipper genom geometrin. I ett spel där timing och läsbarhet av fienders attacker är avgörande valde jag detta system framför att dölja geometrin, eftersom det ser till att spelaren alltid är synlig. Om spelaren inte kan se vad bossen gör så är spelet inte längre rättvist.

Nedan är ett exempel på Context. Miljön ska alltid stödja spelaren, aldrig arbeta mot den.

Verticality and Large Scale. Enorma väggar, byggnader och fiender får spelaren att känna sig liten i kontrast. Vi har valt att skala spelet större en vad det hade varit i verkligheten för att ge den känslan till spelaren.

Polish

Attackerna är designade med tre faser; wind-up, aktiv och återhämtning. Vanliga attacker har kort wind-up och återhämtning medan tunga attacker har längre wind-up och återhämtning, men gör mer skada. Det skapar ett naturligt risk/reward-system utan att behöva extra regler.

Detta är ett exempel på Polish, varje attack kommunicerar styrka och konsekvens vusuellt innan den träffar.

För att vidareutveckla spelet skulle jag kunna lägga till effekter och ljud när en attack kolliderar för att ge attacken bättre träffkänsla.

Lock-On och Strafe. Lock-on-mekanik i souls-like spel innebär att kameran låser sin rotation så att den alltid är riktad mot bossen för att spelaren inte ska tappa bossens position ur sikte. Det betyder att karaktärens rotation också är låst mot bossen. Det innebär att karaktären rör sig i sidled eller strafar. För att animera detta korrekt behövde benen röra sig annorlunda eftersom karaktären rör sig i en annan riktning än den riktning som karaktären tittar mot.

Problemet är att vi behöver helt nya animationer för varje riktning karaktären kan röra sig i. För att lösa detta använde vi animationslager som innebär att vi delade upp överkroppen och benen. På det sättet kan överkroppen fortsätta spela sin vilolägesanimation medan ett separat lager hanterar benens rörelse beroende på vilken riktning karaktären strafar. Det resulterade i att vi behövde skapa nya animationer enbart för benen istället för hela karaktären.

Det här är ett effektivt sätt för oss att hålla animationssystemet hanterbart och för att återanvända animationer.

För att skapa vårt animationssystem utgick vi från Travis McIntosh 2010 GDC-panel Animation and Player Control in Uncharted: Drake’s Fortune and Uncharted II: Among Thieves. Där går han igenom hur man använde partial och additive animations för att hålla Drakes animationssystem flexibelt utan att animationsarbetet skalade okontrollerat.

Nedan är ett till exempel på Polish. Animationslager gör att karaktären alltid ser naturlig ut oavsett kombination av rörelse ock lock-on utan att animationsarbetet skalas exponentiellt.

Rules

Jag delade upp dodge-mekaniken i tre faser; uppstart, rörelse och återhämtning. I-frames(frames som spelaren inte kan ta skada i) aktiveras bara under rörelse-fasen, inte under uppstart eller återhämtning. Jag valde att göra det för att belöna spelaren om de tajmar sin dodge rätt, och straffa dem om de gör det för sent eller för tidigt.

Jag implementerade dodge som ett eget state i karaktärens tillståndsmaskin, där skadeimmunitet slås på och av beroende på vilket state spelaren befinner sig i för att kunna styra exakt när I-frames är aktiva. Det gjorde det enklare att förhindra spelaren att dodga medan de attackerar eller blockar.

Nedan är ett exempel på Rules. Spelaren lär sig systemets logik genom konsekvens, inte genom instruktioner.

Stamina-system innebär att alla aktiva handlingar som attacker, dodgar, blockar och sprintar kostar stamina, vilket får spelet att kännas mer strategiskt. Om spelaren attackerar för mycket kommer den inte ha tillräckligt mycket stamina för att undvika eller blocka bossens attack. Stamina börjar inte återfyllas direkt efter att den har använts utan regenereringen är fördröjd. Detta är ett medvetet val för att få spelet att kännas mer strategiskt. Spelaren kan inte bara attackera kontinuerligt utan måste läsa av bossens mönster och hitta rätt tidpunkt att agera. Stamina är också synligt via UI:t för att spelaren inte ska behöva gissa hur mycket de har kvar. På så sätt kan spelaren fatta mer informerade beslut.

Nedan är ett ytterligare exempel på Rules. Stamina sätter gränser för spelaren som gör varje beslut mer strategiskt.

För heal-systemet valde vi att ha tre heals per boss-fight som aktiveras med ett knapptryck. Healen sker omedelbart och utan animation, dvs. spelaren är inte låst under processen till skillnad från andra souls-like spel. Vi valde att göra detta på grund av att vi inte hann skapa en heal-animation, och tog inspiration från Armored Core VI Fires of Rubicon. Där har de ett liknande heal-system som vi tyckte passade både vårt gameplay och tema. Heal-systemet blir istället ett resurshanteringsproblem snarare än ett timing-problem, där konsekvensen av en dålig heal är att slösa resurser istället för att ta skada.

Samarbete och planering

För att samarbeta med andra discipliner behövde jag tänka igenom var någonstans i min kod saker som exempelvis animation eller ljud skulle implementeras. Jag behövde även anpassa mig efter vilka variabler som behövde vara hårdkodade eller inte för att ge möjligheten till min designer att balansera spelet.

Efter det att vi hade definierat vår MVP (Minimum Viable Product) behövde jag prioritera vad som var viktigast för det här projektet. Från de tio veckorna vi hade valde jag att dedikera de två första veckorna till att sätta upp nätverk. De sex kommande veckorna dedikerade jag en vecka till varje del som behövdes för karaktärskontrollen, och om jag fick tid över skulle jag arbeta med bossens AI. De två sista veckorna lämnade jag tomma för oväntade saker som kunde dyka upp.

Under min arbetsprocess var det viktigt att anpassa mig. Jag började jobba med det jag bedömde var det viktigaste men hoppade över till att lösa problem när de dök upp.