v 9 5SD033

Sista crunchen lider mot sitt slut

 

Denna vecka har varit utan tvekan den mest stressfulla veckan under hela kursen. På grund av dålig planering och tidsoptimism har arbetet inte gått som det ska tidigare veckor. Detta har i sin tur har lett till att alla små saker som binder ihop spelet har hamnat på denna veckas planering akut. I början av veckan verkade det inte så fasligt många saker som behövde göras men en sak ledde till en annan och helt plötsligt var listan en mil lång.

 

En av mina främsta uppgifter för den här veckan var att fixa döds animationer för alla fiender då de innan bara förvan på direkten så fort projektilen träffade de. Grafikerna hade jobbat hårt med att göra animationerna och spritesheets så kändes dumt att utesluta dem. Förutom det så ger de spelet en bättre känsla vilket är något vi strävar mot.

 

I spelet har vi en klass vid namn EnemyManager som sköter all spellogik för fienderna och håller dem i en array som kameran använder sig av för att hitta alla fiender i scenen och ritar ut dem på skärmen. Eftersom varken spelaren eller projektiler ska kolla kollision mot döda fiender som fortfarande syns på skärmen så valde jag att separera döda fiender från levande i två olika arrayer. Detta även för att objekten har olika beteende mönster och funktioner beroende på om de lever eller inte. En av fienderna i spelet är en barrel som droppas från toppen av skärmen på slumpmässig position på x axeln. Om en annan fiende eller spelaren kolliderar alternativt skjuter en projektil på barreln sätts en timer igång och en animation spelas upp. Om en fiende eller spelaren befinner sig i närheten av objektet när en exploderar dödas fienden automatiskt och spelaren tar skada.

VI planerar att i mån av tid lägga till att objekt i en viss närhet av barrel men som är nog pass långt borta från den ska slungas en bit bakåt när den exploderar då ett objekt som exploderar i vatten skapar en svallvåg. VI tänkte lägga in det för att ge spelaren mer feedback på vad som händer i spelet och för att försöka skapa en wow faktor.

 

När spelaren tidigare dog gick spelet direkt till highscoren för att skriva in sitt namn men vi tyckte att det var för tråkigt så vi valde att lägga till en dödsanimation till spelaren som spelas upp när spelaren får slut på liv. Och för att göra det mer dramatiskt skapade jag en funktion i kameran som jag kallar på medan dödanimationen spelas upp. Den gör så att spelaren och GUIn är det enda som vissas på skärmen och resten ersäts av en svart bakgrund.

V 8 5SD033

I måndags var det beta presentation av vårt spel Mermaid River som vid det tillfället inte nådde upp till våra förväntningar som vanligt. Vi hade implementerat alla mekaniker och olika objekt men saknade estetiska delar so som en paralax bakgrund för att få en bättre känsla av djup i spelet. Enligt mig gick dock presentationen bra och vi fick bra feedback och i princip ingen kritik angående de designbeslut som vi har tagit. Mina uppgifter för denna veckas sprint som även är den näst sista innan spelet ska vara inlämnat är väldigt varierande mot varandra. De största fokuset för mig har varit att knyta ihop påsen och se till att alla komponenter verkligen fungerar ihop med varandra och att leta efter buggar som tack och lov inte har varit många hittills.

 

En av de delarna som inte var fullständiga denna vecka var feedbacken till spelaren angående vad som händer och hur spelaren gör framsteg och hur hen blir belönad för sina framsteg. I spelet har vi implementerat en rom flaska som är en powerup med funktionen att sakta ner tiden. Eftersom vårt spel är en endless runner så kommer svårighetsmomentet in i form av att hastigheten ökar stegvis ju längre man kommer och fienderna blir snabbare. Och då är tanken att när man aktiverar rom flaskan vilket delvis som nämnt innan saktar ner tiden men även gör skärmen skakig för att simulera att spelaren är full.

 

För att få detta att funka behövde flera komponenters delar ändras och vissa funktioner läggas till. För att rendera alla sprites på skärmen har vi en kamera klass som tar alla objekten och renderar dem i ordning. I kameran la jag till en funktion som förflyttade kamerans relativa position i förhållande till sitt urprung. Problemet om uppstod var att spritesen har sin egna position och istället för att ändra allas riktiga position som skulle kunna förstöra andra mekaniker så som kollision. Lösningen på problemet blev att jag kopierar deras data tillfälligt och sätter deras position till kamerans nuvarande position. Då renderas spritesen ut på rätt ställe relativt till kameran men objektens ursprungliga position ändras inte vilket förebygger att mekaniker så som kollision inte påverkas av att kameran skakar.
Sedan la jag in GUI element till spelarens heads up diplay för att visa hur många mynt spelaren har plockat upp och hur långt man har tagit sig sen man startade spelet. Dessa delar består av en sprite och en text del som för mynten plussas på i pickup managern och för distansen plussas på varje delta sekund i game state updateringen.

5SD033 v 7

Vi börjar nära oss sista milstolpen innan spelets produktion slut nämligen beta presentationen. Veckan som har gått har varit full av händelser både bra och dåliga. i måndags var det pre-beta spel testning och vårt spel mötte inte den standarden och mål som jag och övriga gruppen hade satt. På grund av omständigheter efter alfan var vi tvungna att programmera om i princip hela spelets struktur för att inte bara få ett fullt fungerande spel utan också ett spel med en kod struktur som är lätt att navigera i och som är sorterart på ett bra och rimligt sätt.

 

Min huvudsakliga uppgift denna vecka var att konstruera powerup och enemy systemen inför beta presentationen. Det låter kanske som två separata delar av ett spel vilket det är till en viss del men samtidigt är dessa system så pass beroende av varandra så att jag räknade det som en uppgift. Dock kodvis delade jag upp dessa två komponeter i två managers, en för enemies och en för powerups. Enemy managern håller koll på alla fiender som existerar i spelet och den uppdaterar dess positioner för varje frame. I designen till spelet har vi bestämt att fiender ska kunna komma in från både höger och vänster sida av skärmen och därför slumpar enemy managern ut vilken sida fiende objektet ska starta och viken postion på y axeln som fienden ska komma in på.

 

Powerup managern håller koll på både vilken powerup som spelaren använder och i annat fall använder den spelarens vanliga vapen och projektilerna som powerupen eventuellt avfyrar. Dock finns det en powerup som spelaren kan plocka upp som inte avfyrar en projektil och det är rom flaskan. Den saktar ner tiden så att spelaren hinner planera sin strategi bättre men det kommer till ett pris nämligen att skärmen blir skakig och suddig för att simulera att spelaren är full.

För att få en powerup i spelet måste man vänta en viss given tid innan en slumpmässig typ dropas i spelet. Men om man dödar fiender med sitt vanliga vapen eller med en powerup kortas tiden ner med ett visst intervall för varje dödad fiende. Allt detta räknas ut i managern och den droppar en ny powerup i spelet när kriterierna för den är uppfylld. Då powerups spawntid varierar beroende på hur många fiender man har dödat så verkade det rimligt att samma klass kollar kollision mellan projektiler och fiende objekten.

SSD033 Vecka 6

Vårt spel Mermaid River är en bra bra bit på väg mot sitt slutstadie. Dock har ett av de viktigaste visuella elementen nämligen animationer hamnat långt ner på listan över saker att göra. Därför var veckans uppgift för mig att implementera ett sådant system i spelet då vi börjar närma oss redovisningen av beta variationen. Från första början var det tänkt att det skulle ha varit klart innan presentationen av alfan men tyvärr drabbades vi av stora tekniska problem vilket gav animations systemet en låg prioritet. Vi hade tänkt oss först att bara animera karaktären och fienderna när de rör sig på banan. Men efter reflektioner som vi fick under vår presentation av spelet i alfa stadiet kom det upp förslag på andra saker som man skulle kunna animera för att framhäva vad objekten faktiskt är. Ett typiskt exempel på det är våra luftbubblor som i alfan inte riktigt likande en faktiskt bubbla då den var stel och såg mer ut som en pärla. Läsningen på vårt problem blir att animera den så den aldrig behåller samma form utan deformeras som en riktig luftbubbla skulle göra i vatten.

 

Till sfml finns ett tillägs bibliotek som heter Thor innehållande färdiggjorda komponenter  för animering av grafik och för partikel system. Vår första tanke vara att använda dessa färdiga komponenter för att snabbt och effektivt implementera animationer i spelet men så blev inte fallet. Pågrund av brist av tid och tekniska svårigheter struntade jag i att använda Thor och byggde istället mitt egna system för att animera objekt. Systemet vi har nu består av en klass vid namn AnimationClip och en klass som kontrollerar och håller alla pågående animationer i spelet vid namn AnimationManager. För att skapa en animerad sprite krävs en textur och flera koordinater för varje bildruta. I animations hanteraren laddas en textur in och en text fil som har alla koordinaterna. Därifrån läser programmet av alla koordinaterna och skapar rektanglar som senare används för att bara rita ut vissa delar av texturen för varje frame. I AnimatipClip klassen kallas en updaterings funtion som har en timer med tiden för varje frame. När timern är nere vid noll byter klassen vilken bildruta som ska vissas och återställer timern. AniamtionClip innehåller också ett hastighetsvärde som vid modifiering kan öka eller sänka hastigheten i hela animationen
I AnimationManager har jag lagt till några extra funktioner som kan stoppa, starta och pausa alla animationer på en och samma gång istället för att kalla på en sådan funktion i alla objekt som har någon form av animation. Detta kommer användas när spelaren pausar spelet för att komma åt kontrollpanelen då spelet inte ska forsätta köra i bakgrunden.

5SD033 Vecka 5

Denna vecka har varit fylld av problematik när vi skulle binda ihop säcken inför alfa presentationen på fredag. Vår repository på bitbucket slutade funka så att när man drog ner projektet försvann alla systemfiler på vägen och projektet gick ej att kompilera i Visual studio. På grund av detta fel hamnade vi efter med allt som var planerat att göras enligt sprint planen. Mina huvudsakliga uppgifter denna vecka var att skapa ett animationsystem och att se till att alla komponenterna i spelet skulle funka ihop med varandra inför presentationen av spelet.

 

För sfml media biblioteket finns ett tillägs bibliotek vin namn Thor library med funktioner och klasser som bland annat hanterar animation och partikel system. Vår plan var att använda oss utav Thor för att på in animationer i spelet innan redovisningen. Men tyvärr på grund av problemen med att få  vår repository att funka så fick det läggas på is.

 

Efter felsökning och handledning med lärare fick jag tillslut repostioryn på bitbucket att fungera. Problemet var en fil som heter git ignore vars uppgift är att ignorera synkning av filer som redan finns i ens program map där alla filer i spelet hamnar. Gick in och ändrade kommando som berättar vilka filer som ska ignoreras av bitbucket och sedan funkade allting som det skulle.

 

Nästa del av min uppgift för veckan var att sätta ihop spelet till ett fungerande stadie. Inför alfa presentationen av spelet fanns en del funktioner som var tvungna att vara med. Jag skapade en class med namnet State_Game som skulle sköta all logik medans spelet kör. Komponenterna som var färdiga sen innan som till exempel spelar rörelse systemet och fiende systemet saknade en del externa komponenter för att kunna fungera ordentligt. Kollision var ett av det viktigaste systemen som saknades för att spelet skulle fungera. Alla komponenter som ska ha någon form av interagerande betende i spelet är tvungna att ha en så kallad collider. Så jag skapade två typer av colliders, en box och en cirkel collider. Sedan skapade jag en klass som hanterar uträkningar av kollision. När man kallar på den identifierar den vilka två typer av colliders som man vill kolla och beroende på vilken typ det är så kallar den på olika funktioner för uträkning.
Nästa system som jag var tvungen att göra för att få spelet att fungera var ett slumpsystem för vart fiender och pickups skulle sättas in i spelet. Detta pågrund av att spelet ska vara endless runner och kan därför inte ha fasta punkter som alla objekt ska finnas på. Fiender och pickups instansieras med olika tids intervaller för att inte allt ska komma samtidigt i en enda stor klump.

5SD033 Vecka 4

Veckans uppgift i spel projektet var att programmera ett system för powerups. Min första plan var att göra en base klass med alla olika powerup child klasser för att lättare hantera deras funktioner i player entity klassen. Två av spelets powerups är en kanon och en harpun som kräver projektiler för att användas. skulle hantera deras funktioner så som kollision och rörelse i powerup child klasserna. Efter konsulterade med Tommie angående vilka system vi behövde ha i spelet för att få det fullt funktionellt, hur dessa system skulle kommunicera med varandra och hur de är beroende av varandra ändrade jag upplägget på hur jag skulle gå tillväga med det. Eftersom highscoren är beroende av de fiender som dödas med hjälpa av powerups så behövde jag ett effektivt system där vapnen i spelet kommunicerade med projektilerna, spelar objetet och klassen som hanterar highscoren på ett effektivt och strukturerat sätt. Därför gjorde jag om systemet till att jag har en powerup manager som håller i vapnen, projektilerna och samtidigt rapporterar till highscore managern när en av projektilerna har träffat en fiende och ska ge mer poäng. I powerup managern finns en array med alla projektiler som existerar i scenen, en pointer till powerup vapnets klass som är aktiv och en pointer till spelar objektet. I själva projektil objektet finns bara spriten, collidern och hastigheten som variabler för att all förflyttning och kollision kollas och sker i managers update funktion. Eftersom en powerup i spelet enbart ska vara användbart under ett visst tidsintervall så finns minskar en timer i powerup managern och när den går ner till noll tas vapnet bort och spelaren återgår till sin ursprungliga state. Den sista typen av powerup som finns tillgängligt är en rom flaska som är tänkt att sakta ner spelets runtime till slow motion under en viss begränsad tid för att spelaren ska kunna få mera tid på sig att utföra sin strategi. Men den gör också skärmen suddig och skakig för att simulera att spelaren är “full”. Därför behöver också powerup managern tillgång till scenens kamera klass och tids manager för att kunna påverka alla icke statiska objekts hastighet så de stämmer överens med spelarens egna tids skala. I systemet använder jag mig av polymorfism principen med en base klass för alla olika objekten som tillhör samma kategori för att kunna använda en variabel för flera olika objekt. Detta underlättar under spelets run time då de olika objekten har nästan identiska funktioner som behöver kallas på i update. Det arbete som resterar denna vecka är att göra klart slow motion powerup och att koppla kameran till powerup managern för att de ska kunna kommunicera med varandra.