Share
Så du har bestemt deg for at du vil lage et videospill som en hobbyist. Du har plukket en utviklingsplattform, les noen opplæringsprogrammer, og du har en kul spillidee i tankene. Du er helt opprettet, tid til å komme i gang, la oss slå på datamaskinen, ikke sant? Feil.
Videospillutviklingsstudioer er selskaper; penger definerer hva de kan og ikke kan gjøre. Men du er ikke et selskap, og ting er ikke så grei for deg.
En antagelse mange ensomme hobbyistutviklere gjør er at deres utvikling vil fungere på samme måte som et studio. At de ikke trenger å betale seg en lønn, og de er ikke avhengig av sitt spill for penger, så de kan ta så lenge de vil fullføre det; de kan gjøre alt de tenker på.
Dessverre er dette ikke slik det egentlig virker. Som enmanslag er du begrenset av dine nåværende ferdigheter og ferdighetene du vil kunne skaffe deg under utvikling. Dette kan virke åpenbart, men det er noe som ambisiøse nye utviklere ofte glir over. Mange nye hobbyister, inkludert meg selv, fikk tåkete øynene første gang de begynte å lage et spill, tenkte på den fantastiske opplevelsen de ville skape, og helt mistet synet av hva de realistisk kunne oppnå.
Å lage et videospill er komplisert arbeid, spesielt alene. Fra design til programmering til kunst, ikke alle kan gjøre alt, og det er ikke alltid lett å lære. Du kan være villig til å lære å lage din egen stive kroppsfysikkmotor, men å få det gjort uten å miste interessen i prosjektet ditt, kan være vanskelig - og hvem vet, kanskje matematikken bak fysikken bare ikke er enig med hjernen din.
Ikke utfordre deg selv med konseptet ditt, spesielt hvis dette er ditt første spill. Enten det ser ut som det eller ikke, vil det alltid være hindringer du ikke hadde forventet, selv i de enkleste designene, og du vil bli utfordret og lære noe under utvikling. Selv om du ikke søker det ut, vil det skje på egen hånd.
En annen ting å huske på: omfang. Spill tar alltid lengre tid å gjøre enn du tror de vil, så juster designene dine tilsvarende. Som nitti og nitti regelen sier:
De første 90 prosent av koden står for de første 90 prosent av utviklingsperioden. De resterende 10 prosent av koden står for de andre 90 prosent av utviklingsperioden. Tom Cargill av Bell Labs
Denne regelen er humoristisk, men den beskriver den typiske utviklingssyklusen til et spill. Du får alt som tilsynelatende kjører perfekt og tror du er nesten ferdig ... og innså plutselig at du fortsatt har massevis av arbeid for å gjøre polering av spillet ditt. Ting som brukergrensesnitt, lyd og last-minute glitcher krever mye mer tid enn du tror.
Jo større spillet ditt er, desto flere av disse små tingene vil det være å fikse - så vær alltid i orden.
Har du et konsept du er sikker på at du kan utføre på? Flott - men ikke start ennå. Du kan ikke kode a konsept; ingen programmeringsspråk eller spillutviklingsverktøy lar utviklere lage spill i vage, brede slag. Du må vite detaljene for hva du lager.
Anta at du lager en 2D puslespillplattform som foregår under vann med en kul vektmekaniker. Det høres fantastisk ut, men du kan ikke kode en "kul vektmekaniker", du må bryte ned hvordan det fungerer på et svært spesifikt nivå.
Du må vurdere alle disse aspektene før du begynner å lage innholdet. Selvfølgelig vil mange ting endres i løpet av utviklingen - du kommer opp med nye ideer og skrap gamle - men det er viktig å ha en god ide om hva du gjør før du treffer datamaskinen.
Jeg er ikke alene i denne mentaliteten. Hele kartet for Shadow Complex ble laget på grafpapir før noen til og med rørte ved en datamaskin. Nå er dette definitivt en uvanlig utviklingsstil, og jeg sier ikke at alle skal gjenta det, men laget over på Chair Entertainment forstår definitivt verdien av å forstå spillet ditt før du bygger det.
Jeg er fast på dette punktet fordi det er en kamp jeg kom over meg nylig, og jeg vil gjerne bruke meg selv som et eksempel på hva jeg ikke skal gjøre.
Jeg var spent på å begynne å utvikle et spill i sommerferien, da jeg var garantert å ha mye ledig tid. Jeg kom opp med et konsept jeg trodde var ganske kult, fikk litt god tilbakemelding om en teknisk demo jeg bygget og startet koding. Problemet var alt jeg hadde var et konsept. Jeg hadde en primær spiller evne som jeg trodde var interessant: du kan skyte noen fliser i nivået for å gjøre det stige opp eller ned, slik at du beveger deg rundt og squish fiender. Bortsett fra alt jeg hadde, var en sjanger og generell stemning av hvordan jeg ønsket at spillet skulle føles.
Dette var katastrofalt og dumt. Jeg var så ivrig etter å komme i gang at jeg ikke hadde anelse om hva jeg prøvde å gjøre. Jeg endte opp med kodingsfunksjoner tilfeldig, og håpet mitt spill ville krystallisere til noe kult. Det jeg fikk var en veldig rotete kodebase, kunst som så ut som om spillet mitt fant sted i en jungel (og kanskje det gjorde, jeg tegnet kunst før jeg hadde en innstilling - gå figur) og ingen inspirasjon overhodet.
Tross alt mistet jeg helt interesse for prosjektet fordi det var så vanskelig å lage. Designet var ikke spesielt komplisert, og det var ingenting jeg ikke hadde gjort før, men jeg fant fremdeles utvikling omhyggelig, vanskelig og slet ikke stimulerende.
Bruk meg som et eksempel - du kan lese mer om mitt forlatte prosjekt på bloggen min. Vet hva du vil gjøre før du begynner å gjøre det.
Nesten alle gamedev ettermord diskuterer prototyper. "Bare prototype og lektest, skyll og gjenta til du har noe du liker."
Jeg har aldri laget et spill som en del av et stort lag, men jeg har erfaring med å jobbe i små lag og på egen hånd, og jeg kan fortelle deg at prototyping ikke er så fort og enkelt som du kanskje tror. Når du bare er en person som jobber med et spill, får det bare en liten del av det å jobbe, og det kan ta en stund, og bruk av dette som en metode for å finne ut de viktigste spillkonseptene er ganske kjedelig opplevelse.
Men prototyping og spilltesting har sin plass i et enmanslags utviklingssyklus - du trenger bare å gå om det på en annen måte.
Når du finner ut om en spillidee er like stor som du tror det er, er ingenting mer effektivt enn å faktisk sette seg ned og spille det. Dette endres ikke når du arbeider alene, men fordi prototyping kan ta så lang tid, trenger det litt ompasning. Ikke gå blindt inn i prototyping, tenk på det som en tid der du skal teste en ting og komme opp med en rekke kule nye ideer. Tenk snarere på prototyping som et rom hvor du kan forfine ideene du allerede har, stryke ut detaljene i din eksisterende plan.
Du kan bli rammet av en bølge av inspirasjon når du begynner å få ting til å løpe, men ikke stole på det. Når du starter prototyping, er det effektivt å lage et vertikalt stykke av spillet ditt, en kort hacket sammen spillbar seksjon som representerer det beste du kan hva du vil ha en del av sluttproduktet til. Du trenger ikke å gjenbruke noen av denne koden senere, så bare få den oppe og løpe så fort du kan for å få en god måling av hva du virkelig gjør. Du kan til og med bruke en annen motor til dette enn du planlegger å bruke til selve spillet.
Dette vil bidra til å gi deg et mål å jobbe mot, så vel som en veldig god ide om hvordan designen din skal fungere. Denne erfaringen legger sammen konteksten til resten av utviklingen din og gjør at arbeidet kan gjøres veldig effektivt. Å ha det endelige produktet på baksiden av tankene dine, bidrar virkelig til å minimere mengden kunst og kodes deg senere.
Selvfølgelig er alt dette avhengig av utviklingsplattformen din. Hvis du lager spillet i noe med mye grunnarbeid gjort for deg, som GameMaker eller til og med LittleBigPlanet-nivåredaktøren, kan prototyping være rask selv om du bare er en person. I så fall skal du bygge så mange prototyper som du vil!
Når du har et design som er oppnåelig, har du hamret ut detaljene for hvordan ting skal fungere, og du vet nøyaktig hvordan du skal takle prototyping, så er du klar!
Takk for at du leste. Gå videre og få gjort det spillet - jeg gleder meg til å se det.
Accentsconagua