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.