Power Up HUD

Så, sista veckan för spelet är här och dom sista bitarna av spelet börjar falla på plats. Det har inte varit så mycket sömn den här veckan då vi har behövt arbeta väldigt mycket eftersom att det har varit många saker som ska läggas till i spelet. Och det är även många delar som har finslipats.

Den här veckan har jag och Anton jobbat tillsammans med en väldigt intressant sak, det vi gjort är en HUD för power upsen. Och men i huden så ska gjorde vi så att alla power ups är svarta bilder innan man har plockat upp dom men i la även in en pil som ska visa vilken av de tre olika power upsen som man har vald.

Det första problemet uppstod innan Anton började hjälpa mig, och det var när jag skulle få bilderna att ritas ut på sidan av skärmen. De ritades inte ut, men när Anton började hjälpa mig så fick vi dom att ritas ut, dock så ritades hela sprite sheetet ut och inte bara den delen vi ville rita ut. Detta hände för att vi hade satt att bilden skulle laddas in som en animerad textur och sedan uppdaterade vi aldrig den så den ritade alltid ut hela bilden. Vi ville även sätta så att innan man hade plockat upp skulle bilden vara helt svart, vilket inte var svårt att fixa det var bara att använda SFMLs egna funktion för att ändra färger. Och sedan när spelaren hade plockat upp en power up så satte vi så att bilden fick sin vanliga färg igen.

Sedan när vi hade fått bilderna att ritas ut så skulle vi rita ut en pil som gick upp och ner till vänster om power up bilderna. Pilen ska illustrera vilken power upp som är vald. Detta löste vi genom att skapa en variabel som börjar på 1 och sedan ökas med 1 varje gång spelaren klickar på space knappen. Knapp tryckningen kollar vi i vår huvud klass där vi har vi en funktion som kollar om spelaren trycker ner knappar. Och när variabeln hade siffran 1 så var en power up vald, sedan när variabeln blir mer än 3 så sätts den till 1 igen.

När vi hade lyckats få så att spelaren kan växla mellan vilken power up som är vald så började vi fundera på hur vi skulle kunna få så att spelaren kunde använda den valda power upen om den är upp plockad. Vi visste inte riktigt hur vi skulle lösa detta så vi frågade den tredje programmeraren i vår grupp Philip. Han kom med ett antal förslag hur vi skulle lösa det. Vi beslutade att göra så att spelar klassen kollar klassen för power up HUDen om man har plockat upp power ups men även vilken power up som är aktiv. Och eftersom att vi gjorde så så blev spelar klassen väldigt beroende utav klassen för power up HUDen vilket inte är så bra, men vi hade tid att göra det på ett bättre sätt så vi gjorde klart den nu i slutet.

Fixa med HUD, Grupp 4 post #5

Efter vår beta presentation så sa Markus att han tyckte att vi skulle flytta på vår luftmätare för spelaren. Detta var något som vi hade funderat på att göra då vi kände att den låg i vägen för spelaren. Den låg från början högst upp på skärmen men eftersom att spelaren måste åka högst upp på skärmen så blockerade den vyn för spelaren. Så vi bestämde att vi ville både luftmätaren lägga den på vänster sida av skärmen, vi valde även att flytta vår poäng och multipliern för poängen till den nedre delen av vänstra sidan.

Vi hade innan hårdkodat allting för luftmätaren och poängen så det var väldigt lätt att flytta allting. Men det tog ett tag att få allting på rätt plats och att få det att se bra ut. Mycket av det som tog tid var att varje gång jag bytte en siffra så var jag tvungen att starta upp spelet för att se hur det såg ut. Och vi har väldigt stora bilder i vårt spel vilket gör att det tar lång tid att starta upp. Sedan var jag även tvungen att rotera vissa av bilderna vilket i sig inte är svårt men när de var roterade så bytte jag origon på dem så att skulle bli lättare att flytta runt dem.

Det uppstod inga riktiga problem med att flytta på bilderna det tog bara lång tid eftersom att spelet tar en stund att starta upp men det var även tidskrävande att hitta på alla ställen vi bytte position på vissa bilder. En av de jobbigaste sakerna att flytta på var lungorna som vi har bredvid vår luftmätare för att visa att det är luft. De var jobbiga att flytta för att när vi kör en uppdatering på alla saker i vårt spel så uppdaterar vi även dem för att kolla om man har lite luft för då ska de bli större och röda. Men i uppdateringen så sattes dom även på en ny plats på skärmen. Jag märkte inte detta i början för det händer bara när spelaren får under en viss procent med luft, och jag kollade bara när jag startade upp spelet om allt låg på rätt plats. Jag märkte det dock när jag spelade igenom spelet senare och var då tvungen att leta upp vart de sattes på ny position på skärmen. Men när jag väl hittade vart det var så fixade jag snabbt så att de sattes på rätt plats.

Den övre bilden är innan jag flyttade luftmätaren och allting och den nedre är efter att jag flyttat allting.

Arbete med musen i menyn, grupp 4 post #4

Ännu en vecka som är över och den här veckan har jag arbetat med ett par olika saker, men främst med att lyckas göra så att man kan använda musen i menyn. Förut så har vi haft så att man navigerar runt med piltangenterna och väljer med enter-knappen. Men under speltestningen så var det många som försökte navigera runt i menyn med hjälp av musen och sedan tog det ett tag innan de förstod att man behövde använda piltangenterna där. Sedan när de väl började spela spelet så styr man karaktären med hjälp av W, A, S, D och skjuter med musen. Men eftersom att man inte använde musen i menyn så var det många som släppte musen när de lyckades med att starta spelet. Vi diskuterade det i gruppen och kom fram till att vi ville navigera med musen i menyn istället för med piltangenterna.

Så nu till hur jag lyckades göra så att musen kunde klicka på en knapp och sedan starta spelet eller klicka på exit. Det svåraste var att kolla om musen var på en av våra knappar, detta var dels svårt då jag inte har jobbat med någonting i vårt spel som använder musen. Sedan när jag skulle kolla om musen var på en knapp så glömde jag att jämföra musens x-och y-position i spelet med knappens x-och y-position. Jag fick reda på detta när jag frågade en annan programmerare i min grupp om hjälp. Det var ett lätt fix genom att ta knappens storlek och kolla om musen var innanför knappens koordinater.

Sedan glömde jag även att fixa så att musens position kollades relativt till spelskärmens storlek. Det var inte heller svårt att fixa för en person som har lite mer erfarenhet inom programmering men för mig så var det ett problem. Så därför bad jag även här en annan programmerare i gruppen om hjälp. Det han sa att fattades var att jag skulle skriva en funktion som tog musens position och jämförde med storleken på spelets skärm. Detta skrev jag först högst upp i klassen men fick snabbt tipset om att jag skulle lägga in det i update för klassen. För när den inte låg i update så uppdaterades inte musens position vilket ledde till att den inte gick att använda.

Senare när det var klart så skulle jag lägga till så att jag kunde klicka med musen på knapparna när jag höll musen på en av dem. Det var inge problem krävdes bara att man kollade att om musen var på tillexempel start knappen och att om vänster musknapp var nertryckt så skulle spelet gå ut från menyn och starta spelet. Det var den lättaste biten av allting. Det som återstår att fixa i menyn just nu är att jag ska lägga till så att när musen är över en knapp så ska den byta färg. Men jag ska även lägga till en meny för inställningar där man kan ändra volymen för ljuden i spelet.

En till fiende, grupp 4 post #3

Den här veckan har jag jobbat med att skapa en till fiende som vi ska ha i spelet. Fienden som jag har arbetet med är en piraya som åker upp och ner på skärmen samtidigt som den åker mot vänster. Detta kommer inte att vara den vanligaste fienden så därför bestämde vi i gruppen att den skulle göras den här veckan då vi redan har gjort färdigt den vanligaste fienden.

Det uppstod inte så många problem när jag skulle skapa pirayan då jag förra veckan gjorde vår första fiende till spelet. Så jag hade redan hyfsat bra koll på vad som behövdes för att skapa den fiende. Ett problem som uppstod var dock att när jag skulle rita ut pirayan så blev det något fel med den koden som gör att de inte ritas ut. Jag har tyvärr inte lyckats med att lösa detta problem än och vet just nu inte vad det är som gör att det blir fel. Det kommer inte heller upp något felmeddelande vilket gör att det blir lite jobbigare att hitta vad det är som krånglar. Men jag tror att det är i vår huvudklass som det är fel i, det var inte jag som gjorde att vår andra fiende ritas ut så det är nytt för mig. Så jag kommer sitta imorgon och försöka lista ut vad det är som gör att dem inte ritas ut.

Eftersom att pirayan inte ritas ut så kan jag inte med säkerhet veta om rörelsemönstret för dem är som jag vill att det ska vara. På bilden nedan så visas rörelsemönstret för pirayan. Bilden är inte från spelet då jag som jag skrev innan inte lyckats med att få pirayan att ritas ut än.

 

Då grafikerna har arbetat på en annan fiende som vi ska ha med i spelet, en manet som görs av en annan programmerare, så har vi ännu ingen animation till pirayan. Så även om jag skulle kunnat få den att ritas ut så hade jag inte kunnat testa den med rätt animationer. Men det kommer in i spelet nästa vecka.

För att få så att pirayan inte åker uppåt eller neråt varje gång den kommer så satte jag så att när den skapas så får den ett slumpmässigt värde mellan -1 och 1. Detta värde är det som styr hur mycket den ska åka i Y-led. Så alltså den får ett slumpmässigt värde som avgör om den börjar med att åka uppåt eller neråt på skärmen.

Power up, grupp 4 post #2

Då har en till vecka gått förbi och det har varit en helt okej vecka om man kollar programmeringen som har gjorts för min del. I slutet av förra veckan så satt vi i grupp 4 och gick igenom vad vi behövde för saker till Alphan. Vi kom fram till ett par olika saker som fortfarande behövdes göras eller fixas till innan Alpha. En av de sakerna som behövdes göras var att vi behövde ha en power up i spelet, och i vårt Game design dokument så hade vi skrivit att vi ville ha med totalt tre stycken power ups i vårt spel. Men eftersom att vi inte skulle ha tid till at göra alla tre power ups till Alphan så fick vi bestämma vilken som var viktigast för spelet. Vi kom fram till att vi tyckte att det var vår amulett power up som var viktigast och att det var den som vi skulle fokusera på. Power upen gör så att spelaren inte kan ta skada under ett visst antal sekunder.

När jag skulle skapa amuletten så började jag med att bara göra en klass som bara gjorde så att jag kunde rita ut Amuletten. Ett litet problem som jag stötte på när jag skulle rita ut animationen för amuletten var att jag glömde att sätta hur lång tid varje bild skulle visas vilket ledde till att bara var den första bilden som ritades ut. Jag lyckades hitta vad det var som jag hade gjort fel genom att kolla jämföra vad jag hade skrivit med andra animationer som vi har i vårt spel. Så det tog inte allt för lång tid innan jag hittade den lösningen.

Ett annat problem som jag hade var att jag skulle få vår avatar att byta till ett nytt state när man simmar och plockar upp amuletten. Jag googlade runt men lyckades inte riktigt hitta ett svar som kunde hjälpa mig att förstå hur jag kunde göra det på bästa sätt. Så det jag gjorde då var att jag frågade en annan programmerare som hade gjort en meny till sitt spel. Han förklarade att med hjälp av State managern som vi redan har i vårt spel så kunde jag göra en funktion som kollade om avataren plockat upp amuletten så kunde jag byta state på avataren. Med hjälpen från honom så lyckades jag tillslut få avataren att byta från sitt vanliga state till ett state där han inte kunde ta skada under ett antal sekunder.

Grupp 4 -kollision

För några veckor sedan så valde min grupp ett koncept på ett spel och konceptet som vi valde var på spelet Mermaid river. Det är ett spel där man spelar som piraten Skip Leg Day och man ska simma och leta efter sin besättning och sin skatt som har blivit stulna av några onda sirener. Man simmar och plockar upp mynt som sirenerna har tappat eftersom att man inte kan låta någon annan ha den skatten som man har plundrat till sig

Spelet är ett 2D side-scrolling shooter spel. Det utspelar under vatten och spelaren möter olika fiender i form av fiskar som har olika rörelsemönster men det finns även svårare fiender vilket är sirenerna. Eftersom att man är undervatten så har man en harpun som vapen och det tar ett tag att ladda om den så mycket fokus ligger i att skjuta vid rätt tillfälle och att man måste undvika fiender istället för att skjuta dem. Och eftersom att det utspelar sig undervatten så måste man då och då simma upp till ytan för att hämta luft vilket leder till att man måste planera hur man simmar.

Det känns som att det har gått bra för både programmerarna och grafikerna i vår grupp den här veckan. Det har inte uppstått några problem som är allt för stora eller inte gått att lösa hyfsat fort.

Den här veckan har jag valt att jobba med kollision. det jag har gjort är att skapa en klass som säger hur stor kollisionsboxen är för varje bild. Sedan efter det så gjorde jag en klass som tar kollisionsboxen och sedan kolla om den är på samma x eller y position som en annan kollisionsbox.

Vi har dock tyvärr inte riktigt kunnat testa om kollisionen fungerar som jag vill att den ska fungera då vi inte har ritat ut fiender eller gjort så att spelaren kunnat skjuta. Detta har gjort så att vi inte riktigt vet om kollisionen fungerar som den ska eller om den fungerar över huvud taget. 

Ett problem som jag stötte på när jag skrev klassen för kollisionen var att jag inte visste hur man använde  rektanglar i biblioteket som vi använder oss utav. När jag sökte efter en förklaring på internet så missförstod jag till en början hur det fungerade. Men efter ett stund av läsning på internet och diskussion med andra programmerare så förstod jag hur det fungerade och kunde då komma vidare med koden.