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.