Share
Jeg tror at alle spillutviklere burde bruke alle verktøyene de kan for å forbedre arbeidsflyten deres, i stedet for å gjøre alt for hånd eller fra grunnen av. Men hva mener jeg med verktøy? Nivåredaktører, debuggere, analytics ...? Alle de, og mer! I denne artikkelen bryter jeg ned de ulike typer verktøy som er tilgjengelige for spillutviklere, og forklar hvorfor du vil bruke hver.
Når du utvikler et spill, vil det sikkert komme tid når du må begynne å legge til innhold til det. Dette kan være en enkel oppgave først: bare sett opp noen arrays og objekter inne i koden din. Men når utviklingen utvikler seg, kan jeg nesten garantere at innholdskoden din vil begynne å se rotete.
Tenk deg at du har ti nivåer av et plattformspill som er lagt ut i koden, med fiendspotposisjoner, gjenstander, gjenstander, fliser og alt annet i den. Som du spillerestesting det, legger du merke til at du må endre gyteposisjonen til en fiende. Innholdet av nivået er i den store filen med all informasjon for alle nivåene. Det høres ut som en hodepine for å gå gjennom hele koden på jakt etter den eksakte linjen som skal endres. Og det vurderer ikke engang endringer som kan påvirke andre endringer - som en plattforms posisjon som en fiende står på.
Selvfølgelig kan du også visualisere nivået ditt og kunne endre det på fluen. Dette er ikke mulig å se på koden.
Skriveverktøy for å hjelpe deg med spillet utviklingsprosessen er en mer komplisert, men mer givende tilnærming. Du kan skrive et verktøy som oversetter all den innholdskoden visuelt til nivået for deg selv, og når du endrer det, vil verktøyet endre innholdskoden. Du kan også skrive verktøy for å skape mer innhold for spillet ditt, hjelpe deg med å feilsøke spillet ditt og til og med hjelpe distribusjon til flere plattformer også. Eller du kan gå et nivå høyere og slippe verktøyet til spillerne dine og la dem lage innhold for spillet ditt også!
Dette kan til og med øke suksessen til spillet ditt, som du kanskje noterer om du ser etter nye spill som har gjort det allerede.
La oss ta en titt på de forskjellige verktøyene du kan lage, hvordan hver enkelt kan hjelpe deg med å legge til og administrere innhold i spillet ditt, og vanskelighetene med å skape dem.
Dette er den bredeste delen. Et verktøy for opprettelse er alt som legger til innhold i spillet ditt - elementer, figurer, nivåer, musikk ... Disse verktøyene er de som du vil bruke mest tid på, fordi etterbehandling av spillet ditt vil dreie seg rundt dem: lage nivåer, elementer og fiender; sette alt sammen polere hver bit til sine fineste detaljer. Noen av disse oppgavene kan innebære et verktøy for opprettelse.
Selv om nivåredigeren bare skal brukes av deg eller ditt lag, må du gjøre grensesnittet intuitivt og enkelt å bruke.
La oss anta at du har et nivåbasert spill. For å skape et godt verktøy for å redigere nivåene dine, er den første oppgaven å gjøre verktøyet visuelt representativt nivået for deg. Det betyr at det må vise deg nøyaktig hvordan nivået vil se etter spillerne dine. Etter det må det tillate deg å redigere innholdet på en eller annen måte, slik at du faktisk kan opprette nivået. Dette gjøres gjennom et grensesnitt. Les nøye nå, fordi dette er viktig: selv om nivåredigeren bare skal brukes av deg eller ditt lag, må du gjøre grensesnittet intuitivt og enkelt å bruke. Hvorfor? Fordi ingen liker å jobbe med noe som krever at du trykker på en kombinasjon av knapper eller klikker på en haug med knapper for å legge til noe så enkelt som et objekt på skjermen. Og det inkluderer deg og ditt lag.
Selv om du er de som opprettet det og vet alt om redaktøren, kan du lage et brukervennlig grensesnitt for alle som legger til innhold i spillet. Og hvis noen kommer til å glemme snarveien til hvordan man markerer et objekt som "collidable", for eksempel, da å ha et intuitivt grensesnitt vil være en stor hjelp.
Her er et faktisk eksempel - en enkel nivåredigerer jeg opprettet for et Windows Phone 7-kjedereaksjonsspill:
Som du kanskje har lagt merke til, finnes det hele nivåredigeringsprogrammet i Adobe Flash Professional-programvaren - jeg opprettet ikke en egen app. Flash Pro var et perfekt miljø: det krevde null innsats for å skape noe for å håndtere tegningsgrafikk på skjermen for meg, siden jeg så på et enkelt verktøy for å hjelpe meg å lage nivåene for spillet. Det eneste jeg måtte gjøre var å lage en veldig enkel utvidelse (som du kan se på videoen) for å lagre all den nivåinformasjonen et sted for meg (jeg brukte en XML-fil).
Alt annet ble håndtert for meg av Flash Pro: Jeg kunne stille skjermstørrelsen nøyaktig til skjermstørrelsen på spillet mitt, jeg kunne plassere alle objekter i sin virkelige størrelse på skjermen og sette inn guider for å hjelpe meg å visualisere hvor bildene ville gå etter en objektet hadde eksplodert. Testprosessen var like enkelt som å "kompilere" prosjektet i Flash, noe som ville åpne et vindu der du spør hvor du skal lagre XML-filen; da jeg kompilerte spillet mitt igjen, ville det lese den oppdaterte XML.
Nå, la oss forestille deg at du har et shoot-opp-spill. Har du noen gang prøvd å lage en før? Det er irriterende (og komplisert) å sette opp alle disse fiendens bevegelser og skytemønstre gjennom selve koden, og å sette opp timingen er også kjedelig.
Her er en shoot-up-level editor jeg opprettet som et annet eksperiment:
Dette er et eksempel på hva ikke å gjøre. Selv om redaktøren min hadde den grunnleggende funksjonaliteten til å la deg sette opp fiendens bevegelsesmønstre som du likte og til og med inkluderte noen hjelpefunksjoner (i så fall speilet fienden jeg redigerte for å skape en "speil" -effekt når fiender dukket opp i spillet) grensesnittet var en komplett feil.
Jeg hadde ikke en måte å visualisere alle nivåene på samme tid: alt jeg kunne gjøre var å visualisere bølge av bølge. Har du noen gang forestilt deg hvor vondt det ville være å forandre noe på nivået på den måten? Hvis jeg for eksempel ville forsinke gyetiden mellom fiender av den nåværende bølgen med 400 millisekunder, måtte jeg gå gjennom alle påfølgende bølger og legge til (400ms * antall fiender endret) til alle de første bølgetidene til de andre bølgene. For denne grunnleggende grunnen, endte jeg med å gjenskape verktøyet fra bunnen av.
Å skape etableringsverktøy er en svært vanskelig oppgave. Kanskje dette er det vanskeligste av alle de andre verktøyene å lage, siden du skal håndtere dem på daglig basis for å gjøre spillet ditt. Du må gjøre dem så raske og enkle å bruke som mulig, og de må ikke komme i veien for å faktisk lage innholdet for spillet ditt. Hvis du finner ut at du må bruke minutter eller til og med timer for å endre ting i redaktøren din fordi du har endret noe annet som måtte løses, vil du kanskje tenke på om verktøyet tjener sin hensikt.
En utmerket tilnærming er å lage redaktører i spillet. Disse verktøyene lar deg endre innhold mens spillet kjører, og for å teste hva du endret på kjøretid.
Verktøy som disse, presser produktiviteten til grensen, fordi du har øyeblikkelig tilbakemelding på endringene du har gjort. Enkelte redaktører lar deg endre verdien av attributter mens spillet kjører, slik at du kan kjøre kommandoer i sanntid og se resultatene. Du kan også "bøye tid" og registrere de handlingene du gjorde i spillet, endre deretter attributter i spillet ditt (tyngdekraft, for eksempel) og se hvordan bevegelsen til spilleren som gjør de samme handlingene ville se ut under det nye miljøet.
Ta en titt på dette eksemplet av et redigeringsprogram i spillet for et spill i utvikling, bekymret Joe:
Dette er sannsynligvis en programmers beste venner. Når noe går galt med et spill, hjelper feilsøkingsverktøy deg å finne ut hva det var. De kan også vise statistikk om spillet ditt, undersøke prosessetiden for hver funksjon som blir kalt i koden din, gi minne dumper når noe feiler, lag logger så lenge programmet kjører, og mer.
Når du programmerer et spill, vil en programmerer ofte bruke mange av disse verktøyene - spesielt utviklingsmiljøets egen debugger, hvis den har en. Imidlertid kan mange andre verktøy skrives for å hjelpe med utviklingsprosessen på dette området.
For et svært komplisert spill vil du ofte kunne gjenopprette funksjonssamlingsstakken når noe krasjer (slik at du vet nøyaktig hvilke kodelinjer som forårsaket krasj) og genererer logger så ofte du kan. Selvfølgelig må du kunne tolke disse loggene. Kanskje et verktøy for å hjelpe deg med å analysere logger kan komme til nytte ...
For eksempel, se på dette verktøyet opprettet av Adobe, kalt SWF Investigator:
Dette verktøyet, laget for å analysere SWF-filer, gjør at utvikleren kan undersøke en rekke ting i spillet, inkludert kodeanalyse (det er i stand til å demontere SWF for å undersøke nøyaktig hva programmet gjør), noe som er svært viktig for en spillutvikler - spesielt når du optimaliserer kode.
Oppgaven med å skrive et feilsøkingsverktøy er imidlertid svært vanskelig. Ikke fordi det må ha et "perfekt" grensesnitt som opprettingsverktøy; ofte brukes disse verktøyene bare av programmerere og kjerneutviklingslaget, og grensesnittet spiller ingen rolle at mye. (Selvfølgelig må den fortsatt kunne vise alt av betydning for deg og tillate deg å manipulere ting gjennom det.) Nei, det er vanskelig på grunn av den enorme mengden tekniske detaljer som må gå inn i dem.
Disse verktøyene kan imidlertid hjelpe deg med å gjøre spillet ditt bedre på spillernes plattformer, noe som selvfølgelig er veldig viktig.
Distribusjonsverktøy er nødvendig når du arbeider med ulike aspekter av spillet (kanskje en artist og en programmerer), og når du utvikler for flere plattformer. Når du utvikler for flere plattformer, må du ta hensyn til skjermstørrelsen på hver enhet (spesielt for mobilspill) og de tekniske begrensningene på hver plattform.
Tenk deg å utvikle et spill for en smarttelefon med en oppløsning på 1280x768 og en nettbrett med en oppløsning på 1920x1200. Du vil nok bruke to forskjellige sett med bilder for hver enhet, fordi du ikke vil bruke bilder til smarttelefonen og skalere dem for nettbrettet - det ville se stygg ut. Dessuten har smarttelefonen din ikke nok minne og prosessorkraft til å håndtere de store bildene du bruker til nettbrettet. På grunn av dette er et distribusjonsverktøy nødvendig for å hjelpe deg med å administrere eiendelene for spillet ditt.
Snakker om å administrere eiendeler, anta nå at du jobber i et lag, som består av en kunstner og en programmerer. Kunstneren vil definitivt skape mange kunstmidler, men hvordan går programmøren til å håndtere å referere til disse kunstfilene i spillet? Den lateste tilnærmingen ville være å bare endre eller legge til navnet på filen på hvert sted som koden bruker den når kunstneren endrer eller legger til kunstfiler. For store prosjekter er dette imidlertid ikke mulig, da det ville ta bort god utviklingstid.
En god måte å håndtere det ville være å skape et verktøy for å håndtere kunstverdier for laget: kunstneren spesifiserer bare hvilken kunstfil som refererer til hva, og verktøyet konverterer automatisk navnene til et forhåndsdefinert navn satt av selve verktøyet . På den måten trenger programmereren ikke å bekymre seg for å endre navn i koden når kunstneren endrer noe.
Disse verktøyene er enkle å overse, men du bør definitivt bruke dem i spillene dine. Verktøy etter utgivelse hjelper deg med å spore hvordan spillet ditt gjøres der ute i markedet og hvordan spillere mottar det.
Dette er svært viktig for virus- og mobilspill, men stasjonære spill kan også ha stor nytte av disse verktøyene. De lar deg spore hvor spillet er tilgjengelig og hvor mange spillere som har spilt spillet ditt. De kan gå enda lenger: verktøy som Playtomic, Mochi Analytics og GamesAnalytics kan spore hvor mange ganger et gitt nivå ble spilt, hvor mange ganger en knapp ble klikket, hvor mange spillere droppet spillet ditt (i første minutt, første fem minutter, sekund nivå, og så videre) og mer. Du kan da bruke denne informasjonen til å konkludere at et bestemt nivå er for vanskelig (basert på antall spillere som ikke fullfører det) og deretter fikse det.
Det er mer: Du kan også skrive verktøy for å spore den offentlige mottakelsen av spillet ditt på internett, ved hjelp av bots som samler informasjon om Facebook-innlegg eller Tweets som inkluderer spillets navn, viser hvilke evalueringssteder som har vurdert spillet ditt og så videre. La oss heller ikke glemme Google Alerts, et flott verktøy som gir deg beskjed når et spesifisert uttrykk vises på nettet.
Selv om du virkelig trenger å bruk verktøy for å hjelpe utviklingsprosessen din, noen ganger vil du oppdage at du ikke trenger å faktisk skape dem, som spillutviklingssamfunnet allerede har skapt mange verktøy.
Mange gode spill dev verktøy er der ute online, tilgjengelig for deg å bruke - det tar bare litt tid å finne dem. Men bruk dem med forsiktighet: Hvis du føler at et verktøy ikke gjør akkurat det du trenger, kan det være bedre å skrive din egen enn å kaste bort tiden å vri den for å passe ditt spill. Dette er ofte tilfelle for spill- eller sjangre-spesifikke verktøy.
Egentlig å lage et verktøy er et stort emne som fortjener flere artikler på egenhånd, men jeg gir deg ett tips her: du må ofte standardisere måten du håndterer spillets innhold. Dette betyr at du må komme med en måte å lagre spillets informasjon på, kunne laste den og lagre den. De fleste bruker XML eller JSON for å beskrive informasjon, men du vil kanskje lage ditt eget binære format hvis du trenger en mer spesifikk måte å beskrive ting på..
Det er slutten på analysen av de forskjellige verktøyene du kan bruke til å hjelpe deg med spillutviklingen. Jeg håper du likte artikkelen og lærte av det! Har du spørsmål, vennligst ikke nøl med å spørre.
Redaktørens merknad: Vi skal kompilere en liste over gode verktøy som Ogmo Editor, Tiled, og SFXR. Hvis du har noen forslag, gi oss beskjed!
Accentsconagua