Kategoriarkiv: Leveldesign

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.

3D modeller

sattelit

 

Bilden ovan har jag byggt en parabol.

 

kran1

bilden ovan ska föreställa en rivningsmaskin

glassbil

Bilden ovan ska föreställa en glassbil.

Dessa 3D modellerna har bland annats skapats denna veckan.

Den svåraste att komma på ett bra sätt att få ner antal polygoner vad rivningsmaskinen. Innan man kom in i att tänka lågt antal polygoner när man ska skapa 3D modeller. Efter att man hade skapat den så kom man snabbare in i tänkandet å det gick rätt fort för att skapa modeller efter det.

Dock så har vi inte hunnit göra några speciella texturer till våra modeller ännu.

Vad är leveldesign?

Vad definerar ordet ”Leveldesign”?
Det är en ganska vag definition faktiskt, som ofta tolkas olika. Deras gemensamma nämnare är dock att målet blir en värld/miljö för spelet eller produktionen att utnyttja.
”Level Design is all about the combination of widely varying individual elements, keywords, that compose a level.” (De Jong, 2008, 13).
Vilka element som kombinationen involverar skiljer sig från designer till designer, men i regel innebär det;

Gameplay (hur spelet beter sig)
Layout (hur ytan är formad)
Interaktion (vad spelaren kan interagera med)
Story (vad leveln vill förmedla)
Ljud och musik (vilken typ av ljudeffekter och bakgrundsmusik)
Ljus (var artificiellt och organiskt ljus ska vara)
Texturer och material (vilka färger och former som ska vara med på modellerna)
Effekter (var specialeffekter ska appliceras och varför)
Atmosfär och Immersion (känslan och atmosfären som ska förmedlas till användaren)
Optimering (hur leveln fungerar smidigast)

Leveldesign är ett stort område som inte avslutas i en handvändning, utan var och en av de här punkterna inkluderas i produktionen på ett eller annat vis. En skicklig leveldesigner behärskar de här komponenterna och lyckas balansera in dem så att de passar.

De Jong nämner också ett intressant system för design av levels, om sex s.k. pelare som alla bidrar till en fungerande level.

OPTIMISERING OCH POLERING
Då alla aspekterna i en spelvärld renderas i realtid så måste leveln vara så optimerad som den kan bli om den ska fungera smidigt. Minimera antalet polygoner på områden som syns minimalt eller inte alls (exempelvis baksidan av en byggnad som står utanför själva ”spelområdet”, etc) Ju fler polygoner, desto mer krävs av datorn eller konsollen för att kunna köras med bra hastighet. Enkelt sammanfattat: Ifall en level inte är spelbar, så faller hela spelet med den.
Polering innebär att man måste gå över sin level för att kolla varenda litet skrymsle så att inga detaljer som kan bryta immersionen är fel. Exempelvis så ska man inte kunna komma utanför världens utrymme, men man måste också se till att spelaren inte kan se detaljer som inte används inne i spelvärlden. En felaktigt placerad kollisonsbox är ett av de snabbaste sätten att få folk att stänga ner spelet och aldrig starta det igen.

GAMEPLAY
Gameplay är allt om att få en level att både se och vara intressant och framförallt underhållande att spela, för det är vad spel är: Underhållning. Och det är just vad designen innebär, att mer eller mindre ”ge spelarna vad de vill ha”. Världens vackraste öppna fält lockar inga spelare om det inte finns något intressant att göra på fältet. In med lite floder att simma i, ett par klippor att klättra på, ett par träd att gömma sig bakom och det är genast ett steg, om än litet, mot ett mer intressant fält.

IMMERSION
Den pelare som ur många spelares synpunkt är bland de viktigaste. Att kunna leva i världen som en av karaktärerna, i synnerhet i förstapersonsspel, är någonting som de flesta suktar efter, inte bara att kunna styra karaktären. Det här involverar dock inte enbart karaktärens relation till världen, utan även hur världen ser ut. Den måste vara logisk och, ifall den är baserad på en verklig plats, autentisk. Sätt en bil på i vattnet på en strand och varje spelare kommer undra hur den hamnade där. Ifall det inte finns märken från hjul i sanden ut i vattnet, och kanske en avtuppad förare som flyter i närheten så är en sådan sak en av de enklare ”immersion-breakers”.

VISUALIETET
Som det låter, en värld måste se lockande ut. Även den mest intressanta världen snubblar på sig självt ifall den inte är något intressant att titta på. Det här är en ganska svår pelare att spika till bra, då spelarnas åsikter är så många att spelutvecklare omöjligt kan göra alla glada när det kommer till vilken grafikstil och detaljnivå. En del spelare föredrar realistisk grafik in på minsta pixel, medan andra gillar en lite mer ”cartoonish” känsla.

FUNKTIONELL DESIGN
Den här pelaren har med mekaniken och layouten att göra. En level måste gå att navigera runt på fritt inom sina satta ramar och varje objekt måste passa in och försöka förstärka existansen av andra objekt på kuppen.

KOMBINATIONEN
Sist, men absolut inte minst, kombinationen av de fem ovanstående pelarna. ”A level can have awesome gameplay, and awesome visuals, but if the two do not complement each other it still won’t work.” (De Jong, 2008, 14). Den färdiga leveln är resultatet av alla aspekterna när alla pelarna passat ihop som ett blixtlås.

 

KÄLLA:
De Jong, Sjoerd. 2008. The Hows and Whys of Level Design.

Bokmal

Jag har under tisdagen och onsdagen mest suttit och läst igenom en rad ”böcker” och magasin kring ”hows and whys” när det gäller design av levels och layouter.

Började med att mala igenom den PDF jag nämnde tidigare som faktiskt var mer intressant än jag trodde. Den handlade mest om områden att tänka på när man designar en spelvärld, både ur design- och grafik-perspektiv (hela 55 olika punkter, med säkert ännu fler som inte stod med). Den var formulerad på ett sånt vis att den beskrev aspekten och sedan förklarade med bilder hur det användes i spel. Det blev ganska mycket av en AHA!-upplevelse för mig, för jag har spelat många av spelen som bilderna kom ifrån, men jag hade i ytterst få fall tänkt på just den biten. Jag menar, vem tänker på att en kraschad bil med fortfarande fungerande framlysen är placerad där för att ”leda” spelaren åt rätt håll? Inte jag i alla fall, inte när en zombiehord försöker slita huvudet av en samtidigt. Som sagt, jag fann den mycket inspirerande och det är definitivt något man har nyttan av i framtiden.

Fick även tips om en annan källa från en klasskamrat som sysslat med lite leveldesign under Tematiskan, så den var näst upp att läsas igenom.

- The Hows and Whys of Level Design (de Jong, 2008)

Förberedelser till level-design

Jag kommer ge mig på att utforska aspekterna kring att bygga vår värld/världar. Jag hade under mitt första block på Tematiska Fördjupningen undersökt inom det området, men det finns så mycket mer att titta på. En logisk och trolig värld är ju en av de centrala delarna i ett spel.

Jag kommer sikta på att kolla över det material jag samlade in under mitt första block, samt titta runt ännu mer på Alex Galuzin’s material, bland annat hans ebook-serie ”UDK, 11 Day Level Design”. Galuzin har en bakgrund på bland annat polska Techland (mest kända för Call of Juarez-serien) där han arbetade som just leveldesigner. Jag har också hittat en mycket intressant PDF som han också gjort, med inspiration och tankesätt. Den är på ca 150 sidor, så jag har ett par trevliga godnattsagor däri.

Galuzin basar också över en internetsite, kallad ”World of LevelDesign” som har så gott som allt mellan himmel och jord inom områdena Level Design och Environment Artist. En av de bästa sakerna med den platsen är att utöver hans egna material så har även en del andra kunna lägga upp material på den, så man får se på saken från mer än ett perspektiv. Detta gör det mer intressant att forska om det, för att kunna pilla ut ”det bästa av två världar”. Jag utnyttjade främst tutorials kring CryEngine 3 när jag hade blocket, men det finns en hel uppsjö av mycket bra artiklar till UDK och allmän leveldesign och workflows av Galuzin, en man vid namn Magnar Jenssen (har jobbat på DICE tidigare bland annat) och en tredje som går under användarnamnet IcyApex (riktigt namn dock okänt, men hans artiklar är mycket inspirerande).

Snubblade även över ett exemplar av 3D-world med en större artikel inom området. Jag kan dock inte svara än om den är givande, för jag har inte läst den än. Men jag är positiv.