Projektrapport

Projektstatus

När projektet började var vi mer engagerade i att skapa en motor istället för att börja prototypa de olika delarna av spelet såsom stealth, flygande och fiender. Hade vi börjat med att prototypa istället för att försöka skapa en motor så kan projektet sett annorlunda ut nu. Det är möjligt att vi hade vetat mer om de olika funktionerna vi planerat, men trots allt är vi relativt nöjda med hur vårt arbete med spelet skett under de senaste veckorna.

Det kan bli svårt för oss programmerare att kunna implementera vissa funktioner utan grafiska assets. I väntan på grafiska assets har vi programmerare inte mycket att göra och om efter ett speltest i får feedback att redigera ett grafiskt element så drar det tid från andra assets. Som tur har vår grupp överskott av grafiker så att uppgifterna kan spridas ut mer, men det resulterar också i att den estetiska stilen kan bli skev.

Faktumet att vi skrev en statemanager så pass tidigt i spelet kan ha dragit vår uppmärksamhet från “köttet” i spelet, det faktiska spelet, så vi kan ha spenderat för mycket tid på saker som egentligen är helt onödiga innan

Alla fiender, och därmed alla planerade obstacles, har hittills blivit implementerade, med AI, rörelse, m.m. Ljud finns för maskin och artillerield, men animation är ännu inte implementerad eller färdig som spritesheets till fiender. Det kan dock behövas testas för att justera svårighet ytterligare.

Kollision finns men för enkelhetens skull använder vi SFMLs sprites inbyggda funktioner, vilket innebär att kollision kollas med kollisionslådor som är lika stora som Spriten de utgår ifrån. Detta skulle gå att förbättra genom att definiera en floatrect som en slags collider vars position är relativ till sin sprite.

Designval

Låter kanske lite klyschigt men vi är nöjda med de designval vi har gjort. Vi valde att tänka lite “utanför lådan” och istället för att göra en generisk side-scrolling space shooter så gick vi åt ett mer “Asteroids” håll. Där kameran följer spelaren och hen har ett stort område att röra sig fritt på. Eftersom den estetiken vi tog från konceptet var baserat runt flygplan gav vi spelaren och fienderna rätt så verklighetstrogna beteenden. Vi försökte ge planet en känsla av vikt, att man kontrollerar ett fordon. Men då blev vi också tvungna att utforma en AI som presenterar en utmaning för spelaren att både undvika och slåss emot.

AI

AI-koden är en så kallad “finite state-machine” vilket funktionellt är en pekar till en AIState, som ändras till olika states som ärver av den pekarens klass.

Fiender har en klasshierarki, som används för att iterera genom dem för att uppdatera, rita ut dem, osv. Detta gör det enklare att använda AI:n, då alla funktioner som används relativt till fiende-entiten när den nämns i AI-koden, kan härledas till olika typer av fiender.

Fiendetyperna är följande; Flygplan, Luftvärn och Zeppelinare.

Flygplanen har den mest involverade AI:n, men även den är relativ simpel med tre states som växlas mellan. Flygplanen patrullerar kartan och om de ser spelaren så börjar de jaga och skjuta denne.

Zeppelinaren har också en del av AI-koden men endast för att kunna patrullera runt på kartan, då den är mer av en “passiv” fiende som signalerar andra flygplan att anfalla om spelaren är i dess närhet för länge.

Luftvärnets beteende är så pass enkelspårig och annorlunda från de andra fiendernas att AI till den inte skulle tillföra något. Istället skjuter den mot spelaren efter att en tidsintervall passerats och spelaren är inom dess räckvidd.

Prestanda/Optimering

Något vi fortfarande har problem med är hur spelet uppdaterar när vi debuggar, spelet kan köras bra men bara på en av våra datorer och när laddaren är ikopplad. Vi har försökt hitta olika lösningar men har inte lyckats. När vi pratat med andra grupper har de haft samma problem.

Sourcetree/Repositories(?)

Något annat som också orsakade en hel del problem för oss är SourceTree, vi var väldigt förvirrade med hur vi skulle skapa branches och sedan merga med huvud branchen. Sedan när det står att en branch är “2 behind” har vi ingen aning vad det betyder och ibland dök en commit inte upp för en av oss, men var fullt synlig för de andra två. Så de första veckorna blev vi tvungna att skicka koden via skype eller skicka .zip filer till varandra. Vi tycker att en lektion där vi undervisas hur man skapar en branch, hur man “comittar”, “pullar”, “pushar” och “mergar”. Hade vi fått en sådan lektion innan arbetet började tror vi att vi kan ha undvikit mycket av de problemen och den huvudvärken vi led av.

Kodrecension av Player från Grupp 8

Spelarklassen behöver, utöver sfml-header och system-headers:

”ProjectileManager.h”
Används för att lägga in olika typer av projektiler; de läggs in i vektorer och uppdateras, ritas ut och tas bort i den klassen.
Ljud för skott och liknande ligger här, och skulle kunna läggas in i en soundmanager istället, möjligtvis genom att låta spelaren ta in SoundManager som en parameter och använda den som parameter i ProjectileManager.

”Planet.h”
Används för att kolla ifall en sektor är öppen eller inte. Spelarens ”radiusPos” sätts också till Planets ”getRadiusSize()”.

”AnimatedSprite.h”
Ärver av sf:Sprite, och lägger till funktioner för att uppdatera och lägga till frames samt kolla deras livstid.
Spelaren använder sig av Animated sprite för att animera sin kanon.

Texturer skulle kunna läggas i en manager, just nu läggs de in i en vector separat i spelarens klass.

Alternativt skulle man också kunna lägga draw-funktioner från spelaren till någon slags DrawManager för att kunna, bland annat, bestämma i vilken ordning spelaren ska ritas ut gentemot resten av sprites.

Input för spelaren ligger i Update och skulle kunna flyttas till en InputManager.

About Erik Nord

2015 Programming

View all posts by Erik Nord →