[5SD023]Project report och review of a player class

This week we were tasked to write a report on our project and an review on anothers group player class. The latter having focus on coupling and decoupling, which I am still not sure if I have fully grasped, resulting in a rather short review.  The rest of the post will be in swedish.

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 det jag ser har ni lyckats rätt så bra med att hålla er spelarklass så simpel som möjligt och flytta kod till sina egna klasser. Det var också bra att ni använde er av en separat klass för projektiler, men jag skulle också flytta Input hantering till en separat manager.

Sen skulle kommentarer göra koden lite lättare att läsa för andra.

About Bengt Hagnelius

2015 Programming

View all posts by Bengt Hagnelius →