Mal for spilldesigndokument

Fil Mal for spilldesigndokument/Spilldesigndokument.md

Spilldesigndokument

Slik bruker du malen: kursive linjer er veiledning. Bytt dem ut med dine egne ord, og slett dem deretter. Verdier i hakeparentes fyller du inn selv. Hold denne siden på omtrent én skjerm: det er siden alle leser først, og alle andre deler av designet er én lenke unna.

Kort fortalt

Pitch

To eller tre setninger: hvem som spiller, hva de gjør, og hva som gjør spillet annerledes. Skriv den slik at den også ville fungert på en butikkside.

Eksempel (Saltmarrow, et eksempelspill): Rak salt, dykk etter minner, rekk hjem før tidevannet. Et samarbeidsspill om utforsking og crafting for opptil fire spillere, lagt til saltflater i tidevannssonen der en druknet arkivby kommer til syne to ganger om dagen.

[Din pitch]

Designpilarer

Tre til fem regler som hver funksjon må tjene. En pilar som kunne beskrevet et hvilket som helst spill, som «morsom kamp», er ingen pilar. En funksjon som ikke tjener noen pilar, kuttes; en funksjon som bryter en pilar, designes på nytt.

1. [Første pilar]: [hva den betyr, i én setning]
2. [Andre pilar]: [hva den betyr, i én setning]
3. [Tredje pilar]: [hva den betyr, i én setning]

Eksempel (Saltmarrow, et eksempelspill): Tidevannet er klokken. Tid er den eneste ressursen som aldri vokser: hvert system leser tidevannet, og ingenting setter det på pause.

Målgruppe

Hvem spillet er for, hva de spiller i dag, og når de slutter å spille. Nevn ekte spill og ekte vaner, ikke bare en aldersgruppe.

• Primærspillere: [hvem de er og hvordan de spiller]
• Hva de spiller i dag: [tre eller fire spill]
• De slutter å spille når: [...]
• Sekundærspillere: [...]

Sammenlignbare spill

Tre eller fire spill som teamet og spillerne dine allerede kjenner. Si hva dere tar fra hvert av dem og, like nyttig, hva dere lar ligge.

Omfang

Hva den første lanseringen inneholder, og hva den uttrykkelig ikke inneholder. Det er den andre listen som hindrer omfanget i å vokse i det stille.

• I første lansering: [...]
• Ikke i første lansering: [...]
• Avgjøres senere: [...]

Resten av designet

Hver del er sitt eget dokument. Lenk til den i stedet for å kopiere fra den, så hvert faktum bor ett sted og endres ett sted.

• Gameplay: kjerneløkken, mekanikkene, kontrollene og progresjonen
• Systemer og økonomi: hvert system, reglene og tallene
• Verden, historie og karakterer: settingen, historien og menneskene i den
• Nivåer og innhold: hvert sted, den første timen og innholdsbudsjettet
• Kunstnerisk retning og lyd: hvordan spillet ser ut og høres ut
• Grensesnitt og tilgjengelighet: skjermbilder, HUD, input og tilgjengelighet
• Teknisk design: spillmotor, mål, arkitektur og pipeline
• Produksjonsplan: milepæler, team, risikoer og beslutningsloggen

Denne malen er gratis å bruke, endre og dele. Den kommer fra Nodary, der disse filene kan importeres som et kart av koblede dokumenter.

Fil Mal for spilldesigndokument/Spilldesigndokument/01 Gameplay.md

Gameplay

Ansvarlig: [navn] · Status: utkast · Sist gjennomgått: [dato]

Hva spilleren gjør fra minutt til minutt, og hva som får spilleren til å fortsette. Start med løkken: alt annet i dette dokumentet henger på den.

Kjerneløkke

Løkken spilleren gjentar mest, i fire til seks verb. Hvis teamet ikke kan tegne den, er den ikke avklart ennå.

flowchart LR
  n0["Planlegge"]
  n1["Utforske"]
  n2["Samle"]
  n3["Lage"]
  n4["Oppgradere"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
  n4 --> n0

Eksempel (Saltmarrow, et eksempelspill): Høste eller dykke, 8 til 14 minutter: rake trygt salt, eller dykke etter krystaller som kanskje er verdt mer? Hvert steg bør stille spilleren et spørsmål. Et steg uten et spørsmål er bare et ork.

Mekanikker

Én rad per mekanikk. Pilarkolonnen holder hver av dem ærlig: en mekanikk som ikke tjener noen pilar, havner på kuttlisten.

Kontroller

Spillerens verb og hvordan hvert av dem skal føles. Knappeoppsettet for hver enhet står i Grensesnitt og tilgjengelighet.

• [Verb]: [hvordan det utføres, og hvordan det skal føles]
• [Verb]: [...]

Progresjon

Hva som vokser i løpet av en økt og gjennom hele spillet, og hvordan spilleren ser det vokse. Navngi det langsiktige målet.

• I løpet av en økt: [...]
• Fra økt til økt: [...]
• Langsiktig mål: [...]

Utfordring og nederlag

Hvordan vanskelighetsgraden stiger, hva det koster å mislykkes, og hvordan spilleren kommer inn igjen. Et nederlag som bare koster tid, lærer bort mindre enn et som koster et valg.

• Vanskelighetsgraden stiger gjennom: [...]
• Å mislykkes koster: [...]
• Tilbake i spillet: [...]

Eksempel (Saltmarrow, et eksempelspill): En dykker som fortsatt er i arkivet når hornet lyder, mister krystallene i vesken og kommer opp ved nærmeste tårn, men beholder saltet sitt.

Åpne spørsmål

• [Spørsmål], [hvem som svarer], [innen når]

Se også: Spilldesigndokument · Systemer og økonomi · Nivåer og innhold

Fil Mal for spilldesigndokument/Spilldesigndokument/02 Systemer og økonomi.md

Systemer og økonomi

Ansvarlig: [navn] · Status: utkast · Sist gjennomgått: [dato]

Hvert system i spillet, reglene det følger og tallene bak. Tallene endrer seg hver uke: hold dem i tabeller eller regneark, og hold begrunnelsen her.

Systemer

Én rad per system. Et system som ikke mater noe, er pynt. Et system som alt mater inn i, er ryggraden i spillet ditt og fortjener et eget dokument.

Eksempel (Saltmarrow, et eksempelspill): Hvert system leser tidevannet: høsteutbytte, stormsjanser, prisene i landsbyen, til og med hvor lenge en karakter gidder å prate.

Ressurser og valutaer

For hver ressurs: hvor den kommer fra (kilder) og hvor den forsvinner (sluk). En økonomi med flere kilder enn sluk får inflasjon: fyll ut begge kolonnene før du justerer noe.

Belønninger og dropprater

Byttetabeller, belønningssjanser og eventuelle pity-regler. Si hva en spiller kan forvente: hvor mange forsøk før halvparten av spillerne har en gjenstand, og før ni av ti har den. Den gratis dropprate-kalkulatoren regner ut dette fra en tabell med vekter.

Balanseringsspaker

De få verdiene en designer endrer for å gjøre spillet lettere, raskere eller rausere, med nåværende verdi og området som allerede er testet. Når én endres, noter hvorfor i beslutningsloggen i produksjonsplanen.

Åpne spørsmål

• [Spørsmål], [hvem som svarer], [innen når]

Se også: Gameplay · Nivåer og innhold · Produksjonsplan

Fil Mal for spilldesigndokument/Spilldesigndokument/03 Verden, historie og karakterer.md

Verden, historie og karakterer

Ansvarlig: [navn] · Status: utkast · Sist gjennomgått: [dato]

Verdens regler, historien spilleren opplever, og menneskene i den. Lore som aldri når spilleren, hører hjemme i egne dokumenter, lenket herfra.

Setting

Hvor og når, i tre setninger, og den ene regelen i denne verdenen som spilleren merker i spillet.

Eksempel (Saltmarrow, et eksempelspill): En biblioteksby som prøvde å overleve havet ved å dyrke salt. Det virket: saltet bevarte bøkene og druknet leserne. To ganger om dagen trekker tidevannet seg tilbake og avdekker den.

[Din setting]

Tone

Tre ord, hvert med et spill, en film eller en bok som setter listen. Deretter hva tonen ikke er: det avgjør flere diskusjoner enn hva den er.

• Tone: [...]
• Referanser: [...]
• Aldri: [...]

Historien i grove trekk

Historien slik spilleren opplever den, steg for steg, ikke forhistorien. Noter hvordan hvert steg når spilleren: en mellomsekvens, en replikk, en gjenstand som blir funnet, selve nivået.

Karakterer

Når en karakter har mer enn noen få replikker, gi den et eget dokument (en profil, referanser, eksempeldialog) og lenk til det fra denne tabellen.

Skriveregler

Konvensjonene alle som skriver, følger: navn og stavemåter, ord denne verdenen aldri bruker, den lengste replikken som får plass på skjermen. Skrevet tidlig sparer de lokaliseringsteamet for uker.

• [Regel]
• [Regel]

Åpne spørsmål

• [Spørsmål], [hvem som svarer], [innen når]

Se også: Spilldesigndokument · Nivåer og innhold · Kunstnerisk retning og lyd

Fil Mal for spilldesigndokument/Spilldesigndokument/04 Nivåer og innhold.md

Nivåer og innhold

Ansvarlig: [navn] · Status: utkast · Sist gjennomgått: [dato]

Hvert sted spilleren besøker og hver bit innhold spillet trenger, med antall av hvert. Denne listen blir produksjonens backlog, så hold tallene ærlige.

Steder og nivåer

Regler for nivådesign

Regler som gjelder i hvert nivå: hvordan spilleren ledes, hvor langt det er mellom sjekkpunktene, hvordan hemmeligheter signaliseres. Skriv dem én gang her i stedet for i hvert nivå.

• [Regel]
• [Regel]

Den første timen

Spillerens første time, steg for steg: hva de gjør, hva de lærer, og det første øyeblikket de ville fortalt en venn om. De fleste spillere som gir opp, gir opp her.

Innholdsbudsjett

Hvor mye av hver type innhold den første lanseringen trenger, og hvem som lager det. Sjekk det mot produksjonsplanen før noen begynner å bygge.

Åpne spørsmål

• [Spørsmål], [hvem som svarer], [innen når]

Se også: Gameplay · Verden, historie og karakterer · Produksjonsplan

Fil Mal for spilldesigndokument/Spilldesigndokument/05 Kunstnerisk retning og lyd.md

Kunstnerisk retning og lyd

Ansvarlig: [navn] · Status: utkast · Sist gjennomgått: [dato]

Hvordan spillet ser ut og høres ut, beskrevet presist nok til at to kunstnere som jobber hver for seg, lager arbeid som passer sammen.

Visuelle regler

Tre til fem regler om form, farge, lys og detaljer. «Stilisert» er ingen regel; «hver silhuett kan leses på tretti meters avstand» er det.

• [Regel]
• [Regel]
• [Regel]

Referanser

Legg til referansebilder under hver regel, og si hva dere skal ta fra hvert av dem: paletten, lyset, formene. Aldri «alt».

Palett

Asset-familier

Hva hver asset-familie har til felles, budsjettet (polygoner, teksturstørrelse, animasjonsrammer) og hvem som godkjenner den.

Lyd

Stemningen i musikken, lydeffektene og stemmene, og spillinformasjonen lyden bærer: advarsler, belønninger, tiden som går.

• Musikk: [...]
• Lydeffekter: [...]
• Stemmer: [språk og antall replikker, eller ingen]
• Informasjon som bæres av lyd: [...]

Eksempel (Saltmarrow, et eksempelspill): To minutter før tidevannet snur, lyder et horn over saltflatene. Tidevannet vises på skjermen, høres i miksen og kjennes i håndkontrollen.

Gjennomganger

Hvem som godkjenner grafikk og lyd, og når. Hold tilbakemeldingene på selve bildet, festet til stedet de gjelder: det sparer en runde med «hvilken, den til venstre?»

• Grafikk godkjennes av: [...]
• Lyd godkjennes av: [...]

Åpne spørsmål

• [Spørsmål], [hvem som svarer], [innen når]

Se også: Verden, historie og karakterer · Grensesnitt og tilgjengelighet

Fil Mal for spilldesigndokument/Spilldesigndokument/06 Grensesnitt og tilgjengelighet.md

Grensesnitt og tilgjengelighet

Ansvarlig: [navn] · Status: utkast · Sist gjennomgått: [dato]

Alt spilleren leser, trykker på og navigerer i, og hvordan spillet tilpasser seg spillere som ser, hører eller beveger seg annerledes.

Skjermbilder og flyt

Hvert skjermbilde, og hvordan spilleren beveger seg mellom dem fra oppstart til avslutning. Et diagram finner blindveiene før de blir bygget.

flowchart LR
  n0["Tittelskjerm"]
  n1["Hovedmeny"]
  n2["Spill"]
  n3["Innstillinger"]
  n4["Pause"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n2 --> n4
  n4 --> n2
  n4 --> n1

HUD

Hva som blir værende på skjermen mens man spiller, og hvorfor hvert element fortjener plassen sin. Alt spilleren sjekker sjeldnere enn én gang i minuttet, kan ligge i en meny.

Input

Tilgjengelighet

Kryss av hvert punkt, eller skriv hvorfor det ikke gjelder. Bestemt tidlig koster de fleste lite; lagt til sent koster de mye.

• Alle kontroller kan tilordnes på nytt
• Handlinger der en knapp må holdes inne, kan gjøres om til av/på
• Undertekster viser hvem som snakker, og størrelsen kan endres
• Viktige lyder har også et visuelt signal
• Ingen informasjon formidles bare med farge
• Teksten kan gjøres større
• Tidtakere kan gå saktere eller slås av
• Kamerarystelser og blinking kan reduseres

Tekst og språk

Språkene ved lansering, og reglene som gjør oversettelse mulig: ingen tekst bakt inn i bilder, plass til tekst som er opptil en tredjedel lengre enn engelsk, og skrifttyper som dekker alle skriftsystemene dere leverer på.

• Språk ved lansering: [...]
• Språk senere: [...]
• Skrifttyper: [...]

Åpne spørsmål

• [Spørsmål], [hvem som svarer], [innen når]

Se også: Gameplay · Kunstnerisk retning og lyd · Teknisk design

Fil Mal for spilldesigndokument/Spilldesigndokument/07 Teknisk design.md

Teknisk design

Ansvarlig: [navn] · Status: utkast · Sist gjennomgått: [dato]

De tekniske valgene som former designet, og grensene designet må respektere. Detaljert arkitektur kan ligge i tekniske dokumenter lenket herfra.

Spillmotor og verktøy

Mål og budsjetter

Tallene hver avdeling bygger mot. Uten dem oppdages ytelsesproblemene først på slutten.

Arkitektur

Hoveddelene av spillets kode og hvordan de snakker med hverandre. Et diagram med fem bokser slår fem sider med prosa.

flowchart TD
  n0["Input"]
  n1["Spilltilstand"]
  n2["Rendering"]
  n3["Lyd"]
  n4["Lagring"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n1 --> n4

Lagring og nett

• Lagring: [hva som lagres, når og hvor]
• Nett: [ingen, peer-to-peer, dedikerte servere]
• Spillerdata: [hva som samles inn, og hvor det oppbevares]

Pipeline

Hvordan en asset eller en tekstlinje går fra den som lagde den til et spillbart bygg, og hvor lang tid det tar. En treg pipeline kutter i det stille antall iterasjoner et team får.

[Din pipeline]

Tekniske risikoer

Åpne spørsmål

• [Spørsmål], [hvem som svarer], [innen når]

Se også: Grensesnitt og tilgjengelighet · Produksjonsplan

Fil Mal for spilldesigndokument/Spilldesigndokument/08 Produksjonsplan.md

Produksjonsplan

Ansvarlig: [navn] · Status: utkast · Sist gjennomgått: [dato]

Når spillet lanseres, hvem som lager det, hva som kan stoppe det, og hver beslutning som tas underveis.

Milepæler

«Ferdig når» er kolonnen folk hopper over. Uten den er en milepæl bare en dato.

Team

Risikoer

Beslutningslogg

Hver beslutning som endrer designet: hva som ble bestemt, av hvem, hvorfor, og hvilket dokument som ble endret. Når noen om seks måneder spør hvorfor det fungerer slik, svarer denne tabellen.

Eksempel (Saltmarrow, et eksempelspill): 12. september: ingen kamp, trusselen kommer bare fra tidevannet og stormene. Bestemt av kreativ leder og systemdesigneren, for å holde spillet rolig og tidsplanen stram. Endret dokument: designpilarene.

Åpne spørsmål

• [Spørsmål], [hvem som svarer], [innen når]

Se også: Spilldesigndokument · Nivåer og innhold · Teknisk design