Share
Hver indieutvikler eller -lag har spurt seg selv hvordan det er best å håndtere utviklingsprosessen. Er det obligatorisk å bruke detaljert dokumentasjon, for eksempel det legendariske spilldesigndokumentet (GDD)? Hva er de vanligste feilene, og hvordan kan de unngås?
For de som har søkt etter svar på disse spørsmålene, vil jeg dele vårt lags erfaring med å lage vår GDD.
Mange spilldesignere avstår fra å dyrke designdokumenter og organisere ideer. Jeg kan ikke forestille meg hvordan disse utviklerne kommer igjennom de tider at de er hindret av funksjonsfeil, plassholderkunst og sammenstøtende mekanikk, mens de prøver å huske hvorfor det var at de først utsatte deg for å lage et spill i utgangspunktet.
Å ha et godt gjennomtenkt spilldesigndokument kan fungere som din krykke i disse tider. Det vil la deg se de fantastiske ideene og konseptene som holdt deg oppe hele natten når du først startet på spillet ditt, og kanskje enda viktigere, hvilke som må klippes ut av spillet for å gjøre livet enklere eller omarbeidet for å gjøre din innsats verdt.
Et spilldesigndokument fungerer som en knutepunkt og knutepunkt for å koble til og liste alle aspekter av et spill. Den består av skriftlige beskrivelser, bilder, grafer, diagrammer og lister over informasjon som er relevante for hvert utviklingssegment, og er ofte organisert av hvilke funksjoner som vil være i spillet, og viser tydelig hvordan de alle passer sammen.
Å lage en GDD vil hjelpe teamets designer til å forstå hva essensen av spillet er og det planlagte omfanget av sin overordnede verden og spill. Pluss at å ha alle spillelementene i et velorganisert dokument, vil hjelpe designeren å formidle sin visjon til resten av teamet, samtidig som det hjelper å identifisere svakheter eller mangler komponenter som spillet kan kreve.
GDD skal fungere som master sjekkliste. Det blir dokumentet du kaster opp i luften i feiringen ved å fullføre alle sine seksjoner og fullføre spillet ditt.
Siden en GDD er full av beskrivelser, er den en ideell ressurs for alle PR- og markedsfronter, med konsepter som formidler spillets estetiske og appellasjon allerede skrevet opp og klar til å kopiere og lime inn.
Prospektive medarbeideres ferdigheter kan raskt vurderes som kvalifisert eller ikke, ved å se på deres legitimasjon sammen med deres stillinger 'tilsvarende seksjoner i dokumentet.
Hvis innsamlingen er i kortene for teamet ditt, vil det være avgjørende å ha en god kombinasjon av GDD for investorer å se over og bestemme risikoen for utviklingen din, så vel som din evne til å levere på dine løfter.
Å lage og følge et spilldesigndokument er som å plante et frø og se det vokse til et tre i løpet av utviklingen. Du har din første forberedelse, dyrking, og til slutt den grusomme og tilbakebrytende plenen av høsten.
En vanlig feil gir ikke alle dine lagmedlemmer de riktige hagen verktøy for å gjøre spillet ditt til virkelighet. GDD vil bidra til at alle sammen jobber, slik at du ikke finner programmereren din og kunstneren kutte av avdelingen de står på.
Prøver å beskrive alt på en gang
Det er ikke nødvendig å liste hver funksjon og mekaniker i detalj i det første utkastet. Dette er umulig når man arbeider på et komplekst spill med et lite lag. Ved å skissere de store noder av spill og kjerneelementer vil du få et perspektiv på hva som må gjøres, men du bør forvente å fylle dem i en etter en over tid.
Innstilling av spillmål med tidsfrister kan virke off-putting til noen utviklere. Frister er en del av den kjedelige 9-til-5-livsstilen, så mange mennesker har en naturlig aversjon mot dem.
Innstillingsfristen er imidlertid hvordan du sikrer at spillet ditt blir gjort og ikke sitter for alltid uferdig i en mappe på skrivebordet. Disse typer mål er milepæler på vei til fremgang, og å sende dem en etter en er en klar indikasjon på at du gjør noe riktig. Hver er en anledning til feiring.
Frister er en grunnleggende komponent i planlegging som hjelper deg med å overvåke ytelsen til teamet ditt og deg selv. Det hjelper i beslutningsprosesser som er forankret i virkeligheten, og til slutt bygger opp et momentum og etikk som er sunt for laget som helhet og individer i det.
Det er plass i GDD for grunnleggende beskrivelser som dekker spill, storylines og store kodingsoppgaver. Når utviklingen utvikler seg, legger du til flere detaljer i disse seksjonene. Mens du lager og tester spillet, bør du legge til eller oppdatere spesifikke tekniske detaljer hver gang en funksjon er implementert eller endret. På denne måten vil du aldri ha en konstruksjon med elementer som du ikke kan spore tilbake til GDD, skape manglende koblinger til ideer, kode eller kunst. Det kan også være nyttig å legge til informasjon om vanskeligheten ved å gjennomføre bestemte oppgaver, og om de har blitt fullt integrert i spillet eller kan kreve ytterligere revisjon.
I løpet av denne prosessen bør de første konseptene dine falle ned i stadig mer detaljerte beskrivelser av hver fasett som dine funksjoner inneholder. Dette bidrar til å lage konkrete milepæler som er enkle å navigere og backtrack for å se hvor de kommer fra og hvor de trenger å gå.
Som GDD fortsetter å vokse og blir mer fullført, er det fortsatt viktig å holde den oppdatert. Dette eliminerer situasjoner der gruppemedlemmene gjør noe uten å kunne rettferdiggjøre hvorfor de brukte tid på å gjøre dem, noe som er avgjørende, kommer knase tid.
Personlig har jeg en uforklarlig primær frykt for å drukne i en haug med trykt dokumentasjon. Dette ville bli et ekte mareritt hvis jeg måtte beholde alle gamle versjoner av vår GDD for hvert lagmedlem.
Hvorfor bør vi torturere oss selv som dette i en alder av digital teknologi? Det er mange gratis online-tjenester som Google Docs eller Trello som lar deg lagre alle endringer og se alle gruppens kommentarer i sanntid.
Når du starter GDD, er det normalt å bli pakket inn i konsepter. Bakgrunn, introduksjoner og nøkkelbeskrivelser bidrar til å kutte ut spillet og gi det form. Når du begynner å teste og implementere funksjoner, bør disse konseptene bli mer raffinert, spesifisert og detaljert. Opprettholde riktig organisasjon vil bli stadig mer kritisk ettersom din GDD får vekt og tetthet.
Start i konseptfasen, hvor du brainstormer dine ideer og får dem alle på papir. Dette burde være spennende! Det vil også fungere som en veikart, slik at du ikke mister oversikten over dine mål og visjon underveis. Når appell av bestemte spillelementer mister sin glans eller fører deg inn i en grøft, kan det være på tide å omarbeide ditt opprinnelige konsept for å sikre at du når en tilfredsstillende målstreke.
Mot midten av utviklingen, når du har et gung-ho-team ombord, vil diskusjoner og spillbygger hjelpe til med å skape og organisere dokumentet til en lett å bruke og heftig veiledning for alle. Det er fortsatt plass til å eksperimentere med nye konsepter og ideer på dette punktet, men de bør holdes i kontroll med noen av de første dokumentasjonene dine.
Hjemmet strekningen av utviklingen er hvor ditt spill design dokument vil spare deg for timer med frustrasjon og hjertesorg. Når du lukker inn på frigjøringen, bør din GDD sakte begynne å bli en stentabletter, med funksjoner og mekanikk sett i mer permanente spillbygger alle holdt sammen av kunst som sikkert ble laget over flere iterasjoner for å matche dokumentets spesifikasjoner. Dokumentet skal bidra til å holde alle lagets hjul på bakken, med en god syn på realistiske forventninger om å levere spillet.
Det er ikke nødvendig å ha en helt komplett GDD før du starter utviklingen. Men GDD må være komplett de neste 10 dagene eller to uker utover lagets nåværende arbeid - og de relevante delene av dokumentet må være så detaljert som mulig.
Deler av GDD må endres og modifiseres gjennom hele utviklingsprosessen, noen ganger selv i de siste dagene før utgivelsen. Det kan begynne å ligne en katastrofesone hvis innholdet ikke er trimmet riktig. Hvis du er redd for å slette tekst som er utdatert, klipp og lim den inn i et tillegg eller separat dokument. Dette vil la hoveddelen av GDD være relevant for den nåværende utviklingsstatus, uten alle forstyrrelser fra tidligere iterasjoner.
Ikke stoppe teammedlemmer som sender inn nye ideer. Ideopprettelse er en av de mest givende delene av utvikling, og bør oppfordres til enhver tid. Dine lagmedlemmer skal gå inn i utviklingen og vite at mange av disse konseptene vil bli kuttet og aldri gjøre det inn i spillet, men dette bør ikke stoppe dem fra å drømme! Ingen vet hvilke ideer som vil gi de beste resultatene først, så generering av nye og innovative ideer bør være en stift av diskusjonene dine og feire tilsvarende.
Tilsyn med GDD må kun utføres av ett lagmedlem. De vil identifisere de sentrale ideene som må fokuseres på, og kutte de mindre viktige ideene.
Å oppmuntre aktiv tilbakemelding er viktig, da andre medlemmer ikke har mulighet til å legge til ideene direkte i dokumentet.
De fleste utviklingsproblemene består av et hardt ytre skall av feilkommunikasjon og et mykt interiør uten å vite hvordan du kompenserer og retter dem. Disse barrierer kan elimineres med vaktig vedlikehold av GDD og klar, kortfattet dokumentasjon, og dette kan best oppnås hvis en person tar på seg ansvaret.
Vær konsekvent med skriftstiler og bruk av ensartede overskrifter og innrykk, tegnsetting og formatering. Å lage en legende eller nøkkel for å forklare hvilke spesifikke fargete høydepunkter kan bety en lang vei mot å redusere forvirring og kutte ned på tiden det tar å formidle faser av forskjellige funksjoner 'implementering.
Jo enklere og klarere du holder språket i GDD, desto bedre vil laget ditt forstå det.
Det er viktig å holde skrivingen klar og konsis, og teamet ditt bør aktivt gi deg tilbakemelding om presentasjonen og klarheten til GDD. En frem og tilbake dynamikk vil resultere i en mer sammenhengende utviklingsopplevelse, med overordnede fordeler, inkludert en definert kunststil, færre kommunikasjonsfeil og mindre stressende dokumentasjon og kontorarbeid.
Men viktigst av alt, bør GDD være en refleksjon av lagkulturen din, skapt i hvilket format du finner, fungerer best og er mest tiltalende for deg og de du jobber med.
Ingen bør noen gang kunne si at de ikke har forstått noe, eller gjort noe riktig, på grunn av mangel på referansemateriale i GDD.
Visuelle materialer og referanser spiller en nøkkelrolle i prosessen med å formidle ideer. Noen vanskelige konsepter kan forklares på kort tid med visuelle hjelpemidler som grafer og konseptkunst. Dette vil bidra til at hvert lagmedlem forstår informasjonen som blir formidlet til dem, noe som i sin tur vil hjelpe dem med å fullføre utviklingsoppgaver raskere.
Du bør ikke begrense deg til tørr tekst. (Hvis du gjør det, vil du vente lenge for alle å bli engasjert og forstå hovedideene!) Prøv å beskrive spillernes følelser og erfaringene som spillet kan dyrke.
Å holde en GDD kan høres teknisk, men du bør ikke være redd for å rive hjertet ditt og kaste det på dokumentet. La dine følelser og lidenskap bløde inn i den. Tenk deg hvordan du vil få spilleren til å føle, og skriv disse aspirasjonene sammen med beskrivelsene av funksjonene dine. Dette bidrar til å kultivere en kollektiv bevissthet i teamet ditt om hva spillet ditt forsøker å formidle til spilleren - og la oss innse det, følelser bør ha entusiasme bak dem hvis du vil at de skal bli forstått av noen andre.
Angi prioriteringene for oppgaver og funksjoner, dokumentere sine tidsfrister, og kontroller utførelsen av dem. Du kan ikke utvikle absolutt alle ideene som teamet ditt og tankene dine vil foreslå, så (etter at du har kuttet noen av dem), må du sette prioriteringer og i det minste omtrentlige en tidsplan for implementeringen.
En velstelte GDD gir en utmerket, prioritert liste over oppgaver som må fylles ut av teamet ditt. Ikke alle funksjonene i en GDD vil gjøre det til det endelige spillet. Med dette i tankene må du bestemme hvilke funksjoner som har forrang over andre, og du bør planlegge dem for implementering og testing før de andre.
Tenk hardt om hva som er kritisk for spillet ditt, og hva som er mulig med tanke på lagets ferdighetsnivå, og bruk denne informasjonen til å veilede produksjonen din.
En solid GDD kan også bidra til å lette nye teammedlemmer inn i prosjektet, og få dem like glade for det som du er.
Siden en fullstendig skissert GDD kan resultere i det som virker som et overdreven skremmende spill å lage, er det godt å huske at mer enn én person vil kaste ut sine detaljer. Ved å tilordne gruppemedlemsoppgaver i GDD vil det bli robustere samtidig som alle sammen holdes på samme side. Alle kan hoppe inn i dokumentet og se hva som er fullført, hvilke oppgaver lå foran dem og resten av teamet, og hvorfor de jobber med sin nåværende oppgave.
Skrive noe i en felles GDD bør ikke minimere eller eliminere diskusjon med teamet, det bør tjene til å øke gruppediskusjonen og forbedre kommunikasjonsdynamikken. Det er viktig at alle forstår klart hvordan du (og de andre lagmedlemmene) forestiller seg hver funksjon i spillet.
Skjære ideer kan være vanskelig og unnerving, men det er en prosess medfødt å skape spill. Å sørge for at åpen, fri diskusjon er en del av utviklingen, vil bidra til å lette de inneboende spenningene her, uten å fraråse medlemmer fra å være kreative.
Jeg fant mange gode ideer som nesten spilte spillet i tankene mine, både før og under spillets skapelse. Selvfølgelig gir dette ingen garanti for at disse ideene vil ta røtter i spillet under utvikling og testing, men spesielt i de tidlige stadier, er det en god metode for brainstorming.
Selv om det er bra å stimulere til en spenning i et lag, er det like viktig å holde dine spillmål innebygd i virkeligheten. Mekanikk og komplisert fiend og nivåoppførsel ser alltid bra ut på papir, men virkeligheten har en måte å korrodere storheten på visse spillelementer på, og dette bør forventes.
Konsekvenser av oppdateringer og endringer er nesten umulig å forutse før tid i noen situasjoner, så husk at det er jobben din å forsøke å begrense mengden remodeling som må gjøres når endringer oppstår. Hvis du gjør det vanlig å spille gjennom nye ideer i tankene dine før du legger dem på papir, står du i større grad for å holde utviklingsmålene rotet i realistiske forventninger.
Vårt team er multinasjonalt. Vi lever rundt i verden, i forskjellige tidszoner, og dette gjør det umulig å bruke utskriftsversjoner av dokumenter for alle, og det er vanskelig å ha sanntidssamtaler. Ved hjelp av verktøy som Skype (for samtaler), Google Disk (for å dele filer), kan Google Dokumenter (for samarbeid på dokumenter og deling av GDD) og FlockDraw (for digitale tegninger) virkelig hjelpe med forklaringer og diskusjoner.
Hvis du befinner deg på gjerdet om å opprettholde en GDD er nødvendig for spillets produksjon, bør du ta en god og hard titt på hvordan du tenker på utvikling. Det er nesten helt sikkert tider hvor ekte og heltidsjobber vil komme i veien for spillopptak, eller implementeringen av funksjoner og mekanikk virker enkelt ikke.
På de stormfulle havene i spillutvikling kan en sunn GDD tjene som en solid og solid fartøy, og til og med en livbåt til tider. Det er en detaljert journal over dine kamper og triumfer, en samling tanker og ideer for deg å falle tilbake i vanskelige tider. Det kan hende du synes at det å forbedre kvaliteten på GDD-trickles ned i resten av utviklingen også, øker linjen over bordet for teamet ditt. Det bør fungere som et solidt nav for å lette gruppediskusjon og generere nye, enda større ideer. Samtidig kan den holde disse konseptene i realistisk kontroll.
Fordelene ved denne typen effektivitet kan virke små når man ser på det individuelt, men i løpet av det lange utviklingsløpet, bygger det opp en fantastisk form for fart. Til slutt bør denne typen dokument drive, tvinge og inspirere deg og teamet ditt til å fullføre det du startet. Det skal vise deg at spillet ditt har en plan som kan realiseres.
Og etter at du er ferdig med spillet ditt, vil din GDD stå som et testament til alt ditt harde arbeid og innsats, bak-scenene til en forsiktig opplevelse som alle vil glede seg over..
Accentsconagua