Kategoriarkiv: Process

The War against the Game

Nu har jag ju kommit på att jag varit ganska dålig med att skriva inlägg i Workbooken, Jimmy har skött den biten bättre än mig så nu är det hög tid att jag gör det med, och jag kör hårt med en ordentlig sammanfattning av projektet och våra framgångar/motgångar hittills.

Vad är det som har hänt med produktionen då? I början av produktionstiden satt jag mycket och försökte strukturera upp en logisk leveldesign för vårt projekt. Vi har båda redan innan bestämt oss för att göra ett demoleringsspel till mobiler, lite likt Angry Birds, fast i 3D och en del skillnader i mekaniken. Vi kan säga att vi tar grundkonceptet (vilket betyder mer eller mindre att ”förstöra en konstruktion”), men gör om resten. Hur kan man då göra det här lite originellt?
Först och främst så bytte vi ut katapulten mot en rivningskula, som man med en pendelrörelse ska banka på byggnaden istället. Sen valde vi i grund och botten att ha lite taktisk känsla i spelet. Ett exempel på det här är att spelet är satt i ett okänt metropolis, där byggnadsblocken är av olika vikt. Detta ger att man måste slå till de tunga blocken (som tegel eller metall) lite hårdare för att de ska rubbas, men ifall man slår lika hårt på ett lättare block (som glas eller trä) så flyger de längre. Låter inte så speciellt nu kanske, men eftersom byggnaden som ska rivas står mitt inne i stan så får inte närliggande byggnader skadas. På så vis så får spelaren tänka lite taktiskt, han kanske inte ska drämma till med full styrka på vilket block som helst.

Det här leder ju till oändliga möjligheter i form av leveldesign, wohooo! Eller gör det? Nej, det är en enda liten liten liten detalj som spelar all roll – mobilens kapacitet. Vi bestämde oss tidigt för att sikta på iPhone 4 och nyare mobiler, just för att fyran är fortfarande väldigt vanlig på marknaden och ifall vi gör ett spel som fyran klarar av att hantera, så klarar definitivt 4S och 5 det också. Finns även en del Androidtelefoner som är kända som starkare än iPhone 4. Men vad klarar mobilen av då? Ja, vi visste redan innan att mobilerna var ganska klena, men som Jimmy tidigare nämnt så trodde vi inte att de var SÅ klena. Det var inte mycket kapacitet vi har att spela på här, men det är inte mig emot faktiskt. Jag ser det som en större utmaningsfaktor.. ganska mycket större faktiskt. Innan vi testade riktigt så hade vi den låga kapaciteten i åtanke, så ingen av våra modeller var speciellt högupplöst i form av polygoner (geometriska former, oftast kvadrater och trianglar, som är sammanbundna till en 3D-modell med hjälp av deras kanter, edges) och texturer (bilder av olika slag som ger färg, djup och egenskaper till 3D-modellen). Dock märkte vi i början att det var inte många block som kunde vara med innan mobilen började protestera och då gick vi över på undersökningen. De mest noterbara ”soft limits” som en iPhone 4 har när det gäller spel är antal vertixes (hörn på polygonerna, en triangel har 3 vertixes, en i varje hörn exempelvis) och så kallade ”Draw Calls”, vilket är sammanfattningsvis hur många gånger per frame (bilduppdatering) som spelmotorn säger åt grafikprocessorn och den vanliga processorn att göra något när det gäller att rita ut objekt på skärmen. Vi hade inte räknat med Draw Calls tidigare, ingen av oss visste faktiskt vad det var innan projektet, så vi blev ganska förvånade när mobilen klagade trots att antal vertixes i spelet låg en bra bit under rekommenderat maximum. Vi forskade lite mer om möjliga problem och fick då reda på att Draw Calls är en annan viktig faktor i prestandan och det förklarade ju allting. Mobilens ”soft limit”, alltså rekommenderat maximum till skillnad från ”hard limit” som är absoluta maximumet, för Draw Calls ligger runt 90-110, beroende på hur många vertixes som också finns där, och vi låg i just nu på runt 150 Draw Calls… AJ!

Det här ledde ju till att vi fick gnugga de gamla grå cellerna rätt ordentlgt, för att även det bästa spelet med det roligaste gameplayet och snyggaste grafiken är ju ett totalt fiasko om det inte går att spela och det kan ju Jimmys smältande mobil intyga. Vi hittade tillslut ett paket för Unity som ska hantera just den här typen av problem, oavsett om det är till spel för datorn eller för mobilen. Vad det gjorde var att det binder ihop alla 3D modeller till en enda modell och alla texturer sätts ihop till en enda stor bild, vilket egentligen drar ner antalet Draw Calls till mycket få, då man i enkelhet kan säga att varje 3D modell är ett Draw Call och varje material till modellerna är ett. Problemet är dock att det här systemet kan bara användas på modeller som inte ska röra sig, vilket blocken som vår byggnad är uppbyggd av gör. Med lite smart tänkande och modifikationer så lyckades vi dock med hjälp av skriptet få ner våra Draw Calls till runt 70, vilket är en mer hanterbar nivå i nuläget. Då uppkom dock ett nytt problem och det är att hela den här baletten kretsade kring att få leveln fungerande – Jimmys karaktärer ska ju också in, och de ska röra på sig. Tillbaka till tänkarbänken.

Men efter mycket om och men så har vi i nuläget konstruerat vår första level och vertixes och Draw Calls är på en mycket acceptabel nivå utan att för mycket har offrats för att uppnå det här. Vad som kommer ske härnäst är att ta vårt fungerande kontrollsystem och binda samma det med vår kran, så att den kan röra sig på det sättet vi vill. Sen ska vi ha in Jimmys karaktärer och därefter är det egentligen bara att bygga banor, när vi fått det att fungera som det ska.

Vad är det då för något som jag gjort när det gäller leveldesignen? Vi började med att fundera vad för material vi ska ha på byggnadsblocken och vilka former. Innan vi insåg hur lite telefonen egentligen klarar av så tänkte vi bygga upp hela chabraket utav totalt fem olika byggblock i fem olika material (tegel, trä, metall, marmor och glas).

Alla fem L-Shapes

Alla fem L-Shapes

Vilket då ledde till att det var just vad jag började förbereda. Enkla byggklossar som skulle ha sin respektive textur. Normalt brukar vi använda tre olika bilder för ett material, färg, normalmap (djup) och specular map (ljusåterkastning) för 3D-modeller, men de två sistnämnda, i synnerhet den sista, är ganska prestandakrävande så vi körde bara färgtexturer för spelets modeller.

När dessa modellerna var klara så började jag gå an med själva leveln efteråt. Vi hade som tidigare nämnt bestämt oss för att sikta på en stadskärna, just för lite bättre rama in leveln, men vi har haft tankar som ett skogsparti i utkanten av en stad också. Det blir dock en potentiell senare episod. Jag började först med att bygga upp huset bit för bit som en exempelbyggnad medan Jimmy gick mer ingående in på hur vi skulle få över projektet till mobilen efteråt. Först när jag hunnit färdigt med första våningen

First draft

First draft

så testade vi om det fungerade. Visst gick exporten till mobilen bra och vi fick in spelet i Jimmys mobil. Dock var det ungefär här vi började inse att något var galet när spelets FPS (står för ”Frames-Per-Second, antal bilder som motorn kan generera per sekund) indikerade överbelastning som en stor fet röd alarmlampa, vilket då ledde till att vi började forska mer runt vad problemet kan vara. Det var nu vi lärde oss om Draw Calls och dess påverkan och hur vi var alarmerande högt med dem redan efter första våningen. Don’t get me started on hur många Draw Calls det hade blivit om vi byggt de planerade tre-fyra våningarna i samma stil.

Det dröjde inte länge innan vi upptäckte att om man bygger hela leveln i Maya (3D-modelleringsprogram) och exporterar den till Unity istället för att exportera småbitarna och därefter bygga ihop dem i motorn som vi gjort nu, så sparar man en del prestanda, då det blir en modell istället för kanske tio, och alltså logiskt nog eliminerar 90% av Draw Calls för just modellerna (vilket inte är så jättemycket för vi har inte så jättemånga olika modeller, men det är ett steg i rätt riktning).

Leveln i Maya

Leveln i Maya

Hursomhelst var det precis så jag gjorde och det blev också lättare att arbeta med. Näst upp var att kolla över exakt vilka byggnader som kom att synas i bild och vilka som alltid är utanför bilden (och alltså någonting som tar prestanda till ingen nytta).

Därefter, när jag var nöjd igen, så slängde jag över leveln i Unity och ställde in den så att den fick rätt skala jämfört med de saker som redan var inlagda. Vi insåg också att vi inte skulle kunna ha våra fem olika former, då det krävde för mycket att utnyttja allihopa. Inget förnedrande för de tog inte många minuter att göra själva formerna och texturerna återanvände jag till de nya blocken, som var en kub och en dubbelkub (två kuber ihopsatta intill varann). Byggde upp en mycket simplare konstruktion och nu stannade vi runt 70 Draw Calls när vi ”optimerat” vad vi kunnat via skripten och strax över hälften av de max rekommenderade vertixes.

UnityLvl1UnityLvl1-2UnityLvl1-3

 

 

 

 

Det är nu det roliga börjar, när jag kan börja programmera in blockens egenskaper (dvs ge exempelvis de tunga metall- och tegelblocken sin vikt och alla blocken får sin ”hälsa”, eller ja, ett siffervärde över hur mycket stryk blocket kan ta innan det går sönder) och fysiken, så att blocken kan kollidera med varann och att de tar skada baserat på det här. Också sambandet med blocken och närliggande byggnader ska ju tas med i beräkningarna, för man ska få minuspoäng ifall man skickar ett block flygande som en vinglös fågel rätt in i grannkvarteret….

Fire in the Hole!

Fire in the Hole! Ett typiskt exempel på vad man INTE ska göra i det färdiga spelet…

Och det är ungefär här vi är i nuläget. Som jag tidigare nämnde så är nästkommande detaljer att få in Jimmys karaktärer i spelet, som fotgängare bland annat, och sedan få vår rivningskran att röra sig som vi vill. Annars fungerar det mesta ur programmeringssynpunkt, utav det vi har. Det senaste jag gjorde till spelet var en sak som jag lärde mig från Sjoerd De Jong faktiskt, vars bok kring leveldesign jag läste. Han tipsade om att ifall man har flera banor i samma område/stad etc, så är ett tydligt landmärke väldigt användbart, för det ger spelaren möjlighet att lättare orientera sig i universumet, om de har ett landmärke att gå efter. Jag byggde en stor dome-kupol som är tänkt att ses i bakgrunden på varje bana, från olika håll. Jag funderade en hel del på vilket landmärke det skulle vara, där de jag funderade mest på kretsade från ett högt torn, till något i stil med Eiffeltornet, men torn kan vara svåra att skilja från varandra om det inte sticker ut ordentligt och det brukar ofta se konstigt ut då också. Sen var ingen av oss för att ha ett icke-fiktivt landmärke så jag byggde en stor dome-kupol istället. Den sticker ut lite, men ser inte helt ologisk ut.

Karaktärsdesign till mobilen

En sak som gör karaktärsdesign betydligt svårare på mobil är hur få polygoner man kan använda sig av. I och med att man har en begränsning på hur mycket mobilen klarar av så måste man tänka väldigt noga hur man ska modellerar karaktärerna. Just nu sikar jag på att använda som man 260 polygoner. Det är väldigt lite om man jämför med dagen spel till datorn som kan ligga över 30.000 polygoner.

Detta gör att det är väldigt viktigt med lättigenkännbara former. Även om det inte ser runt ut så ska ändå förstå att det ska vara runt. Likaså med alla andra former.

kyckling

 

Bilden ovan så använder jag bara jag bara 102 trianglar för att skapa en kyckling. I och med att jag har former som man kan förknippa med en kyckling så ser man att det kan vara det eller en annan fågel fast att den inte är texturera ännu.

spaceship lvl1 och lvl2

 

Bilden ovan så har jag skapat två stycken rymdskepp. De använder sig av samma saker för att på så sätt visa att de hör till samma ”planet”. Den till höger är den första modellen. Den till vänster jag jag kopierat ringen från förra tre gånger och satt ihop det till ett nytt.