Mole Munch – Dev log 6

Den här veckan har jag jobbat på att få in partikeleffekt i vårat spel. Partikeleffekt är när man laddar in en bild som sprids ut snabbt under en kort period av tid. Exempel på när partikeleffekt kan vara bra att använda är när man vill ge mer positiv feedback till spelaren. Därför bestämde vi oss för att det skulle flyga ut små gröna och röda partiklar när spelaren åt grönsaker. Detta skulle göra upplevelsen att plocka upp grönsaker roligare och därför få spelaren att vilja plocka upp grönsaker.

Det stora problemet som jag hade med partikeleffekten var att koden som vi fick att arbeta med hade några buggar, vilket gjorde att jag spenderade alldeles för mycket tid med att försöka fixa dem. Men när buggarna var fixade så var partikeleffekt relativt enkelt att arbeta med. Det fanns flera olika variabler som man kunde arbeta för att få den effekt som man ville. Variablerna som man kunde modifiera var, ”spread” hur långt varje partikel skulle åka ifrån startpunkten. ”Max age”, den högsta tiden som partikeln kunde vara ute innan den försvann. Man kunde också bestämma hur många partiklar som skulle skapas och hur snabbt dem skulle röra sig. Med hjälp av alla dessa variabler så kan man forma partikeleffekten utifrån vad man är ute efter. Om man till exempel vill att något ska sprängas så kan man skapa en effekt av att alla partiklar åker utåt från punkten i en slumpad riktning. Om man skulle vilja skapa en effekt av rök eller eld så skulle man kunna ladda in en eld textur som sakta rör sig uppåt.

När vi gjorde vår partikeleffekt så visste vi inte från början vad vi var ute efter. Vi ville bara ha ännu en feedback faktor till spelaren för att belöna hen ytterligare. Därför testade vi flera olika sätt att utforma effekten. Effekten som vi valde att gå med var en ganska långsam och liten, vi ville först ha en ganska stor ”spread” och en snabb effekt för att få effekten av att mullvaden snabbt mumsa i sig alla grönsaker, men på grund av att inte detta fungerade så gjorde vi en långsam och liten istället.

Detta är en bild på partikeleffekten just nu, eftersom att våran startposition av partikeleffekten är på grönsaken, detta är något vi måste fixa eftersom att det ser konstigt ut när man sedan går över grönsaken. Men på grund av gamla programmeringslösningar så är detta ganska klurigt att fixa. 

Mole Munch – Dev log 5

I det här inlägget ska jag skriva om hur jag har lagt in feedback till spelaren i form av Ui.

På bilden nedan kan man se hur vårat Ui ser ut när man spelar. Längst ner till vänster av Ui’t finns det två mätare. Ena mätaren räknar antal ”Speed Powerups” som spelaren har tagit, och den andra räknar antal ”Vision Powerups” som spelaren har tagit. Mätaren går sedan upp och ner beroende på hur många som är tagna. Till höger om mätarna så ser ni antalet stenar som spelaren håller i. Om spelaren kastar iväg en sten så ändras spriten till en tom sten sprite. På varje bana finns det ett antal prisbelönta meloner som spelaren ska äta upp. Målet med varje bana är att plocka upp alla meloner. På Ui’t så presenteras detta genom att vi målar ut antal meloner som spelaren tagit, och antal meloner som är kvar på kartan. Just nu har spelaren tagit två meloner och har fyra kvar innan banan är slut. Poängen och multiplikatorn till höger och melonerna är gjorda på ett annorlunda sätt. Poängen börjar som en ”int”, ett värde som håller i heltal. Jag gjorde sedan om int värdet till en ”string”, ett värde som håller i en text. Sedan kunde jag rita ut texten på skärmen.

Detta är vår startskärm som jag har skapat, jag räknar med den som Ui eftersom den är gjord på ett liknande sätt. Startskärmen består främst av flera olika bilder. Den första bilden är bakgrundsbilden, i denna ingår bakgrunden plus en tom tavla. Eftersom att tavlan ska vara med i alla olika alternativ så kan den lika gärna vara med på bakgrundsbilden. På tavlan ligger sedan fem olika bilder. En bild för varje knapp plus en titeltext för att visa för spelaren vilken meny hen är i. Man navigerar genom knapparna med pil upp och pil ner, vi valde att inte navigera med en mus eftersom att vi inte använder någon mus i resten av spelet. Navigationen mellan knapparna är gjorda med ett int värde. Int värdet adderas med ett ifall man trycker pil upp och subtraheras med ett ifall spelaren klickar pil ner. Ifall värdet är till exempel tre så skulle ”CREDITS” knappen lysa upp grön. I detta fallet är värdet ett då ”PLAY” knappen lyser. Sättet jag gjorde markeringen på var att spriten ändrades beroende på vad värdet var.

Om spelaren väljer att klicka sig in på manual så kommer denna tavlan upp lokaliserat till höger av skärmen. Tavlan är just nu bara en enkel sprite. Men vi ska sedan använda samma tavla för att skriva highscore och liknande när man väljer vilken bana man ska spela. Jag har också lagt till ett alpha värde på tavlan så att man ser igenom den lite. Detta ser man även bättre om man kollar på fönstret av ladan. Alpha värdet lade jag till för att tavlan inte ska kännas så inklistrad. Alpha värdet går att implementera direkt när man skapar bilden ifall man sparar den till en png, men är väldigt lätt att fixa i kod.

Mole Munch – Dev log 4

Den här veckan har jag jobbat på att få bort alla minnesluckor som vi hade i vårat spel. En minneslucka är när man lagrar minne på ”heap” minnet. I Vårat spel så skapades minnesläckor väldigt ofta. Varje gång vi gjorde ett nytt objekt så skapades minnesläckor. Så när vi i början av spelet skapade 50 olika objekt som till exempel jordgubbar och mullvaden så uppkom flera minnesläckor. På bilden nedan ser man flera objekt i spelet. Till höger om mullvaden finns jordgubbsplantor, några av jordgubbsplantorna är redan tagna av mullvaden. När mullvaden tagit en jordgubbsplanta så kan man ta bort den. I vårat fall så sätter vi jordgubbsplantan till osynlig och ej aktiv. För att sedan ta bort alla objekt i spelets dekonstruktor. Du kan läsa mer om vår dekonstruktor längre ner i texten.

För att ta bort minnesläckor så måste man ta bort objekten som man skapat. Oftast tar man bort objekten när de inte längre ska vara med i spelet. Man kan som i förra exemplet ta bort objektet direkt när det försvinner ur spelet. Eller så kan man ta bort alla objekt i spelets dekonstruktor. En dekonstruktor är en funktion som kallas automatiskt när ett objekt tas bort. När spelet körs så är spelet i ett så kallat ”Game state”. När spelet är slut, eller när ”Game state” är över, så kallas dens dekonstruktor. Därför så var det där som jag skulle ta bort alla objekt.

För att ha struktur i vårat projekt så har vi lagt in alla våra objekt i olika listor. Till exempel så är alla våra grönsaker i samma lista. Så i vår dekonstruktor kunde jag gå igenom den här listan, kolla vilka objekt som fortfarande var aktiva, sedan ta bort dem från ”heap” minnet. Detta gjorde jag för varje lista i spelet, men också för vissa andra objekt som skapats på andra sätt utanför listorna.

För att hitta vart alla minnesläckor skapades så använde jag mig av ett program som heter ”Visual Leak Detector”. Detta programmet kan vara ett av de svåraste program jag någonsin arbetat med. Det första problemet uppstod när jag skulle installera det. Jag installerade version 2.3 av programmet, då fick jag feedback som berättade att jag inte hade en enda minneslucka i spelet. Eftersom jag visste att jag hade minnesläckor i spelet så hörde jag med några andra som går samma kurs, och då fick jag reda på att han använde version 2.4rc2 av programmet. Efter flera problem med att installera programmet med rätt version så fick jag det äntligen att fungera. När programmet till slut var installerat så fungerade det väldigt bra, man kunde lätt se var i koden som minnesläckan skapades, och sedan var det bara att ta bort det som beskrivet tidigare i texten.

Mole Munch – Dev log 3

Denna veckan har jag fortsatt att jobba på vattnet. Mellan förra bloggposten och denna så har vi i gruppen fått ett fungerande vattenflöde, men vattenflödet skapades på spelarens position och hade ingen kollision. Det första jag gjorde var att skapa kollision mellan trädgårdsmästaren och hålen på ovansidan. På bilden till höger kan man se hur hålen på ovansidan ser ut, ett av hålen är tomt och ett är fyllt med vatten som trädgårdsmästaren har fyllt på. Detta är det slutgiltiga resultatet. För att komma till detta resultatet så skapade jag kollision mellan trädgårdsmästaren och ett tomt hål, då byttes bilden till ett vattenfullt hål. Jag fixade också så att om vattnet kolliderade med ett tomt hål på undersidan så byttes spriten på ovansidan till ett vattenfyllt hål. Detta ifall spelaren skulle ha två hål som var länkade via tunnlar på undersidan.

Spelaren har ingen kollision med hålen på ovansidan, dem är bara där för att demonstrera att det är vatten i tunnlarna i underjorden. Däremot ska vattnet i tunnlarna ha kollision med spelaren. Detta var ett av de stora problemen jag hade den här veckan. För att gå igenom hur kollisionen med vattnet fungerade så måste jag först gå igenom hur vattnet fungerar. I kort så skapas en pixel på trädgårdsmästarens position när trädgårdsmästaren och hålet kolliderar. Denna pixel skapar sedan flera pixlar runt sig själv, då får vi en effekt av att de blåa pixlarna flyter i tunnlarna. Om ni vill läsa mer om hur vattnet fungerar så kan ni läsa om det här https://bergjens.wordpress.com/2015/02/26/update-3-on-project-mole-munch/.

När man ska skapa kollision mellan spelaren och vattnet så uppstår ett problem. Eftersom att vattnet inte är ett objekt utan bara är pixlar så går det inte att kolla på vattnets kollisionsbox. Istället kan vi använda oss av en teknik då vi kollar färgen på en bild. Det första som behövdes göra för att kunna använda denna tekniken var att skapa en bild av vattnets sprite. Detta var lätt att göra genom SFML’s funktioner. När detta var gjort så kunde vi använda den bilden för att kolla positioner och RGB värden. För att veta vattnets position så kollade vi vart på bilden som RGB värdet var det samma som vattnet. Till exempel om vattnets RGB var 128, 128, 255, så kunde vi kollade var på bilden som en pixel har det exakta RGB värdet. Sedan kollade vi positionen på spelaren och jämförde med positionen på bilden av vattnet. Om det var exakt samma position så fick vi resultatet sant och då kallades kollision. Just nu händer inget när de kolliderar, men vi ska lägga till en animation som spelar upp när mullvaden dör.

Såhär ser vattnet ut när man gräver i tunnlarna.

Mole Munch – Dev log 2

Denna vecka har allt mitt fokus gått till att skapa ett vattenflöde. Detta har skapats för att fylla tunnlarna som mullvaden har grävt under marken. Varför detta vattenflöde är användbart är för att spelaren inte ska kunna vara inaktiv för länge, även fast hen är under marken. Därför finns detta vattenflöde för att skapa känslan av ett konstant hot.

Vattenflödet i detta stadiet är inte helt färdigt, vi programmerare hade ett möte med vår programmeringslärare där vi fick en idé om hur vi ska ta oss åt för att skapa det. Min idé före mötet var att skapa vattenobjekt lika stora som hålen och måla ut dessa ovanpå våra tunnlar, sedan lägga in dem i entitetslistan som vi skapade förra veckan, för att till exempel kolla kollision med spelaren. Sättet som vår lärare tipsade om var en teknik som kallades för ”Flood Fill”, denna tekniken gick ut på att måla ut först en pixel, sedan kolla pixlarna runt denna, och om dessa pixlar var lediga så målades ännu en pixel ut. Efter flera itereringar kommer vattnet att nå en vägg och därför sluta måla ut nya pixlar. Denna metod att skapa vatten fungerade i teorin, men i praktiken skapade det grova prestandaproblem. En anledning varför det skapade problem var för att vi laddade om bilden varje gång den fick en uppdatering på sig, alltså behövdes hela bilden laddas om ifall en till pixel lades till. 

I bilden bredvid ser ni hur vattnet såg ut när jag använde mig av ”Flood Fill” tekniken.  Vattnet i denna bilden illustreras som den blåa fyrkanten längst ner på bilden. Vattnet var tänkt att flyta igenom tunneln och jaga spelaren. Den primära anledningen varför vi ville använda oss av denna tekniken var för att det skapade en bild av att vattnet rann i tunneln. Med den andra tekniken att måla vattenobjekt ovanpå tunnlarna så får vi inte samma bild av att vattnet rinner efter spelaren.

Fördelen med att rita ut objekt ovanpå en existerande tunnel är att vi kan ge objektet en sprite och en animation. Det blir roligare att se på än tråkiga blåa pixlar. Även fast än animation ser mycket flashigare ut så kräver det mycket mindre prestanda än tekniken för att få vattnet att rinna. För att få en illustration av att det rinner vatten har vi diskuterat att använda oss av andra sätt för att få det att se ut som att det rinner, även fast det bara är stilla objekt.

Mole Munch – Dev log 1

Vi är en grupp på 6 personer som tillsammans utvecklar ”Mole munch”. ”Mole munch” är ett projekt i kursen Spelutveckling i samband med Spelprogrammering 2. Jag går i rolen av ”Lead Code” och lägger därför mycket av mitt fokus på att programmera. Vad jag har valt att fokusera på denna veckan är vad som kallas en entitetslista. Detta är en lista skapad för att samla alla objekt i spelet. Varför man vill samla alla objekt i en lista är för att det underlättar för flera olika områden. Om man till exempel vill uppdatera alla objekt i spelet så kan man kalla på listan som kollar om objekten är aktiva, är de det så uppdateras dem. Detta underlättar då man istället bara kallar på listan istället för att kalla på varje entitet var för sig.

I projektet från Spelprogrammering 1 så använde vi oss av en liknande lista, vad som skiljer denna åt är att listan innehåller en funktion för att kolla vilka objekt som är under eller över marken. Detta skapades för att spelet har en mekanik då spelaren kan gräva sig ner under marken. När spelaren är under marken så ska inte objekt som är ovanpå marken ritas ut och tvärtom. När denna funktionen inte fanns så skapades många problem så som att objekt på ovansidan kunde reagera med objekt som var på samma position fast under marken.

Nedan är en bild som visar olika entiteter. Varje jordgubbsplanta är individuella entiteter, men använder sig av samma klass, detta gör att de kan reagera olika och ha olika positioner, samtidigt som de använder sig av samma textur. Om jordgubbsplantorna inte skulle läggas in i en lista skulle det vara mycket svårare att hålla isär vilken planta som är vilken. Mullvaden längst ner på bilden är också en entitet med samma funktionalitet som de andra entiteterna. Fast än spelaren är med i listan så har den funktioner som inte kan kallas via listan utan måste kallas genom spelaren. Detta är för att spelaren har funktionalitet för att till exempel reagera till knapptryckningar. Funktioner som måste kallas genom spelaren är funktioner som inte behövs i andra entiteter. Alla entiteter i listan använder sig av de funktioner som listan håller i. 

Det här spelet skulle gå att programmera utan att skapa en entitetslista, men struktur tycker jag är väldigt viktigt i programmering. Strukturen blir ännu viktigare när man är fler än en programmerare, det är också bra övning för framtida projekt som säkerligen kommer vara större och mera avancerade.

Week 6 – Bomberman level

In this week of Game Programming 1 we started working on our map for our bomberman level. The original bomberman level is built up by three different types of blocks, solid blocks, background blocks and breakable blocks. So we decided to create a class for each one of these blocks. To more easily edit the level, we wanted to load in the level from a txt file. We had alot of problems with getting this to work, but by looking back at previous lectures, we could figure it out. The txt file is constructed of numbers, each specific number is used to decide which block should spawn. The position of each block is set in the constructor of our gamestate by a simple formula.

Week 5 – Arkanoid & Collision

This week we completed Arkanoid. The game is fully functional and the code is the code we are going to use for our own project. In the final version of Arkanoid, we implemented collision for the different objects in the game. The collision checks if an objects half width plus the other objects half width is bigger than one of the objects width. We also implented SpriteText, this is useful when you want to write out text on your screen.

We have also started slightly on our final project, Bomberman. Planned for next week is to work on a level/map and the player.

Week 4 of Game Programming 1 – Project preparation

In this week of Game Programming 1, we have been doing a lot of live coding. The code we have been writing is a blueprint for the upcomming project. The project is to create a game in the Simple DirectMedia Library. The game I and my partner (unoakerlund.wordpress.com) have decided to create is Bomberman, so a lot of time this week has gone to study the mechanics and objects that Bomberman contains.

The coding we have been doing is a blueprint that we can use to create our game. The code contains several classes. Some of the classes is advanced and takes a lot of analyzing to fully understand. The class that brought the most attention from me was the StateManager class. This class handles which state the game is in, for example,  if the game goes from menu state to game state, it is StateManager that handles these actions.

Week 3 of Game Programming 1 – Classes

In this week of game programming, we have worked with classes. A class holds values, the amount and type of values is decided by the programmer. To learn how classes work, we had a bunch of different assignments. The assignment I chose to focus on was to make a deck of cards. I chose to focus on this because it demonstrate really well how classes work together. I made a class called Card, this class held the types Integer and String. The class made cards containing those types which was sent to the class Deck, which put the cards in an Array. From the array, the program could shuffle and pick out cards, every card in the array was unique. What was not programmed was the process to remove cards from the deck.

Shown below is a snapshot from the class Card: In this class all the cards is created, the cards is then put in the deck via a for loop in the Deck class.

Card::Card(int num)
{
if (num < 13)
{
int a = 0;
a++;
int m_num = a;
m_suit = "Hearts";
}
if (12 < num < 27)
{
int a = 0;
a++;
int m_num = a;
m_suit = "Spades";
}
if (26 < num < 40)
{
int a = 0;
a++;
int m_num = a;
m_suit = "Clubs";
}
if (39 < num <= 52)
{
int a = 0;
a++;
int m_num = a;
m_suit = "Diamonds";
}
}