Delete all!

I detta blogginlägg tänkte jag skriva om hur spelet ligger till en veckan innan GGC och vilka förändringar som vi har gjort i designen. Vi har ändrat på craftingensystemet, grundtanken var att spelaren skulle kunna byta mellan olika ”recept” för att bygga olika proteser och dessa olika proteser behövdes sätt på rätt skada kroppsdel för att fungera. Eftersom det är så lite tid kvar och vi har fortfarande ingen vinstskärm eller tutorial nivå till GGC väljer vi att satsa på att få ihop det isället för att göra en mer intressant craftingsystem. Vi valde även att ta bort tången som skulle fungera tillsammans med ungen, spelaren skulle först behöva värma upp ungen för att sedan lägga in protesen för att sedan låt protesen bli varm och för att ta ut protesen behövde spelarna samarbete med varandra för att ta ut protesen med hjälp av tången. I samband att tången tas bort försvinner även syftet med ugnen så den tas bort också, nu är typ halv spelet bort, nejdå!

 

Men det finns absolut luckor i design nu som verkligen behövs fyllas för få en bra core loop och ge spelaren en intressant och utmanande upplevelse. Vi har även valt ett nytt sätt att kalla på orcen där spelaren slår på en trumma så flyger orcen in på banan, orcen har tre olika landningsplatser. Om spelarna inte tar emot orcen med båren kommer orcen att sprängas. Vi kände att detta var ett enkelt sätt att göra upphämtningen av orcen mer intressant och utmanande. Men det finns dock inget riktigt straff för spelaren om spelaren misslyckas fånga orcen förutom att den dör då, men då är det bara att slå på trumman igen och en ny orcs kommer inflygandes. Andra saker som kommer behövas fixas till GGC button pop up när spelaren när nära vissa objekt ska det poppa upp den knappen som går att använda. Under de flesta speltestningar har spelarna haft problem med att interagera med vissa objekt för de vet inte riktigt vilka knappar man kan använda för att interagera med just den saken, jag tror att med knapp pop upp kommer man undvika detta problem.

 

Win Screen

I spelet skulle vi använda oss av en vinstskärm, när spelaren vinner så ska spelet bytas till en vy där spelarna ser ett antal orcer som sjunger i kör, beroende på hur många orcer spelarna rädda kommer spelarna få olika antal vinstslut.  När denna scen var slut skulle spelaren ges alternativen att fortsätta till nästa level eller gå tillbaka till huvudmenyn. Tanken från början var att när man räddade orcen skulle orcen ställa sig upp och gå in i en hytt där avslutnings scenen skulle ske. Vi valde i slutändan att istället att skippa gång delen och istället gå direkt till slutdelen där orcen sjunger i kören. Gångdelen skulle kräva att vi skapade en gånganimation och en väldigt simple ai för att få orcen på rätt plats. Vid denna tidpunkt var det redan mycket mekaniker i spelet som redan var oslipade och buggiga. Vi kände att polera och balansera dessa mekaniker skulle ge mer till spelaren än att orcerna skulle gå till sin vinstposition.

För att skapa vinstscenen behövde jag animationer och ljud för kören, detta hade vi två olika personer som fixade det, en som gjorde animationerna och en som gjorde ljudet. Jag behövde sedan vet hur många orcer som blivit räddade och den informationen fick jag via ett skript som kolla om orcen var läkt och var inom ett visst område, skriptet skulle då öka en viss variabel. Sedan behövde jag flytta kamera till slutscenen positionen och detta gjorde jag via transform lerp och för att sätta rätt rotation för kameran använde jag mig quaternion slerp.

Unity slerp

Spherically interpolates between a and b by t. The parameter t is clamped to the range [0, 1]. ”           (Unity Technologies. (2017). Quaternion.Slerp. Tillgänglig: https://docs.unity3d.com/ScriptReference/Quaternion.Slerp.html).

 

Unity lerp

Linearly interpolates between two vectors. Interpolates between the vectors a and b by the interpolant t. The parameter t is clamped to the range [0, 1]. This is most commonly used to find a point some fraction of the way along a line between two endpoints (e.g. to move an object gradually between those points).

(Unity Technologies. (2017). Quaternion.Lerp. Tillgänglig: https://docs.unity3d.com/ScriptReference/Vector3.Lerp.html).

 

Jag använder mig av slerp och lerp för att få en sådan mjuk övergång som möjligt mellan kamerans nuvarande position och rotation till den position och rotation som den ska till. Efter det är det mest bara att se till att sätta igång animationen i rätt tillfälle samtidigt med ljudet. Sedan var det bara att hänvisa spelarna med de olika knappar för att antigen gå vidare till huvudmenyn eller till nästa level.

Crafting

Efter att spelarna ha huggit av orcens skadade lem behöver spelaren bygga en protes, efter det kommer spelarna behöva sätta på en protes på orcens avhuggna kroppsdel. Innan spelarna kan sätta en protes kommer spelarna behöva skapa protes genom olika material som finns runt omkring spelarna.För denna process behövde vi skapa ett craftingsystem för spelarna. Till en början tänkte vi ha olika kombinationerna av olika material som lågt runt omkring sjuklägret, vilket skulle ge olika typer av proteser som t.ex. armprotes, benproteser och att olika mänger av en typ av material skulle göra protesen längre eller kortare. Men vi valde senare att hålla oss till endast en kombination av material och det behövdes endast en av varje materialtyp för att bygga protesen. Varför vi valde att hålla oss till en kombination var att vi kände att det redan var svårt att kommunicerat alla mekaniker som vi redan hade till spelaren. Att vi skulle då klämma in ännu en mekanik till spelaren och designa denna mekanik så att den skulle vara rolig för spelaren men även att implementera denna mekanik på den lilla tid vi hade kvar kände att det skulle bara sluta i katastrof. Att istället bygga upp och finslipa de andra mekanikerna vi redan hade kände som ett bättre val.

Hur jag börja bygga craftingsystem var använda mig av olika tag på de olika materialen, de olika materialen hade tagsen dirt, water, metal och grass.

Unity Tag

“A Tag is a reference word which you can assign to one or more GameObjects. For example, you might define “Player” Tags for player-controlled characters and an “Enemy” Tag for non-player-controlled characters. You might define items the player can collect in a Scene with a “Collectable” Tag.”  ( Unity Technologies. (2017). Tags. Tillgänglig: https://docs.unity3d.com/Manual/Tags.html(2017-06-01).

 

Senare under projektet bytte jag ut dessa tag namn till mer relevanta namn på de olika objekt vi använde. Sedan använder jag mig utav unitys trigger kollision för att kolla om objekten har lagt in i ett område där det går att bygga med objekten. Om ett objekt kommer in innan för detta område ökar jag värdet för en variabel som representera mängden av just de materialet. När alla de olika martialen är lika med ett eller större än ett så ska spelaren ha möjligheten att bygga en protes. När spelaren bygger sedan en protes så initialisera jag ett nytt spelobjekt med ett nytt tag som representerar protesen och detta spelobjekt innehåller även mesh och de olika script som protesen kommer behöva.

Ugn

I spelet ska spelaren använda sig utav en ugn, denna ugn ska användas för att kunna värma upp en protes som läggs in i ugnen. För att kunna värma upp protes måste spelaren först värma upp ugnen och det gör spelaren genom att slänga in trä in i ugnen som sedan bränns upp automatiskt för att ge värme till ugnen. Tanken bakom varför spelaren ska behöva värma upp protesen är att protesens metalliska del ska bli så varm att den ska kunna brännas fast på den skadade orcen.

För att först få det att funka mellan veden och ugnen använde jag mig utav en trigger collider på ugnen och en vanlig box colliders för veden. Så fort vedens colliders kom i kontakt med ugnen colliders lades det till ved i ugnsscriptet. I ugnsscriptet använder jag mig utav en funktion som är beroende av hur mycket ved som finns inuti ugnen, i scriptet ökar veden elds tidsvariabel och denna variabel minskas under varje frame.  Så länge elds tidsvariabeln är över ett ska även en annat variabel som representerar värmen öka under varje frame så länge eld tidsvariabeln är över ett. När värmen är över värdet ett ska det även spelas upp en eldpartikeleffekt som ska gå om på loop så länge värdet är över ett.

För att sedan kunna lägga in en protes in i ugnen gjorde jag på samma sätt som jag gjorde med veden, jag använde mig utav trigger collider och vanliga box collider för att upptäcka kollisionerna mellan de två objekten. Spelarna behöver bara slänga in protes i ungen och se till att det finns ved tillgänglig till ugnen för att alltid hålla ugnen varm för så fort elds tidsvariabeln har nått värdet noll kommer värmen att sjunka och där med kan inte ugnen bidra till att värma protesen.

Vi skapade en blåsbälgsfunktion till ugnen, under spelet kommer det finns en stor blåsbälg bredvid ugnen som spelarna kan slå på för att få upp värmen snabbare. Blåsbälgen är väldigt simpel, det finns en triggerzon runt om ugnen, om spelaren skulle vara inom denna zon och slå på blåsbälgen ska en bool i ugnsscriptet sättas till sant och ge värme variabeln en kort boost, detta gör även eldpartikeleffekten större och mer intensiv under den tiden.

 

Kamera

Spelet kommer använda sig av en isometrisk kamera vy. Eftersom spelet är ett lokalt multiplayer spelet kände vi att det var passade att använda en isometrisk kamera vy som påminner om Magicka och Diablo men med en mer inåt zoomad vy. Detta fungera bra till att både visa spelarna och miljön i spelet. Det var diskussioner angående om vi skulle ha en kamera i stil med lego harry potter, där de använder sig också av en isometrisk kamera med en blandning av en split screen. När de båda spelarena är för långt ifrån varandra delas kameran upp till två, istället för att behöva zooma ut kameran för att se båda spelarna. Men problem med det kamera system var att det var svårare att koda fram och man förlora även lite charmen med att kunna se hela miljön av spelet.

Vi bestämde oss för att ha en dynamisks isometrisk kamera. Då var det mitt jobb som programmerare att fixa fram det. Hur jag gick till väga var först att ta reda på hur unitys kamera fungera, vilka olika slags funktioner som behövde användas. När vi säger att kameran ska vara dynamisk ville vi att kamera skulle följa efter de båda spelarna och även kunna zooma in eller ut beroende på vilken distans de har till varandra.

Hur jag gick till väga för att få kamera att följa de båda spelarna så bra som möjligt var att sätta kamera så att den alltid var i mitten av de båda spelarna. Jag använde mig av en uträkning där jag tog båda spelarnas position och addera de tillsammans för att sedan dividera summan av de två positionerna för att få ut mittenpositionen. För att sedan få kameran att zooma in och ut beroende på hur långt ifrån spelarna är ifrån varandra, använde jag mig av en uträkning som subtrahera en av spelarpositionerna med den andra spelarpositionen för att få ut skillnaden.  Skillnaden skulle sedan avgöra hur stor ut zoomingen är.

Goblin Dr.

Då har det kommit fram till BGP och jag tänkte presentera lite om det koncept som jag har hängivit mig till, det koncept heter Goblin Dr. Goblin Dr. är ett fantasy, lokal co-op spel med isometrisk vy som spelas med två spelare, spelets design har ett fokus på kommunikationen mellan spelarna.  Spelarna styr var sin goblin som har i uppgift att läka så många skadade orcser som möjligt.  Spelet utspelar sig under ett krig mellan människor och orcser en bit ifrån slagfältet kommer det existera ett sjukhustält där dessa två goblins kommer att finnas på plats.

Spelet kommer att börja med att ett antal skadade orcser kommer tillhandges en bit utanför sjuktältet. Spelaren kommer då behöva dra orcsen till en bår som spelaren måste sedan manövrera till en plats inne i tältet där doktorsprocessen ska ske.

Bår kommer att ha ett styrsätt att på ena sidan av båren ska spelaren bara kunna föra båren framåt och bakåt medans på den andra sidan kan bara den andra spelaren kunna föra båren höger och vänster, vilket gör det lättare med bra kommunikation att snabbt föra båren med den skadade orcsen till arbetsplatsen.

Orcsen kommer att ha lite olika slags skador på kroppen och kommer att bara kunna lösas på ett enkelt sätt, amputering. Spelarna kommer då behöva för dit amputeringsverktyget som kommer att manövreras på ungefärligt samma sätt som bår för att förflytta verktyget sedan kommer en ny mekanik in där det gäller för spelaren att sikta in ordentligt för att sedan låta sin kamrat avfyra hugget i rätt tid för att få en lyckad amputering.

Spelarena kommer sedan behöva bygga en protes till orcsen som ersättning för den avhuggna kroppsdelen. För att kunna bygga ihop en protes behöver spelaren samla ihop olika material för att sen snickra ihop det till en protes vid snickarbordet. Olika materialkombinationer ger olika slags proteser.

Efter detta kommer spelaren behöva lägga in protesen i en ung för att värma upp protes för att den ska lätt kunna limmas fast på orcsen. För att spelaren ska kunna ta ut den varma protes ur ungen behöver spelaren använda sig av en tång som det behövs minst två goblins för att manövrera. Tångens funktion kommer bero på spelarnas distans ifrån varandra när tången hålls. Om spelarna är för långt ifrån varandra så kommer protes att glida ur tångens grepp. För att greppa tag om protesen kommer spelarna att alltid behöva ha en viss distans ifrån varandra under hela färden från ungen till orcsen.

När detta är klart så ska orscen bara färdas till en dropoff punkt av goblinsarna därefter kommer han färdas till slagfältet. Orcsen kommer ha en livmätare undera hela denna processas vilket gör att denna process kommer behöva gå snabbt så att inte orscen förblöder och dör. För att vinna kommer spelarena behöva läka ett visst antal orcser om inte spelarena lyckas med det så förlorar de spelet och orcerna förlorar slaget mot människorna

Healthbar och Damage animation

Hejsan! Sista blogginlägget idag, skönt att bli av med det här om jag ska vara helt ärlig. Så de artefakterna jag tänkte skriva om idag är hur jag gjorde skadeanimationen och ”Healthbar animationen”. Så vad exakt har jag gjort? När man tar skada så vill man gärna veta att man tar skada, man vill alltså ha feedback på det, så att man inte går helt ostört och helt plötsligt är man död och inte vet varför. Därför har skapade vi en ”damge animation” när spelaren tar skada, skulle inte riktigt kalla det en animation för det jag gör är egentligen bara ritar ut en enstaka bild lite snabbt. Samma anledning är varför vi skapade en ”healthbar” för spelaren, för spelaren ska ha koll på hur mycket liv spelaren ha kvar i spelet.

Innan i spelet hade vi ett värdet för spelaren som kallades ”marketvalue” som skulle representera spelaren liv. Detta bytte vi nu till att ha en mer visuell representation för spelarensliv för att göra det klara för spelaren. Just nu så visas ”healthbaren” som en jordglob som töms en 1/10 varje gång spelaren tar skada från fienderna, innan så var det bara en text och siffror som det stod ”marketvaule” på som började på 1000 och sedan gick ner med 100 varje gång spelaren tog skada. Detta fick vi väldigt mycket kritik på så vi bytte till att använda oss utav ett mer visuell representation för ”healthbaren” för spelaren.

Hur har jag gjort det? Eftersom min kunskap inom programmering är väldigt låg så gjorde jag det väldigt lätt för mig. Jag hade 10 olika bilder med en jordglob som var olika mycket fyllda. Så i koden använder jag mig utav ”if sats” som säger om”marketvalue” är lägre eller lika med 900 så ska”healthbar” bilden bytas ut med den bilden med jordgloben som är 9/10 fylld. Sen gör jag bara om denna ”if sats” flera gånger om men byter bilden och regeln i ”if satserna” , om ”marketvalue” ska är mindre eller lika med 800 så byts bilden till en jordglob som är 8/10 fylld osv.

en ”if sats” även kallad villkorssats handlar i huvudsakligen om ett ”om” t.ex. om 7-3 är lika med 4 så ska en viss bild ritas ut.

Med ”damages” bilden använde jag mig också utav ”if satser” men även också en inbyggd klockfunktion i sfml. Så om en fiende kraschar ner på planet så ska en ”damages” bild ritas ut under en viss tid på skärmen i detta fall en halv sekund så kommer bakgrundsbilden bli transparent rött på kanterna.

Varför jag gjorde som jag har gjort har jag ingen riktigt bra anledning, jag testa mig först på”if satser” sen så fungerade det ganska bra redan då så jag kände inte direkt någon anledning av att försöka mig på något annats sätt och jag visste inte heller något annats sätt att göra det på.

.

Rapid Fire Power up – week 5

Hejsan! I denna veckas blogginlägg ska ska skriva om hur jag gick till väg för att skapa ”power upen rapid fire” och varför jag har gjort som jag gjorde. Så en av mina uppgifterna till denna vecka vara att fixa ”rapid fire power up”. Så först behöver vi veta vad vår ”rapid fire power up” ska göra? Vi i gruppen bestämde oss för att när man fick ”power upen” så ska spelaren kunna skjuta mer projektiler under en kortare tid. Så vad behöver jag alltså koda.,först och främst så ska spelaren kunna skjuta ut en projektil och denna kod finns redan för att spelaren ska kunna skjuta projektiler vanligt. Men i denna kod använder vi oss av en typ av ”cooldown” med hjälpa en klockkod, innan man kan skjuta igen. Så om man tänker logisk så borde det bara vara att ta bort denna ”cooldown” för att kunna skjuta igen för att få en effekt av att spelaren kan skjuta mer under en kortare tid.Och det var det jag gjort, jag tog bort koden för ”cooldownen” mellan projektilerna som var satt på en halv sekund.

Nu fungerar själva ”rapid fire power upen”, spelaren kan skjuta flera projektiler under kortare tid. Så nu återstår det bara att fixa så att denna ”power up” har en livslängd och inte varar över hela spelet så fort man har fått den. Hur ska jag göra det här? Jag tänkte först att jag skulle använda mig utav kodbiblioteket sfml inbyggda klocka men detta gav mig lite problem. Jag var inte så inläst på sfml klockan och visste inte riktigt när klockan startade tills jag skrev ut det i konsolen, det visande sig att klockan startade så fort man skapade klockkoden. Så jag försökte skapa klockkoden i en kodloop för ”rapid fire” koden men det visa sig att när jag la in klockkoden i ”rapid fire” loopen så vill inte klockan öka, den stannar alltså på samma tid i hela loopen och om jag ska vara helt ärligt så vet jag inte varför det gör så. Så jag testa mig utav ett annat alternativ där jag använder mig utav ”iterator”.

”An iterator is any object that, pointing to some element in a range of elements (such as an array or a container), has the ability to iterate through the elements of that range using a set of operators (with at least the increment (++) and dereference (*) operators)” (http://www.cplusplus.com/reference/iterator/ (Hämtad 20016-03-10).

Så vad jag gjorde var att jag gjorde en iterator som plussas på varje gång som loppen körs igenom. Så då sätter jag en regel för koden om att denna iterator är högre än ett visst värde t.ex. 200 så ska ”rapid fire” ta slut och detta funkar ändå ganska okej. Så tips för någon som har fastnat i en kod är att försöka skriva ut så mycket som möjligt i konsolen så kan det bli lättare att få reda på om något skrivs ut rätt eller fel och se vart felet är. I andra bilden under ser du hur spelet ser ut utan ”rapid fire ”  och i första bilden ser du hur spelet fungerar med ”rapid fire”.

 

individuell -code review grupp 3

Vad spelaren kan gör i spelet är att rör sig upp, ner, höger och vänster. Spelaren ska även kunna skjuta en projektil,använda sig utav power up i olika form, i detta spel är det bumerang, sköld, basebollar. Spelaren ska kunna ta skada och även ritas ut i spelet. Ungefär detta är allt som jag har uppfatta som spelaren behöver kunna göra i spelet. Då behöver alltså spelar klassen, Playercharacter i detta fall först komma åt input i spelet för att vet vad och när spelare ska göra vad t.ex. gå höger eller vänster. För att spelet ska kunna få ut en bild utav spelarkaraktären så kommer spelar klassen behöva information från en sprite klass eller något liknade, i detta projekten så är det en animations klass som hanterar alla bilder och animationer, så spelar klassen kommer binda sig med animationsklassen

. Om nu spelaren ska kunna använda sig utav power up så kommer hen behöva information av alla olika power ups klasser. Men denna grupp har varit smarta, om jag har uppfattat det rätt , just nu så binder spelaren klassen med en Ientity klass som ska fungera som en power up klass hanterare. Istället för att binda alla olika power up så binder de nu bara Ientity klassen. För att spelar klassen ska kunna skjuta ut projektiler från rätt plats så kommer den behöva ge ut information till projektils klassen om vilken plats spelaren befinner sig på. För att spelaren ska kunna ta skada och utge skada i form av projektiler så kommer den behöver binda sig med en kollisions klass, här berättar även spelar klassen hur mycket skada spelaren ger till fienderna och när spelar klassen tar skada. Detta är ungefär vad jag kan tänka på vad en spelar klass skulle kunna behöva för att fungera i detta spel. Min programmeringsnivå är inte så hög så jag kan inte riktigt se vad de kan har gjort annorlunda för att minska bindningsförhållandet mellan det olika klasserna. Enligt mig tycker jag att det ser riktigt bra ut.

Meny – vecka 4

Hejsan! I dagen blogginlägg ska jag skriva om hur vi gjorde våran meny i spelet. Den uppgiften jag hade var att skapa en meny med tre olika knappar som ska innehålla olika stadier. De ska även vara möjligt att vandra mellan dessa olika stadier från menyn . De ska vara fem olika stadier som spelet ska kunna gå emellan. Det första stadiet som man kommer in till när man startar spelet är meny stadiet. Vad som finns här är de andra stadier som man ska kunna gå till. Ett ”play” stadium som ska starta det riktigt ”spelet”. Ett ”option” stadium som var tanke att man skulle kunna ändra olika saker i t.ex. ljud och skärmupplösning men tiden var knappt så för tillfället så innehåller det stadiet bara ”highscore” som ska då visa de tio bästa poängen som har uppnått i spelet. Sista stadiet i spelet är en ”quit” stadium som stänger ner spelet. När jag skapade menyn så tog jag en stor hjälp från vår andra programmerare i gruppen, Mathias.

Det först vi gjorde i projekten var att ladda in bakgrundsbilden som menyn skulle ha, i det här fallet var den en ”pixel art” bild med jorden och spelets namn. Sedan behövde vi ladda in alla andra bilder för knapparna. Alltså så behövde bilder för ”high score”, ”options”, ”play”, ”back” och ”quit”. Efter det så behövde vi fixa ett sätt så att spelet kan interageras med dessa bilder. Hur vi fixa det var genom att ge dessa olika bilder rektanglar som inte ritas ut, men att fortfarande spelet kan interagerar med. Rektanglarna är i huvudsakligen för att kolla om mus pekarna är inom rektanglarna area. Alltså så kommer dessa rektanglar ligga bakom de olika bildknapparna. För att se om muspekaren är inom någon av rektanglarnas area så behöver spelet vet om muspekarens position och det gör jag genom koden under.

sf::Vector2f mousePos = window.mapPixelToCoords(sf::Mouse::getPosition(window));

sedan så har jag en ”if sats” i spelet som säger om muspekare är inom t.ex. ”play knappen” och spelaren trycker på vänster musknapp så går spelet till ett ”play” stadium där spelet start i. Detta funkar på samma sätt på de andra knappar fast du kommer som sagt till olika stadier beroende på vilken rektangel din muspekare är inom. Kortfattat om ”if satser” , en ”if sats” är en villkorssats och som du säkert vet så betyder ”if” om på engelska och det är just detta om som ”if satsen” går ut på t.ex. om(det har gått över tre sekunder) {rita ut denna bild}.

Varför vi gjorde som vi har gjort har jag inget riktigt bra svar för, eftersom detta var det enda sättet som vi visste om för tillfället för att skapa en meny. Vi skulle dock kunna använda oss av piltangenterna för att välja mellan de olika knapparna men eftersom spelet i huvudsakligen styr med hjälp av musen så kände vi att musen var ett passande alternativ att välja mellan de olika knapparna.