samuelmanolakas

Block_Manolakas_Samuel_projektportföljsdokumentation

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

Komponenten för det här spelet är karaktärskontrolen. I souls-like spel är det väldigt viktigt att karaktären känner sig tung och avsiktligt långsam men fortfarande 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 Swink Game Feel: A Game Designer’s Guide to Virtual Sensation.

Spel-komponenten

Jag utgick från Swinks bok från projektets start som blev grunden för hur jag har strukturerat och motiverat mina designbeslut genom hela projektet. För att skapa en karaktärskontroller behöver karaktären kännas bra att styra, men att definiera spel känsla är svårt, det är här Swinks bok kommer in. Han delar upp känslan i ett spel i 6 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 vilket i souls-like spel är skillnaden mellan en kontroller som känns bra och en kontroller som tolereras.

Input

Souls-like spel är kända för att ha minimal input när den gäller combat, en light attack, en heavy attack, 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 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 knaparnas funktion borde på dator och konsol. Det blev några små ändringar efter första spel testet där många som spelade med tangenborn tyckte att lock-on knappen skulle ligga på mellersta musknappen istället för Tab knappen.

Response

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

Utan detta systemet känns attackerna döda, spelaren upplever som att spelet inte registrerade input när dem trycker en knapp och ingenting händer. För att spelaren ska känna att varje knapptryckning är responsiv utan att tappa sin tyngd behövs input buffering som är en av de viktigaste mekanikerna för att combat ska kännas flytande även om det är en av de minst synliga mekanikerna.

Detta ä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 framåt, och bromsar in på ett naturligt sätt när spelaren släpper. För att ge känsla av kontroll utan att kännas trög valde jag att ha kortare inbromsningstid än uppramptid efter första speltestet visade att spelare tykte att karaktären gled som att han stog på is när de släpte framåt knappen.

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

Detta är ett 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 som hade ingen konsekvens eftersom spelaren kunde dodge:a eller springa iväg direkt efter de hade attackerat. Istället för att justera om alla attack animationer bestämde vi att förlänga attack tillståndet spelaren befinner sig i när de attackerar och frysa animationen vid sista frame:et som gav ungefär samma känlsa som karaktären återhämtar sig.

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

Context

Kamern följer efter spelaren med en fast offset bakom och ovanför karaktären. Kameran zoomar in längs sin ray mot spelaren när en objekt hamnar mellan kameran och spelaren istället för att klippa igenom geometrin. I ett spel där timing och läsbarhet av fienders attacker är avgörande valde jag detta systemet framför att dölja geometri eftersom det besvarar spelaren alltid synlig. Om spelaren kan inte se vad bossen gör så är spelet inte längre rättvist.

Detta är ett exempel på Context, miljön ska alltid stödja spelaren, aldrig arbeta mot dem.

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 medans 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 vidare utväkla spelet skulle jag kunna lägga till effekter och ljud när en attack kolliderar för att få attacken att verkligen kännas att den träffar.

Lock-On och Strafe. Lock-on mekanik i souls-like spel innebär att kameran låser sin rotation så att den är alltid riktad mot bossen för att spelaren inte ska tappa bossens position ur sikte, det betyder att karaktärens rotation är också låst mot bossen. Det innebär att karaktären rör sig i sidligen eller strafe:ar och 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 den 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 animation layers som innebär att vi delar upp övrekroppen och benen. På det sättet kan övrekroppen fortsätta spela sin idle animation medan ett separat layer hanterar benens rörelse beroende på vilken riktning karaktären strafe:ar. Det resulterade i att vi behövde skapa nya animationer bara för benen istället för hela karaktären.

Det här är ett effektivt sätt att hålla animationsystemet hanterbar och för att återanvända animationer.

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

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

Rules

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

Jag implementerade dodge som ett eget state i karaktärens tillståndmaskin, 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 änklare att förhindra spelaren att dodge:a medans de attackerar eller block:ar.

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

Stamina system innebär att alla aktiv handlingar som attacker, dodge:ar, block:a ock sprint kostar stamina och det får spelet att kännas mer strategiskt. Om spelaren attackerar för mycket kommer de inte ha tillräckligt mycket stamina för att undvika eller block:a bossens attack. Stamina börjar inte återfyllas direkt efter den har används utan regenereringen är fördröjd. Detta är ett medvetet vaö fär att få spelet att kännas mer strategiskt, spelaren kan inte bara attackera kontinuerligt utan måste läsa bossens mönster och hitta rätt tidpunkt att agera. Stamina är också synligt via UI:en för att spelaren inte ska behöva gissa hur mycket de har kvar och kan fatta mer informerade bslut.

Detta är ett exempel på Rules, stamina sätter gränser för spelaren som gör varje brslut mer strategiskt.

För heal systemet valde vi att ha 3 heals per boss-fight som aktiveras med en knapptryck. Heal:en sker omedelbart och utan animation, dvs. att spelaren är inte låst under processen till skillnad med andra souls-like spel. Vi valde att göra detta på grund av att vi han inte skapa en heal animation och tog inspiration från Armored Core VI Fires of Rubicon där de har ett liknande heal system som vi tyckte passade både vår gameplay och tema. Heal systemet blir istället ett resurs hanterings problem istället för 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 i förväg vart någonstans i min kod saker som exempelvis animation eller ljud skulle implementeras. Jag behövde även anpassa mig för vilka variabler behövde vara hårdkodade eller inte för att ge möjligheten till min designer att balansera spelet.

Efter vi hade bestämt vår MVP(Minimum Viable Product) behövde jag prioretera 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 vekcorna till att sätta upp nätverk. De sex kommande veckorna dedikerade jag en vecka för varje del som behövdes för karaktärkontrollen, och om jag fick tid över skulle jag arbete 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 dömde var det viktigaste men hoppade över till att lösa problem när de dök upp.