General Tweaking

Hello. I haven't done that much this week, wich is quite strange considering that there is only one week remaining of the project. I would have done more but the truth is, I’m not entirely sure what there is left to do (that we still have time to implement and test properly). So, what I’ve actually done this week is: found some memory leaks and fixed them. We store all of our game objects in 2-3 vectors in our gamestate so that we easily can use them to check for collisions and stuff like that. The problem was that we didn’t delete them after each time we’ve used them, but instead just exited the gamestate went into the upgrade state and then back to the gamestate just creating them again. I’m not entirely sure why someone havn’t done this earlier but hey, it’s there now and that’s the important part. Another thing that I will do this weekend is fix our start menu. Currently it’s a bit buggy at best. That is if you don’t hit the “Options” or the “Exit” buttons. If you do, the whole thing crashes. The other thing that I am going to work on is the mouse tracking in the main menu. Currently it’s a bit off, so when you try to click on the “Start Game” button you have to click the bottom of it for anything to happen. I kinda know what the problem is, namely the way I wrote it to check if the mouse position is on the button doesn’t include any code to calculate the frames of the window, so it calculates the buttons positions via the upper left corner of it. This is possibly a not so good idea but that is why we are updating it. Another thing that I will be doing this weekend is adding the final art to the graphical user interface and reposition the things so that they fit together nicely:

This will probably take a bit of tweaking since the background art is a bit too big for the rest of the things and needs to be scaled down a bit but I am certain that I will get it done. After all, I don’t have much else to do and coding is fun =). I thing that will have to do for this week, the last of blog posts for the Gamedesign – Intro course. Overall I’d say that it’s been a quite interesting and fun experience that I’ve learnt quite a lot from. Let’s just hope that the things stick aswell =p

Good luck with the Theme-Park in a couple of weeks.

/Robin K

Levels och Gui

Denna vecka har jag mestadels suttit och pillat med levels. Vi tyckte att det var hög tid att lägga in detta i och med att betan är nu imorgon. Så det första jag gjorde var att skriva en level klass. Den håller koll på vilken dag och vilken vecka det är, vilket tillsammans utgör levels. Den håller även koll på hur många barn som ska finnas på varje nivå. Efter varje nivå kommer man till uppgraderings skärmen där man ska kunna välja uppgraderingar (vi har inte lagt in några uppgraderingar än, men det kanske kommer någon gång nästa vecka). För tillfället ligger där istället en bild som säger att man ska trycka på C för att komma vidare. Just nu fortsätter spelet även i all oändlighet, vilket vi också ska lägga in så att det tar slut. Eftersom vi redan har funktioner i level klassen kommer detta förmodligen att gå ganska snabbt och smärtfritt.

När jag hade lagt ihop min level klass med allt det andra upptäckte jag en ganska intressant bugg. Så fort man kom till nivå 3 och försökte läsa in den så kraschade spelet. Det tog en liten stund att lista ut vad problemet var eftersom att ”Vector subscript out of range” skulle kunna var vilken som helst av våra 5 vectorer. Jag kom efter en liten stund på att det var en kombination av alla våra vectorer some fick det hela att krascha.

 Vi hade nämligen glömt att tömma dom mellan varje nivå, så att koden fick för sig att storleken på vectorerna var större än 0 och jämförde därför listor utan något i. Detta var ett ganska klantigt misstag av mig, men jag kom ju på vad det var för fel iaf =)

När felet var hittat och återgärdat tog jag mig an uppgiften att implementera våran nya gui: 

Vi tyckte att det var ganska viktigt att få den uppdaterad eftersom vi tils idag hade använt placehoder sprites från google till större delen av våran gui. Detta kan ju ses som mindre optimalt, med upphovsrätt och så. Men förhoppningsvis är det ingen som märker att vi har använt deras bar och bestämmer sig för att stämma en hög med fattiga studenter =p

Förmodligen skulle dom inte kunna lyckas med detta, men man vet ju aldrig riktigt säkert.

Men det var allt som jag hade att skriva om den här veckan, se till att ha det bra nu under dom två sista veckorna av kursen.

Visuell Feedback

Hej igen, jag har denna vecka suttit och pillat med visuell feedback. Jag började veckan med att sätta mig ner och börja klura på hur jag skulle få animationer att fungera. Min första tanke var att använda mig av kod jag har skrivit till spelprogrammering1 men detta misslyckades fatalt, av anledningar som ingen verkar kunna lista ut. Det hela funkar som så att jag har en textfil som berättar vad av en bild som ska visas och detta laddas in och sparas som variabler i en Animations Klass. Sedan har animationsklassen en uppdate funktion och en draw funktion. Om en viss tid har gått sedan föregående animation så ska koden ställa om så att nästa bit av bilden visas på skärmen. Själva laddnings processen fungerar fin fint, men sedan när saker ska sparas i en vector blir det problem. I den delen av koden som dom blir inlästa fungerar allt som det ska, men så fort som koden är färdig med laddningen är allting som låg i variabeln borta. Detta är synnerligen underligt eftersom att variabeln är inte en lokal variabel utan global. Så med andra ord: det borde inte försvinna som det gör. Jag har kollat med flera av mina klasskamrater men ingen av dom verkar kunna komma på någon lösning. Dock har jag alltid varit bra på att komma på problem som ingen har haft eller hört om tidigare.

När jag insåg att jag inte skulle kunna komma på vad det var för fel med koden satte jag mig istället och började skriva kod för att kunna få in mer visuell feedback i spelet (vi har för tillfället inte mycket alls) då detta var en av de sakerna som Markus klagade på under pre-betan. Jag började med att fundera på hur jag skulle kunna lösa det hela och kom fram till att den bästa och simplaste läsningen vore att helt enkelt ändra transparansen på bilden beroende på hur smutsig spelaren/barnen är. Så jag tog och satte mig och gjorde en placehoder sprite (ihop slängd av lita annan art vi hade liggandes) för att kunna testa min kod och se om det skulle kunna gå att göra. det hela var väl inte överdrivet snyggt, men det är ju bara en placehoder, så här blev den iaf:

Mina första försök till transparans ändrande kod var ganska patetiska och misslyckades hårt. Men efter några försök lyckades jag komma på hur jag skulle lyckas göra det hela. Jag har inte lagt in kod för att fixa med barnens transparans, än men det kommer innan det blir måndag och beta =)

Detta var vad jag hade den här veckan, ha de gött.

Enemy Collision

Jag har denna vecka suttit och pysslat mestadels med Barn vs Barn Kollision. Från början tänkte jag att jag kanske skulle kunna använda samma kollisionsfunktion som jag använde till platformern. Detta visade sig vara mycket problematiskt eftersom programmet crashade när jag försökte fixa så att ungarna hade en kollider vilket gjorde det hela en aning problematiskt. När jag kom på att det var för mycket jobb för att fixa bestämde jag mig istället för att skriva en ny, egen funktion som använde sig av cirkel vs cirkel kollision. Detta valde jag för att jag redan använde mig av det för att kolla kollision mellan ungar och svampar. Det hela funkar som sådant att funktionen kollar punkterna på de två olika objekten. När den har räknat ut skillnaden så jämför den dom med radien på objekt 1 och radien på objekt 2. Om skillnaden är mindre än dom två radierna tillsammans så överlappar dom. Annars gör dom inte det. Jag har inte riktigt funderat ut hur jag ska kunna använda detta till min fördel men jag kommer nog på något när jag har blivit lite lagom trött, underligt nog är det när jag är trött och inte vill göra saker som de går bäst. Jag vet inte varför det är på detta vis men det har varit så ända sedan jag var liten. Hmm, tror precis att jag fick en idé. Hurra för sömnbrist ^^. När dom kolliderar blir det en liten (eller stor) bit av cirklarna som ligger över varandra, så om jag tar och skickar med denna lilla bit som överlappar in i barnens updaterings-funktion kommer det att sänka hastigheten på dom om dom överlappar. Om dom inte gör det kommer dom bara att fortsätta vandra som dom gjorde från det att dom dök upp på ”Dagis skolgården”.

Förutom att koda denna vecka har jag dessutom blivit utnämnd till producent. Så jag ska ta och hålla koll på saker och ting, vilket inte är min starkaste sida men jag tar mina uppgifter på så pass stort allvar att dom ska fixas oavsett om det är lätt eller inte. Jag har även börjat fundera lite på att leta efter folk som skulle kunna hjälpa oss och testa spelet någon gång nästa vecka så att vi hinner med att göra ändringar inför betan som är om två veckor. Det hade varit uppskattat om du som läser detta kunde höra av dig, antingen via komentar eller dylikt ifall att du eller någon i din grupp skulle kunna tänka sig att testa och ge kritik när vi är färdiga med att lägga in det vi för tillfället håller på att fixa. Självklart kan vi tänka oss att som kompensation testa erat spel och ge feedback på det =)
Aja, nu tror jag att det får räcka med bloggande för idag. Time to code =D

Overheat och enemies.

Den här veckan har jag suttit och pysslat med en hel del olika saker, bland annat med ett vapen heat system som håller koll på om vapnet kan skjutas eller om det behöver kylas ned. Det hela har en mängd små delar som var och en utgör en viktig del för att överhettningen ska fungera som den borde. Dels har vi variablerna som vårat player object håller koll på så som maximala mängden värme som vapnet kan klara av, mängden värme i vapnet för tillfället och om det har blivit överhettat (om värmen har gått upp till max). Sen har vi i våran game-loop kodbitar som börjar med att uppdatera det visuella, kollar först hur mycket värme som finns i vapnet för tillfället, sedan jämför detta med vapnets maximala värme och ritar ut en del av värme mätaren. Sedan går den vidare och undersöker om värmen är över noll och i sådant fall sänker den värmen lite. Sedan om något skulle gå fel och värmen skulle bli negativ så ändras den till 0. Jag har också lagt in lite kod i delen av koden som hanterar skottlossningen. Där lade jag in några rader som gör att värmen ökar så länge som spelaren skjuter. Anledningen till att vi lade in detta system var att utan det kunde man hålla nere vänster musknapp och fortsätta skjuta i all oändlighet, vilket inte var särskilt utmanande och utan utmaning – inget spännande spel. Vilket skulle i sin tur eliminera halva meningen med att göra spel, för vem vill spela ett spel som saknar utmaning? Troligtvis inte väldigt många. Dock finns det ju även sådana personer ute i världen och till dom har vi planerat lite intressanta grejer som har med uppgraderingarna att göra.

Jag har förutom att pyssla med värmesystemet också fixat lite med fienderna. Jag började med att fixa en extremt enkel pathfinding, dvs att fienderna kollar om spelaren är närmare än 400 pixlar så vänder sig fienderna mot spelaren och börjar vandra mot honom/henne. Skulle fienderna komma närmare än 50 pixlar börjar dom kasta lera på spelaren och vid 10 pixlar kvar stannar dom. Detta lade vi in för att kunna kontra en väldigt mysko bugg vi hade i början av projektet. Denna bugg hände när två fiender hamnade på exakt samma position och resulterade i att båda två försvinner mystiskt.

Men nu tror jag att jag har skrivigt tillräckligt, time to code once more.

Jag har denna vecka för det mesta suttit och pysslat med att få fiender till att fungera. Måttligt framgångsrikt hittills men det ska nog gå att lösas under helgen.
Jag började med att skriva en fiende klass som håller koll på dom gemensamma sakerna för fiender. Fiende klassen ärver från våran spelobjekt klass som jag skrev förra veckan. Spelobjekt klassen håller koll på vad saker och ting är, vad dom har för sprite, vad dom har för collider och flaggor (ifall att vi skulle vilja ha något speciellt på spelobjekt nivå). Fiendeklassen håller sedan koll på saker som är speciella för fiender. Exempel på dessa saker är: Hälsa, om dom kan skjuta eller inte och rörelsehastighet.  Sedan har vi själva fiendetyp klassen, den första är våran standard fiende, dom slöa barnen. Den jag hade mest problem med att skriva, mestadels för att jag inte kom på riktigt vad den skulle innehålla. Efter en stunds funderande kom jag dock på att den bara behöver innehålla rörelsemönstren och attackmönstren för fienden, efter som att det är det enda som skiljer som olika fienderna åt. Så för standard fienden fick det bli ett väldigt enkelt rörelsemönster. Är spelaren inom räckvidd ska dom springa mot honom/henne och när dom kommit fram ska dom börja smutsa ner spelaren. För att hålla minnet på en stabil nivå har jag även gett våran motor en variabel som håller koll på vilken sprite som ska användas till dom vanliga fienderna. Detta för att slippa ladda in bilden om och om igen och därmed skapa minnesläckor. Jag lärde mig att detta kunde vara en bra idé i mitt förra projekt där programmets ram andvändning ökade med 5-10mb/s, vilket inte är riktigt optimalt. Med andra ord, jag ska se till skriva koden mer eftertänksamt den här gången, så att detta projekt inte har några läckor alls. Dock eliminerar det ju min möjlighet att åter vinna tävlingen om vem som har mest minnesläckor, men man kan ju inte vara bäst på allt =p

Här är ett screenshot av hur spelet ser ut för tillfället:

När jag var färdig med själva fiendeklassen (med sub-klasser) började jag att skriva på en timer som kan hålla koll på när det ska komma fram en ny fiende. Det hela tog inte väldigt lång tid eftersom jag redan hade experimenterat lite med hur man skulle kunna göra en timer i SFML (biblioteket vi skriver emot).  Det som gjorde det så lätt var att det redan fans vissa enklare inbyggda funktioner i SFML som räknade uppåt, så det enda som behövde göras var att lägga in ett värde som man skulle börja på och sen när den inbyggda klockan räknar upp, får man ett värde att ticka neråt.

Men men, nog skrivande här. Dags att återgå till kodandet.