Innholdsskaping kan være en av de mest tidkrevende delene av spillutvikling, og derfor kan det være så nyttig å bygge et nivåredigeringsprogram. I denne artikkelen deler jeg tipsene mine for å lage en effektiv nivåredigerer, og forklare hvordan bruk av denne typen verktøy har økt arbeidsflyten min.
Her er scenariet: du har brukt måneder på å jobbe med spillet ditt, og det er endelig begynt å komme sammen. Kodebasen er sterk, og du har kommet til det punktet hvor du kan begynne å lage nivåer for spillet ditt.
Det er bare ett problem - din planfil ser slik ut:
Object Texture rocks4 Plassering 78 540 Rotasjon 0 Skala 1 1 Farge 255 255 255 255 ScrollSpeed 1 1 CustomProperties Slutt End Object Texture Gress1 Plassering 60 450 Rotasjon 0 Skala 1 1 Farge 255 255 255 255 ScrollSpeed 1 1 CustomProperties Slutt End Object Texture Gress2 Posisjon 61 459 Rotasjon 0 Skala 1 1 Farge 255 255 255 255 ScrollSpeed 1 1 CustomProperties End End
Æsj. Tenk deg å prøve å lage hele nivåer som dette. Prosessen ville være utrolig sakte og tidkrevende - for ikke å nevne frustrerende. Problemet er at det er veldig vanskelig å redigere noe som er ment å være sett. Hva kan da gjøres om dette? Svaret ligger overraskende i sammenheng med selve problemet.
Nivåer er en form for visuell kommunikasjon. Spillere ser ikke på tekstfiler, de ser på bilder, sprites, animasjoner og så videre. Tenk på en maler: Picasso gjorde ikke maleriene sine ved å sette inn RGB-verdier per piksel i en datamaskin. Han gjorde sine malerier av, vel, maleri dem. For å bruke den samme logikken til nivådesign, bør vi opprette et verktøy som lar oss visuelt redigere slike nivåer - en nivåredigerer.
En av de viktigste fordelene ved å ha en nivåredigerer er WYSIWYGs bekvemmelighet ("Hva du ser er det du får" - det du ser i redaktøren er hva du får i spillet). Som beskrevet ovenfor er det mye enklere å designe når du kan se hva du redigerer.
En annen fordel er at den gir raskere og mer effektiv design iterasjon. Prosessen med nivådesign kan brytes ned til et enkelt flytskjema som dette:
Det er avgjørende at du kan bevege seg sømløst mellom design og testfaser, da dette gir raskere iterasjoner og mindre tid samlet.
Den endelige grunnen til å ha et nivåredaktør er at det gjør jobben med nivådesign mye mindre teknisk. Dette er spesielt relevant når du arbeider i et lag: forestill deg å sende tekstfilen over til artistene og fortelle dem å designe nivåer i det formatet!
God kommunikasjon - både verbalt og visuelt - er viktig i et lag, og en planredaktør kan gjøre ikke-tekniske designers liv mye enklere, samt fjerne en potensiell kommunikasjonsbarriere mellom dem og utviklerne.
Så, i sammendraget, er de tre viktigste årsakene til at du har en nivåredaktør at de tillater deg å:
Du kan spørre hvorfor du vil lage din egen redaktør når det allerede er så mange fritt tilgjengelige å bruke - og jeg kommer ikke til å lyve, det er noen gode redaktører der ute.
Her er noen jeg kjenner til for 2D-spill:
Det er fordeler og ulemper ved å bruke en generisk, eksisterende redaktør. Det er sannsynligvis å være robust og godt vedlikeholdt, men det vet ingenting om spillet ditt, så du må kanskje gjøre smarte triks for at det skal samhandle riktig med spillet ditt. Dette graver inn i iterasjonstid og kan resultere i mye mer unødvendig tid brukt under innholdsskaping.
Også, du må lære å bruke den, mens hvis du brukte din egen redaktør, vet du selvsagt alt om det allerede.
Her er min personlige liste over fordeler og ulemper for hver type editor:
Pre-bygget:
Self-laget:
Det er opp til deg, men for denne artiklens skyld skal jeg fokusere på å designe ditt eget.
Deretter deler jeg mine beste tips for å lage en robust og effektiv nivåredigerer.
Du kan kutte på det faktum at du må skrive mer kode for en nivåredaktør. Men hvorfor ikke gjøre denne prosessen så smertefri som mulig?
Hvis du er på det punktet der du trenger en nivåredigerer, har du sannsynligvis allerede litt struktur til spillarkitekturen din (klasser, grensesnitt, arv, etc.). Gjenbruk denne koden! Hvis du allerede har en masse klasser for å tegne og oppdatere ting for spillet, er det ikke nødvendig å skrive om det for redaktøren. Med andre ord, IKKE skriv en egen motor til redaktøren. Foruten å la deg bruke spillkoden, vil dette hjelpe deg å redusere gapet mellom hvordan nivået ser ut i redaktøren din og hvordan det ser ut i spillet.
Det er to tilnærminger til å implementere en nivåredigerer: du kan ha den i spillet, eller bygge den som en ekstern app. Igjen har begge tilnærmingene sine oppturer og nedturer.
In-game editor vil i hovedsak eliminere gapet mellom design og testing, men det vil kreve mye mer GUI arbeid, for eksempel. Den eksterne editoren kan bruke GUI-biblioteker og ha robuste funksjoner, men designtest iterasjonen vil være litt lengre, gitt at du må hele tiden bytte mellom to forskjellige apper.
Jeg personlig foretrekker den første tilnærmingen fordi jeg synes det føles det mest naturlige, og jeg liker virkelig bekvemmeligheten av å bytte mellom å designe og teste øyeblikkelig.
Husk at denne redaktøren er for deg (eller din level designer, hvis du jobber i et lag). Det er ikke nødvendig å få det til å se pen ut. Faktisk er det sannsynligvis en sløsing med tid, med mindre du planlegger å distribuere redaktøren. I stedet fokusere på å lage et funksjonsnivå editor så fort som mulig, slik at du kan komme til innholdsskaping. (Senere når spillet ditt nærmer seg ferdigstillelse, kan du vurdere ting som "beautifying" redaktøren.)
Dette kan virke åpenbart, men snarveier er dine venner. Ha en nøkkel bundet til enhver handling du tror du kan gjøre. Jeg er seriøs; gjør dette vil spare deg så mye tid når du designer. For eksempel, ved å trykke på 'C' i nivåredigereren av spillet mitt, opprettes et duplikat av det valgte objektet. Det er enkelt, men utrolig nyttig og sparer mye tid.
For eksempel, la meg vise deg redaktøren av mitt nåværende utviklingsspill, Mori. Her er en flis som jeg har rotert og skalert:
Alt jeg trenger å gjøre er å trykke på 'C' og ... voila!
Dette er den vakre delen av å designe din egen redaktør: det kan gjøre alt du vil at den skal gjøre.
Hvert spill er annerledes; Noen spill krever omfattende skripting, mens andre kan innebære intrikate AI-oppførsel. Alle disse kan integreres i redaktøren. Tenk deg å kunne legge til en fiende med en viss oppførsel bare ved å trykke på noen få taster i redaktøren. Forestill deg nå å prøve å gjøre det samme ved å legge til kode i en skriptfil. Som virker mer effektivt?
Det er visse konvensjoner som vi har blitt vant til ved bruk av applikasjoner. Disse inkluderer bekvemmeligheter som angre / gjenta, kopiere / lime inn, advarselsmeldinger og så videre. Hvis du planlegger riktig, kan du implementere alle disse inn i redaktøren uten mye ekstra arbeid. Stol på meg, du vil takke deg selv i fremtiden hvis du har disse.
En annen funksjon som kan gjøre livet enklere, er å kunne teste nivåer uten å lagre filen på disken. Dette gjør designtestprosessen så mye lettere. Mitt spill bruker et spill state management system, så jeg har to separate "skjermer" for gameplay og redigering.
Fra innsiden av spillet treffer jeg en nøkkel for å gå inn i redaktøren. Redaktøren er bestått av nivåobjektet, som deretter kan manipuleres fra redaktøren. Derfra har jeg to alternativer: Jeg kan lagre nivået til disk, eller jeg kan treffe en bestemt nøkkel og passere nivåobjektet tilbake til gameplay-skjermen. Dette tillater meg å teste nivået med en gang uten frykt for å overskrive mine gamle endringer.
Kort sagt, en nivåredaktør er en verdig investering i spillutviklingsprosessen. Det gir mulighet for den visuelle utformingen av nivåer, raskere iterasjonstider, og et lavere teknisk kompetansebehov for designere.
Jeg håper du fant denne artikkelen interessant og nyttig. Takk for at du droppet av!