Share
Da jeg deltok på GDC 2013, tilbrakte jeg mesteparten av tiden på Uavhengig Game Developers Summit hvor jeg fikk høre mange vellykkede indie-utviklere snakk om hvordan deres prosjekter lyktes og hvordan de har bodd i virksomheten gjennom både suksess og fiasko. I denne artikkelen går jeg over tipsene jeg fant mest nyttige, og de jeg tror vil hjelpe deg å være den beste utvikleren du kan være.
Relaterte innleggNår det er mulig, gjenbruk eksisterende elementer, i stedet for å lage nye.
Andy Hull
I Hulls mini-snakk diskuterte han arbeidet han gjorde på Indiespillet Spelunky da det ble hentet til Xbox 360, og hvordan hans erfaring som en leketøydesigner hjalp ham. En av de tingene han diskuterte var at når du designer et tre-leketøy, som faktisk må masseproduseres, har hvert aspekt av produktet potensial til å øke prisen på produksjonen drastisk. Selv noe som er så enkelt som å legge til en ekstra malingfarge øker tiden og pengene som går inn i produksjonen av et leketøy.
Selv om dette ikke er tilfelle for videospill, i hvert fall ikke teknisk, er det fortsatt svært viktig å gjøre godt bruk av spillelementene du har, og vær forsiktig med å legge for mange elementer til spillet ditt.
Under utviklingen av Spelunky for Xbox 360 begynte designerne å se på bruken av hvert våpen i spillet, og fastslått at pistolen i utgangspunktet var en dårligere versjon av haglegeværet, et annet våpen i spillet. På toppen av det hadde Pistoler et helt ammunisjonssystem som ikke ble delt med andre elementer, og dermed å ha og administrere en pistol kunne være irriterende for spilleren.
Når de flyttet spillet til Xboxen bestemte de seg for å fjerne pistolen og erstatte den med en Boomerang. Ikke bare gjorde Boomerangen mange av de samme tingene som pistolen, det hadde også den ekstra bonusen å kunne slå fiender bak deg hvis du hoppet da den kom tilbake til deg, i stedet for å fange den. Ved å fjerne pistolen gav den dem friheten til å legge til et nytt element i spillet, og tillot dem å introdusere en ny mekaniker.
Som Sid Meier sier, "Et spill er en rekke interessante valg". Ved å sørge for at gameplaymekanikkene dine er unike, og at det er svært lite overlapping mellom funksjonene, holder du valgene interessante for spilleren, og gir dem en grunn til å komme tilbake. Når du vurderer spillet ditt, spør du deg selv hva formålet med hver enkelt er. Hvis du finner to elementer som er veldig like i naturen, kan du vurdere å kutte en eller omforme den slik at den er mer unik.
Ikke vær redd for å ta et skritt tilbake og re-design eller re-utvikle.
Dylan Cuthbert
I sin tale diskuterte Cuthbert ideen om at noen ganger, selv når du har en god ide, kan det blokkere deg fra å se en bedre ide.
Før Cuthbert grunnla spillstudiet Q-Games, jobbet han på den opprinnelige versjonen av Star Fox for SNES. Da han jobbet på Star Fox, hadde de opprinnelig planlagt å gjøre alle nivåene store åpne områder som spilleren kunne fly rundt og kjempe inn som de ønsket. Mens mekanikeren arbeidet, og syntes å være interessant, var selve spillet ikke så gøy som de trodde det skulle være. Spillet var i denne tilstanden i noen måneder før til slutt regissøren kom opp med ideen om å fjerne det frie roaming-aspektet av spillet.
På den tiden syntes denne ideen absurd fordi så mye av spillet var basert på det faktum at du kunne fly hvor som helst i spillfeltet. I tillegg var det gratis populær på det tidspunktet, så det tok også bort det som syntes å være et stort trekk til spillet. Til tross for begge disse tingene, da de fjernet freelance-funksjonene i spillet, fant de at det faktisk ble lettere å utvikle fordi de hadde mer kontroll over spillerens opplevelse og hva de gjorde på en gang, og det ble mer moro fordi spilleren ikke kunne gå seg vill, og hadde en større forståelse av hva som foregikk.
Selv om det kan virke absurd i begynnelsen, er det viktig å huske at uansett hvilken type spill du vil lage, er det ingen funksjon som har å være i spillet ditt. Ved å evaluere spillet ditt fra flere perspektiver og prøve ut mange forskjellige måter å implementere samme type mekaniker, vil det ofte føre til mye mer interessante spill. På toppen av det, bare fordi en funksjon virker integrert i spillet, betyr det ikke at det er. Et godt spørsmål å spørre deg selv gjennom utviklingen av spillet ditt er "Hva er denne funksjonen occluding?" eller "Er det en bedre mekaniker som er skjult av denne mekanikerens skygge?" Enkelt sagt, vær ikke redd for å fjerne en mekaniker fra spillet ditt, fordi det kan ende med å gi deg inspirasjonen til en enda bedre mekaniker å bruke på dennes sted.
Jeg synes det er også interessant å merke seg at mens de jobbet på Star Fox, ville de ofte legge til mekanikk for å se hvordan spillet endret seg med den nye mekanikken som ble inkludert, og deretter fjerne dem like raskt. Dette gjorde at de virkelig kunne se kontrasten i spillet med og uten mekanikeren, noe som ga dem en enda sterkere forståelse av hvordan det påvirket spillet.
Fokus på innholdet.
Matt Gilgenbach
I sin tale diskuterte Gilgenbach hvordan hans personlige kamp med OCD og perfeksjonisme skadet utviklingen av hans indie-spill Retro / Grade. Samtidig med å utvikle spillet Gilgenbach obsesset over utseendet på spillet og få en rekke avanserte grafiske funksjoner implementert, men til slutt hadde hans tid vært bedre brukt å utvide det faktiske innholdet i spillet og ikke bare gjøre alt spesielt pent.
Retro / Grade var et rytmebasert spill som var i utvikling i flere år, men da det endelig ble sluppet, hadde det bare 10 spillbare sanger. Problemet han gikk inn i var at han ikke fokuserte nok på innholdsutvikling, og fokuserte i stedet på å gjøre spillmotoren mer i stand til å legge til unødvendige funksjoner og visualer. For eksempel, se på den store "Octo-bot" spilleren kjemper i videoen nedenfor:
I Gilgenbachs tale sa han at det faktisk er en rekke komplekse animasjoner som blir gjort av Octo-botens øye, og at han tilbrakte mange timer på 3D-modellen, og sørget for at øyet ville fungere riktig som om det var et reelt objekt. I et spill hvor du hadde mange nærbilder av denne modellen eller karakteren, ville dette være svært viktig og ville være en god bruk av tid, men i dette spillet, og i dette eksemplet, er det ikke. Du kan knapt se øynet - og, selv om du kunne, er det et minimalt viktig aspekt av karakteren i beste fall. Hvis Gilgenbach hadde brukt mer tid på innholdsutvikling, eller fjernet noen av de visuelle funksjonene som gjorde kunstgenstandene så tidkrevende å produsere, ville han ha endte med et bedre sluttprodukt overordnet.
Når du arbeider med spillene dine, ikke la dine egne oppfatninger av spillet og de mindre ting du vil ha fast, hindre deg i å se hva som virkelig er viktig. Alltid vurdere hvordan tingen du jobber på, vil påvirke spilleren og deres erfaring, og spør deg alltid om en funksjon vil øke salget eller spillerenes glede av spillet selv.
Å gjenoppfinne hjulet er en felle.
Devin Reimer og Alexander Schwartz
I denne diskusjonen diskuterte grunnleggerne av Owlchemy Labs hvordan de opprettholder sin virksomhet og hva de gjør for å minimere bortkastet tid når nye prosjekter påbegynnes. En ting de berørte på, var at du aldri skulle bruke betydelig tid på å prøve å gjøre noe fra grunnen da du like like kan bruke eksisterende verktøy eller programvare for å få jobben gjort mye raskere.
Som en indieutvikler skal du enten lage et helt originalt spill, eller gjøre kontraktsarbeid for en utgiver eller ekstern kilde. I begge disse scenariene vil det være å kaste bort tid på viktige ting som å implementere avanserte, å måtte bruke utallige timer i begynnelsen av prosjektet som implementerer grunnleggende tastaturkontroller eller få spillmotoren til å tegne 2D-bilder på riktig måte. gameplay-funksjoner, eller balansere alle de forskjellige spillelementene. Til slutt er tiden din bedre brukt til å designe og polere spillet, ikke programmering av et system som du har laget hundre ganger før.
Når du starter et nytt prosjekt, vurder alltid om det finnes en eksisterende motor eller et verktøy du kan bruke, eller hvis du kan gjenvinne elementer av kunststilen fra andre spill du tidligere har laget. Det er viktig at alle spillene dine er unike, men det er også viktig at hvert spill du lager blir ferdig før du går tom for penger, så hvis det finnes måter å øke hastigheten på utviklingen ved hjelp av eksisterende verktøy eller ressurser, kan det være lurt å minst vurdere disse ideene.
Velg riktig kunststil.
Ian Marsh
I sin tale diskuterte Marsh mange av tingene han lærte i løpet av årene hans firma NimbleBit har vært i virksomhet. En av de tingene han diskuterte var hvilken innvirkning ditt valg av kunststil kan ha på spillet ditt. Ikke bare gjør kunststilen utseendet på spillet, det har også en dyp effekt på hvor lenge innholdet vil ta for å skape. Noen kunststiler, etter behov av kompleksitet, vil ta vesentlig lengre tid, eller kreve at mange flere skal utføres godt, så det å velge å gå med en av disse stilene kan være svært skadelig for en indieutvikler.
Mens det ville være flott hvis du hadde tid eller ressurser til å forplikte seg til å gjøre ditt indie-spill, ser ut som Halo 4 eller Diablo 3, ble disse kunststilene begge utviklet i løpet av mange år av lag med hundrevis av utviklere og artister. Forvente å kunne reprodusere det detaljnivået og kvaliteten med et lag med fem mann på et budsjett, er ganske enkelt urealistisk, og vil trolig forhindre at spillet ditt kommer til å bli fullført.
Å velge en kunststil er et viktig skritt, og alle aspekter av den beslutningen vil få innvirkning på tid og energi det tar å utvikle hver kunstfordel. Hvis du lager et spill som kan gjøres like enkelt i 2D som det kan i 3D, og forplikte seg til å ha full 3D-ressurser med vanlige kart, vil spekulative kart, gjennomsiktighetskart, diffuse kart og reflektivitetskart være en sløsing og ville utvide omfanget av utvikling og antall lagmedlemmer du trenger for å fullføre spillet.
Takeaway her er dette, velg din kunststil nøye fordi det vil påvirke hvordan spillerne oppfatter ditt spill, men det vil også påvirke hvor hardt spillet ditt er å lage, og det er like viktig på slutten. Ikke skade deg selv ved å forplikte seg til å gjøre noe som ligger utenfor omfanget av laget ditt eller prosjektet, og i stedet finne midtveien til en oppnåelig stil som også formidler meningen du ment.
Vær forsiktig med hvor mye tid du forplikter deg til hvert prosjekt
Flere samtaler
Disse er faktisk to tips fra forskjellige kilder, men de er både relatert til tidsstyring, så jeg syntes det var best å holde dem sammen slik.
Utviklerne på Owlchemy Labs sa at de i løpet av sin karriere hadde bestemt seg for at du aldri skulle bruke mer enn en uke på en prototype, fordi en prototyperdag er omtrent lik en måned med polering. Dette tipset er noe spesielt for teamet deres og det faktum at de vanligvis jobber i seks måneders sykluser, men ideen er at det er viktig å vite hvordan teamet ditt fungerer og hvor lenge du vanligvis tar for å oppnå en gitt oppgave. Dette hjelper når du bestemmer hvor mye tid du skal gi til et prosjekt, og når du prøver å finne ut om du skal fortsette på et gitt prosjekt, eller bare gå videre til en ny.
Ian Marsh fra NimbleBit sa noe lignende da han sa at en indieutvikler aldri burde bruke mer enn 6 måneder på et prosjekt. Som en indie dev, spesielt tidlig i din karriere, er en av de viktigste tingene å lage så mange spill som mulig, slik at du kan få mye erfaring på kort tid, og du kan finne ut hva du er god til og hva du er dårlig på. Hvis du legger for mye tid i et enkelt prosjekt, vil det forhindre deg i å fortsette og prøve andre ting. I tillegg til dette vil den ekstra tiden du legger inn i det opprinnelige prosjektet bare legge mer press på suksess og vil gjøre den potensielle feilen enda verre.
Ved å begrense mengden tid du forplikter deg til et prosjekt, forhindrer du at prosjektet blir større enn du opprinnelig hadde til hensikt og forhindret deg i å gå over bord. Det suger å avslutte et prosjekt tidlig, men - og stol på meg på dette fordi jeg har opplevd det - det kan være langt verre å komme inn i andre eller tredje år med utvikling på et prosjekt du ikke forventet å vare lenger enn en Få måneder. Noen ganger må du bare gi slipp.
Tenk på alle tre spillertypene: spillere med dyktighet, spillere med tid og spillere med penger.
Shane Neville
I Nevilles tale snakket han om utviklingen av Shellrazer. Shellrazer var spesielt utviklet for kjøp i app, men Neville visste at hvis han satte for tungt mot disse kjøpene, ville spillet sannsynligvis ikke være veldig morsomt og ville aldri tiltrekke seg en stor brukerbas til å begynne med.
For å løse dette problemet, vurderte utviklerne tre forskjellige spillertyper når de jobbet på spillet: spillere med dyktighet, spillere med tid og spillere med penger.
For å tiltrekke seg spillere med dyktighet arbeidet de mye for å lage et sterkt kampsystem som hadde grunnlag i klassiske RPGs. Dette tillot dem å skape et virkelig morsomt og engasjerende spill som folk ønsker å spille, selv om de ikke vil bruke penger. Det sterke kampsystemet gjorde det også mer sannsynlig at spillet trekk i store mengder spillere.
For å tiltrekke seg spillere som hadde mye tid til å spille, men som kanskje ikke er veldig dyktige, ga de hvert nivå et element av tilfeldighet i hvilke fiender du opplevde, og i hvordan fienderbølger ble konstruert. Dette betydde at selv om nivået ville være fysisk identisk uansett hvor mange ganger du spilte det, ville de typer fiender du ville møte aldri være akkurat det samme. Dette holdt spillet mer interessant gjennom replays og sliping økter, og forhindret mindre dyktige spillere fra å bli kjedelig når de spilte nivåer for tredje eller fjerde gang.
Til slutt betraktet de spillere som hadde liten dyktighet og lite tid til å begå, men som var villige til å sette inn penger slik at de kunne se alt innholdet. For disse spillerne forsikret de seg om at det var mulig for spilleren å kjøpe hvert element i spillet, og oppgradere hvert element til sitt maksimale nivå, for $ 50 eller mindre.
Ved å gjøre dette betydde det at de hadde en sterk forståelse av hvor verdifulle hvert element måtte være i spillet for å foreta et kjøp verdt det, siden de kunne sammenligne kostnaden for det elementet til kostnaden av spillet som helhet, og det betydde ingen spiller ville noen gang gå fattig for å betale for tjenester i sitt spill og tillate dem å "beholde sine sjeler", som de sa det. Egentlig, de behandlet bare spillerne som kjøpte innhold som spillere, og ikke som kontantkyr som større selskaper.
Hver spillertype krevde forskjellige hensyn når man sørget for at spillet var vellykket, men ved å jobbe hardt for å holde alle tre glade, endte de med et sterkere produkt enn de ville ha ellers.
Emballasje er like viktig som produktet du selger.
Andy Hull
En annen ting som Andy Hull diskuterte, mens han snakket om sin erfaring med treleker, var betydningen av god emballasje. I noen tilfeller, som et leksett basert på et gammeldags band, var pakken en faktisk trekasse som i stor grad økte til ektheten og følelsen av produktet siden selv emballasjen følte at den var en del av produktet. Å gjøre dette gjorde produktet dyrere, men det gjorde også produktet mer attraktivt for barn og foreldre fordi det økte kvaliteten på produktet som helhet.
I spill er emballasjen skjermbilder, boksart, tilhenger og alt annet som går inn i å vende potensielle spillere til kjøpere og fans. Sørg for at "emballasjen" av produktet gjenspeiler kvaliteten på selve spillet, er utrolig viktig.
Når du forbereder deg for å frigjøre eller fremme spillet ditt, må du ta deg tid til å sikre at alt du slipper som er relatert til spillet, har samme appell som selve spillet, og sørg for at du legger inn samme tid og energi i emballasjen som du gjør resten av spillet. Ved å sørge for å få skjermbilder av høy kvalitet som virkelig viser spillets bedre poeng, og ved å sette tiden til å lage en virkelig utrolig trailer, gjør du at spillet ditt virker mer tiltalende og forhåpentligvis gjør folk mer sannsynlig å kjøpe det.
Marker spillet ditt så mye du kan.
Flere samtaler
Dette tipset var faktisk echoed på mange av samtalene jeg dro til og ble nevnt i forbifarten til enda mer. Som en indieutvikler er det en av de vanskeligste tingene som ofte får arbeidet ditt sett. Med dette i tankene må du gjøre alt du kan for å få folk til å snakke om og tenke på spillet ditt.
Det enkle faktum er at du, og resten av dine lagmedlemmer, er trolig de største fansen av spillet ditt. Mens noen spill er heldige nok til å ha store fanbaser, gjør mange indie-spill ikke, og de få som ikke har noe så stort som til og med noen små store utgivelser. Med dette i tankene må du gjøre alt du kan for å spre ordet om spillet ditt, og sørg for at eventuelle potensielle spillere du møter vet hva det er.
En av de beste tipsene jeg hørte var at du aldri burde være redd for å gå til offentlige arrangementer. Det er lett å gå til arrangementer som GDC og snakke om et spill du lager siden du vet at andre utviklere vil trolig kunne se forbi grove kanter, men å gå til offentlige arrangementer som PAX, eller til og med små lokale konvensjoner, kan være skummelt siden du er redd for hva potensielle spillere kan tenke. Ikke la denne frykten stoppe deg fra å gå skjønt. Husk at hver person du møter er en potensiell spiller, og hvis de aldri har hørt om spillet så er det en flott mulighet til å fortelle dem om det. På toppen av det er disse menneskene på disse hendelsene fordi de liker spill, og hvis din er morsom, ser de forbi de grove kanter også.
Ikke begrenset deg til bare spillbegivenheter, det er mange steder du kan prøve å få oppmerksomhet for dine spill som lokale høyskoler eller festivaler, eller til og med offentlige steder med oppslagstavler. Hvis du har et spill og du vil ha det til å bli oppmerksom, bør du ta all sjanse du må gjøre, ikke bare de "trygge".
Poenget med dette tipset er enkelt: Fremme spillet ditt hver sjanse du får, fordi en spiller du kan finne er verdt å ha. På toppen av det er ord i munn den beste måten å gjøre noe populært, og alle du kan overbevise om å spille spillet ditt, har potensial til å få andre til å spille det også.
Det er de leksjonene jeg tok bort fra årets GDC. Mens noen av disse leksjonene kanskje ikke gjelder for alle utviklere, og noen kan ganske enkelt ikke gjelde ennå, Det er mye god informasjon her, og jeg håper at dere alle kunne få så mye ut av det som jeg personlig gjorde.
Hvis du vil se noen av samtalene fra GDC 2013 eller en tidligere GDC-hendelse, kan du gå til GDC Vault der de har en rekke gratis samtaler fra tidligere hendelser, og de fleste av de andre samtalene er tilgjengelige for varierende avgifter. På toppen av det har mange høyttalere lastet opp lysbildene eller lyden fra deres samtaler på nettet, så hvis du søker rundt i YouTube eller spillutviklingssamfunn, kan du kanskje finne noen der også.
Accentsconagua