Mens mye av dette års Unite-konferanse fokuserte på teknologi-relaterte aspekter av Unity-motoren, var det mange samtaler fra utviklere om deres erfaringer med å utvikle spill med små lag ved hjelp av Unity. I denne artikkelen vil jeg gå over noen av de store innsiktene som Unity-utviklere fra hele verden har å tilby, sammen med noen tekniske tips jeg plukket opp underveis.
Kreditt til Bluecadet for forhåndsvisningsbildet.
Jenter liker roboterIkke vær redd for å dele designene dine.
Ziba Scott, Popkannibal
I Ziba Scotts etterliv av hans spill Girls Like Robots, gikk han på rommet gjennom de store suksessene og kostbare feilene Popcannibal led på veien til å skape et vellykket Adult Swim-spill.
Han fremhevet først viktigheten av å være ubearbeidet for å dele spilldesign med mennesker rundt deg. I utgangspunktet syntes ideen om å dele sin tidlige design for jenter som roboter farlig. Scott minnet om at selv om det var frykt for at deling av hans design ville føre til tyveri av hans ideer, skjedde det motsatte. Da han ba om tilbakemelding, ville menneskene rundt ham faktisk bidra til å forbedre sin design ved å peke på noen av de kompleksitetene og inkonsekvensene han ikke kunne se seg selv.
Langs disse samme linjene foreslo han at mangelen på preproduksjon skadet den generelle oppfatningen av spillet av de som jobber med den. Mer av spillet eksisterte i Zibas sinn enn ute for laget å bli inspirert av. Han foreslo at hvis han hadde eksternisert flere av sine planer for spillet, ville det ha ført til en bedre felles visjon mellom alle lagmedlemmer og et mer konkret konsept for teamet å støtte og motivere av. Han musiserte at bare en liten konseptkunst ville ha gått langt for å holde laget opptatt av sluttmålet.
Å sette designene dine ut for at alle skal plukke fra hverandre kan være veldig skummelt, men det gjør at designet skal stå på egen verdi. Ikke bare får du verdifull tilbakemelding fra forskjellige synspunkter, men handlingen med å sette spillet ut for kontroll har bivirkningen av å tvinge deg til å undersøke dine egne designbeslutninger. Bare husk at mens ekstern tilbakemelding er viktig, gjør du som designer den endelige avgjørelsen.
Shroud av Avatar: Forsaken DyderHa en "truthiness" til virkeligheten du oppretter.
Richard "Lord British" Garriott, Portalarium
Richard Garriott har en lang og interessant historie i spillutviklingsbransjen. Som skaperen av Ultima-serien og produsent av City of Heroes og Tabula Rasa har han ganske stor erfaring med å skape store, vedvarende virtuelle spillverdener (faktisk han er fyren som utgjorde termen MMO i 1997). Hans siste innsats, Avatar av Forsaken, Forsaken Dyder, blir bygget ved hjelp av Enhet, som Garriott hevder vil tillate ham å lage et "Ultima-scale" -spill på bare 18 måneder.
I sin hovedrolle ga Garriott litt innsikt i hva hans 30+ års RPG og MMO-opplevelse har lært ham om å skape overbevisende spillverdener. Kjernen foreslo han at en hvilken som helst spillverden trenger å ha en litt "truthiness" til det (å låne et begrep fra Stephen Colbert). Denne sannheten syntes å omfatte tre hovedkonsepter:
Kombinert bidrar disse konseptene til å øke den oppfattede dybden av spillverdenen.
Kanoner av IcarusUtvikle spill er vitenskapelig forskning, ikke produksjon.
Brian Kehrer, Muse Games
Etter suksessen til Guns of Icarus ble teamet på Muse Games nærmet seg for å utvikle en online versjon. Høyt av sin første suksess og opphisset om fornyet interesse fra støttemottakere, ble et 130-siders spilldesigndokument skrevet opp. Mens deres spill vokste i omfang fra Guns of Icarus, gjorde deres lagstørrelse ikke. Etter ni måneder med svært hardt arbeid fant de seg knapt å møte sine mål.
Det var på dette tidspunktet at Kerher bestemte seg for at noe måtte forandre seg. Han trengte en måte å gjenta mer med det samme antall mennesker. I sin tale foreslo Kerher at Agile er veien for å oppnå dette, og hevdet Guns of Icarus Online som bevis på at hans tilnærming kan gi svært positive resultater.
En komponent i Agile-metoden er å ha et funksjonelt stykke programvare på slutten av hver utviklingssyklus. For å møte dette kravet sørget Kerher for at alle utviklingsoppgaver ble brutt ned i oppgaver som kunne fullføres innen en to-tre-ukers periode. Disse mindre oppgavene tillates for mindre deler av konstruksjonen å bli iterert på kortere tid. Design som ikke fungerte eller ikke var fornuftig ble fanget veldig tidlig. Kerher hevdet at fordi det er så mange potensielle løsninger for en "morsom" mekaniker, er den eneste måten å tømme ut den optimale mekanikken, å eksperimentere.
Maskinvare: Shipbreakers (siden omdøpt til Homeworld: Shipbreakers)Skriv kode slik at programmereren ikke trenger å være der.
Gerald Orban og Lance Mueller, Blackbird Interactive
Gerald Orban og Lance Mueller fra Blackbird Interactive hadde et problem: Mens de skrev deres GUI-heavy game Homeworld: Shipbreakers, fant de seg til å bruke mer og mer tid til å justere verdier og feilsøkingssystemer for kunstnerne enn de skrev ny kode. I deres snakk går de over den iterative prosessen som førte dem til det fleksible, kunstnerlige GUI-systemet som de nå bruker i produksjonen.
Tidlig i utviklingsprosessen forsto Orban at GUI i Homeworld: Shipbreakers var avgjørende for gameplay. Enda mer enn de fleste RTS-spill, hadde Homeworld flere lag med data som skulle vises, forsvinne, kombinere og skille avhengig av zoomnivå og hva som var på skjermen. Med hundrevis av ikoner gjengitt samtidig, var den første nødvendigheten å organisere alle disse dataene i forskjellige lag, som ligner på hvordan Google Maps skiller kollektivtransport, steder og trafikkinformasjon.
Den første iterasjonen var piksel skyggefull, gitt ingen WYSIWYG, og krevde at en programmerer skulle være der for å gjøre tillegg eller modifikasjoner. Mens laglegging av data bidro til å segmentere ting visuelt, var det ingen kroker i redaktøren for å foreta noen endringer, slik at endringer i farger og ikoner måtte gjøres av utvikleren via kode.
Den andre og tredje iterasjonen ble gjort marginalt bedre ved å utsette GUI-objektene som skal manipuleres i scenen. Selv om dette tillot artister å transformere GUI-elementer, ønsket de fortsatt mer kontroll over det individuelle utseendet.
Til slutt, etter den åttende iterasjonen, begynte de å knytte seg til Unitys editorskriptingsfunksjonalitet. Dette lar artister manipulere GUI mer effektivt, og lar dem feilsøke sine egne problemer ved først å sikre at det ikke er et problem med konfigurasjonen av det aktuelle GUI-elementet.
Gå nøtter og slipp raskt ut.
David Helgason, grunnlegger og administrerende direktør, Unity Technologies
En ting som David Helgason understreket i sin hovedrolle var at ting går veldig fort nå - så fort at det å lage spill veldig raskt, er det å overvinne den treårige utviklingssyklusen som har dominert spillutviklingsbransjen i år tidligere. "First to market" og "quick to market" blir stadig viktigere etter hvert som flere uformelle plattformer kommer fram, og driver utviklere mot raskere iterasjoner. Raskere iterasjoner betyr mindre overførbare spill, i en kortere tidsramme.
Han styrket denne ideen ytterligere ved å utdybe hva han kalte et "underholdningshalveringstid". I hovedsak er kreasjoner i forskjellige medier varierende lengre tid før de blir glemt eller irrelevante. Eldre musikk har en tendens til å holde seg lengre enn eldre filmer. Eldre filmer har en tendens til å holde seg lengre enn tradisjonelle spill. Og mobilspill har en korteste halveringstid på alle medier. For å ekstrapolere betyr dette at for mobilspill er tidsrammen for å tjene penger mye kortere i forhold til andre medier.
Om dette er bra for næringen, er det ikke helt klart. Ettersom kortere tidsramme reduserer utviklingstiden, kan kompleksiteten av spill også reduseres. I stedet for å gjennomtenkt utforme spill, kan bransjen ta på seg en "se hvilken pinne" mentalitet. På den annen side, fordi investeringen er så lav, har en svikt mindre betydning, noe som gir mer frihet i designernes hender å designe utenfor boksen.
Ikke obsess om [markedsføring] taktikk.
Darren Williams, Markedsdirektør, Unity Technologies
Williams startet sin tale ved å si hva mange indie spillutviklere føler: markedsføring suger. Bare å tenke på hvor å annonsere, hvordan å incentivere, KPI / CPA mål, og kostnaden i tid og penger for å få spillet ditt lagt merke til er nok til å få en indieutvikler lengt etter en utgiveres intervensjon. Williams fortsatte å liste opp noen feil som spillbedrifter gjør og hvor selv en uavhengig utvikler kan lære å nyte markedsføring.
En feil spill selskaper gjør (eller tror de trenger å gjøre) er å fokusere på markedsføring taktikk. Williams snakket om de kraftige markedsføringsløsninger som eksisterer nå, men disse løsningene tar penger. I stedet foreslo han å fokusere på mer organisk vekst ved å målrette mot bestemte publikumstyper, som han foreslår at det er fire: Innovator, Tidlig Adopter, Massemarked, og sinke.
Innovatører er vanligvis veldig tech oppmerksomme og har stor innflytelse på publikum typer over dem. Ved å fremme spillet ditt i samfunn hvor Innovators lever, legger du grunnlaget for et fellesskap.
Når spillet alfa er i hendene på Innovators, er det på tide å begynne å bygge et pre-release-fellesskap. Som innovatører lærer om spillet ditt, vil de ha et nettsted eller forum for å komme tilbake til hvor de kan finne virkelig spesifikke tekniske detaljer og oppdateringer. Etter hvert som tiden går, foreslo Williams å begynne å frigjøre høyere nivå, mindre tekniske oppdateringer ettersom Early Adopters begynner å ankomme.
Med et fellesskap bak spillet ditt, er det bare et spørsmål om å forberede seg på en lanseringsdato. Williams gikk ikke direkte inn i hvordan man skal ta et spill fra innovatør / Early Adopter publikumtyper til massemarkedet, men nevnte at å ha et organisk pre-release-fellesskap er utrolig gunstig når man prøver å få støtte for ting som Steam Greenlight og Kickstarter.
Et aspekt av spillutvikling som Unity-utviklere ikke bruker mye tid på, er å håndtere minne. Dette skyldes at Unitys skriptmotor implementerer en søppelkollektor som auto-magisk tar seg av å rydde opp de irriterende gjenstandene som ikke lenger er referert av scenen. Mens denne søppelkollekten gjør hukommelsesadministrasjonen enkel for utvikleren, er det flere gotchaser og optimaliseringer som kan bidra til å presse mest mulig ytelse ut av skriptene dine.
Den første tingen å forstå om Unitys søppelkollektor er det som er bruk merk og fei å krysse trær med referanser for å finne ubrukte objekter. Som objekter gjør referanser til andre gjenstander, vokser disse trærne i størrelse og tar lengre tid å krysse. For å holde størrelsen på disse trærne små, foreslår utviklere å bruke PODer der det er mulig. Fordi PODer ikke kan referere til objekter, holder referanse trærne mye mindre. Et enkelt eksempel på dette ville være å referere til indeksen i en matrise i stedet for objektet i matrisen.
Det andre tipset for å forbedre søppeloppsamlingshastighet utviklere foreslått var å bruke en struktur og arrayer der det er mulig i stedet for klasser eller en liste. Begge strukturer og arrays er tildelt i sammenhengende minne, noe som forbedrer tilgangshastigheten og gjør skanning av disse referansene lettere for søppelsamleren.
Til slutt er den beste antakelsen å anta ingenting. Noen ganger er det en forventning at fordi et stykke kode ser renere ut at det er mer effektivt. Et eksempel på dette er når du legger til to Vector3
strukturer sammen. Normalt vil dette bli gjort ved hjelp av +
operatør (v1 + v2
, eller v1 + = v2
), som ender med å tildele en midlertidig Vector3
å holde verdien før du tilordner den tilbake til v1
. Mindre minne tildeles ved bare å legge til v2
's x
, y
, og z
komponenter direkte til v1
komponenter.
Mens Unite 2013 ikke hadde et sammenhengende tema, var den underliggende meldingen i hver tale klar: "Gå videre og lag spill." Gjør dem raskt, og gjør dem morsomme, og gjør dem til alle. Siden teknologien for å gjøre spill blir enklere, faller innføringshindringen for uavhengige utviklere og har en demokratiserende effekt på bransjen. Kortere utviklingsherrerasjoner skifter kraft fra store bedrifter tilbake til individuelle skapere, og på grunn av dette vil utgivere vende seg til uavhengige for neste generasjon av spill.
Hvis du er interessert i å se videoer fra Unite-konferansen, kan du finne dette og tidligere års samtaler på Unitys Unite Archive.