# Mal for spilldesigndokument

Ni koblede dokumenter som dekker et spill fra pitchen til beslutningsloggen, hvert med veiledning om hva du skal skrive, og et kort eksempel. Last dem ned som Markdown-filer: de åpnes i alle editorer, viser diagrammene sine på GitHub og i Obsidian, og kan importeres i Nodary som et kart.

Gratis, uten konto og uten e-post. Bruk den, endre den, del den.

[Last ned malen (.zip)](https://nodary.ai/downloads/mal-for-spilldesigndokument.zip)

## Les hver side før du laster ned

Oversikten får plass på én skjerm og lenker til åtte deler, én per fagfelt, så hver del har en ansvarlig og en endring forblir liten. Kursive linjer sier hva du skal skrive; eksemplene kommer fra Saltmarrow, eksempelspillet denne nettsiden bruker overalt.

- Spilldesigndokument: Siden alle leser først: pitch, pilarer, målgruppe, omfang og en lenke til hver del.
- Gameplay: Hva spilleren gjør fra minutt til minutt, og hva som får spilleren til å fortsette.
- Systemer og økonomi: Hvert system, reglene det følger, ressursene det flytter og tallene bak.
- Verden, historie og karakterer: Settingen og reglene i den, historien spilleren opplever, og menneskene i den.
- Nivåer og innhold: Hvert sted spilleren besøker, den første timen, og hvor mye innhold lanseringen trenger.
- Kunstnerisk retning og lyd: Hvordan spillet ser ut og høres ut, presist nok til at to kunstnere som jobber hver for seg, likevel passer sammen.
- Grensesnitt og tilgjengelighet: Skjermbilder, HUD og input, og hvordan spillet tilpasser seg hver spiller.
- Teknisk design: Spillmotor, mål, arkitektur og pipeline, og grensene de setter for designet.
- Produksjonsplan: Milepæler, team, risikoer, og loggen over hver beslutning som endret designet.

### 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

| Felt | Ditt spill |
| --- | --- |
| Arbeidstittel | [Tittel] |
| Logline | [Én setning en fremmed kunne gjentatt] |
| Sjanger | [Sjanger og undersjanger] |
| Spillere | [Enspiller, co-op for 2 til 4, konkurransebasert] |
| Plattformer | [PC, konsoller, mobil] |
| Øktlengde | [En typisk økt, i minutter] |
| Spillmotor | [Spillmotor og versjon] |
| Team | [Størrelse i dag og på det største] |
| Forretningsmodell | [Pris, free-to-play, abonnement] |
| Neste milepæl | [Navn og dato] |

#### 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._

| Spill | Hva vi tar | Hva vi lar ligge |
| --- | --- | --- |
| [Spill] | [...] | [...] |
| [Spill] | [...] | [...] |
| [Spill] | [...] | [...] |

#### 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](https://nodary.ai/nb/templates/game-design-document#gdd-gameplay): kjerneløkken, mekanikkene, kontrollene og progresjonen
- [Systemer og økonomi](https://nodary.ai/nb/templates/game-design-document#gdd-systems): hvert system, reglene og tallene
- [Verden, historie og karakterer](https://nodary.ai/nb/templates/game-design-document#gdd-world): settingen, historien og menneskene i den
- [Nivåer og innhold](https://nodary.ai/nb/templates/game-design-document#gdd-levels): hvert sted, den første timen og innholdsbudsjettet
- [Kunstnerisk retning og lyd](https://nodary.ai/nb/templates/game-design-document#gdd-art): hvordan spillet ser ut og høres ut
- [Grensesnitt og tilgjengelighet](https://nodary.ai/nb/templates/game-design-document#gdd-interface): skjermbilder, HUD, input og tilgjengelighet
- [Teknisk design](https://nodary.ai/nb/templates/game-design-document#gdd-technical): spillmotor, mål, arkitektur og pipeline
- [Produksjonsplan](https://nodary.ai/nb/templates/game-design-document#gdd-production): milepæler, team, risikoer og beslutningsloggen

_Denne malen er gratis å bruke, endre og dele. Den kommer fra_ [Nodary](https://nodary.ai/nb)_, der disse filene kan importeres som et kart av koblede dokumenter._

### 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å._

```mermaid
flowchart LR
  n0["Planlegge"]
  n1["Utforske"]
  n2["Samle"]
  n3["Lage"]
  n4["Oppgradere"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
  n4 --> n0
```
_Kjerneløkken, omtrent [n] minutter per runde_

| Steg | Typisk tid | Spillerens spørsmål |
| --- | --- | --- |
| [Planlegge] | [2 min] | [Hvilket mål denne gangen, og hva tar jeg med?] |
| [Utforske] | [...] | [...] |
| [Samle] | [...] | [...] |

_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._

| Mekanikk | Hva spilleren gjør | Pilaren den tjener | Status |
| --- | --- | --- | --- |
| [Mekanikk] | [...] | [...] | [idé, prototype, låst] |
| [Mekanikk] | [...] | [...] | [...] |

#### Kontroller

_Spillerens verb og hvordan hvert av dem skal føles. Knappeoppsettet for hver enhet står i_ [Grensesnitt og tilgjengelighet](https://nodary.ai/nb/templates/game-design-document#gdd-interface).

- [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](https://nodary.ai/nb/templates/game-design-document#gdd-overview) · [Systemer og økonomi](https://nodary.ai/nb/templates/game-design-document#gdd-systems) · [Nivåer og innhold](https://nodary.ai/nb/templates/game-design-document#gdd-levels)

### 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._

| System | Hva det gjør | Leser fra | Mater inn i | Ansvarlig |
| --- | --- | --- | --- | --- |
| [Crafting] | [...] | [Inventar] | [Oppgraderinger] | [navn] |
| [System] | [...] | [...] | [...] | [...] |

_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._

| Ressurs | Kilder | Sluk | Tak |
| --- | --- | --- | --- |
| [Gull] | [...] | [...] | [ingen, eller et tall] |
| [Ressurs] | [...] | [...] | [...] |

#### 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](https://nodary.ai/nb/tools/drop-rate-calculator) _regner ut dette fra en tabell med vekter._

| Belønning | Vekt | Sjanse per forsøk | Garantert ved |
| --- | --- | --- | --- |
| [Gjenstand] | [...] | [...] | [ingen, eller forsøk n] |
| [Gjenstand] | [...] | [...] | [...] |

#### 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](https://nodary.ai/nb/templates/game-design-document#gdd-production).

| Spak | Nåværende verdi | Testet område | Påvirker |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |

#### Åpne spørsmål

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

Se også: [Gameplay](https://nodary.ai/nb/templates/game-design-document#gdd-gameplay) · [Nivåer og innhold](https://nodary.ai/nb/templates/game-design-document#gdd-levels) · [Produksjonsplan](https://nodary.ai/nb/templates/game-design-document#gdd-production)

### 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._

| Steg | Hva som skjer | Hvordan spilleren får vite det |
| --- | --- | --- |
| [Åpning] | [...] | [...] |
| [Vendepunkt] | [...] | [...] |
| [Slutt] | [...] | [...] |

#### Karakterer

| Karakter | Rolle i spillet | Hva de vil | Stemmen på én linje |
| --- | --- | --- | --- |
| [Navn] | [veileder, kjøpmann, rival] | [...] | [...] |
| [Navn] | [...] | [...] | [...] |

_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](https://nodary.ai/nb/templates/game-design-document#gdd-overview) · [Nivåer og innhold](https://nodary.ai/nb/templates/game-design-document#gdd-levels) · [Kunstnerisk retning og lyd](https://nodary.ai/nb/templates/game-design-document#gdd-art)

### 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

| Sted eller nivå | Formål i spillet | Hovedmekanikker | Lengde | Status |
| --- | --- | --- | --- | --- |
| [Opplæringsområde] | [lære bort bevegelse og kjerneløkken] | [...] | [10 min] | [blockout, grafikkrunde, ferdig] |
| [Sted] | [...] | [...] | [...] | [...] |

#### 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._

| Minutter | Hva spilleren gjør | Hva de lærer |
| --- | --- | --- |
| 0 til 5 | [...] | [...] |
| 5 til 15 | [...] | [...] |
| 15 til 60 | [...] | [...] |

#### Innholdsbudsjett

_Hvor mye av hver type innhold den første lanseringen trenger, og hvem som lager det. Sjekk det mot_ [produksjonsplanen](https://nodary.ai/nb/templates/game-design-document#gdd-production) _før noen begynner å bygge._

| Innhold | Antall | Laget av | Notater |
| --- | --- | --- | --- |
| [Nivåer eller områder] | [...] | [...] | [...] |
| [Karakterer og skapninger] | [...] | [...] | [...] |
| [Gjenstander] | [...] | [...] | [...] |
| [Dialogreplikker] | [...] | [...] | [...] |
| [Musikkspor] | [...] | [...] | [...] |

#### Åpne spørsmål

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

Se også: [Gameplay](https://nodary.ai/nb/templates/game-design-document#gdd-gameplay) · [Verden, historie og karakterer](https://nodary.ai/nb/templates/game-design-document#gdd-world) · [Produksjonsplan](https://nodary.ai/nb/templates/game-design-document#gdd-production)

### 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»._

| Referanse | Hva vi tar | Hva vi unngår |
| --- | --- | --- |
| [Bilde eller spill] | [...] | [...] |
| [Bilde eller spill] | [...] | [...] |

#### Palett

| Bruk | Farge | Notater |
| --- | --- | --- |
| [Bakgrunn] | [#hex] | [...] |
| [Fare] | [#hex] | [aldri den eneste måten fare vises på] |

#### Asset-familier

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

| Familie | Stilnotater | Budsjett | Godkjent av |
| --- | --- | --- | --- |
| [Karakterer] | [...] | [...] | [...] |
| [Miljøer] | [...] | [...] | [...] |
| [Rekvisitter] | [...] | [...] | [...] |
| [Effekter] | [...] | [...] | [...] |

#### 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](https://nodary.ai/nb/templates/game-design-document#gdd-world) · [Grensesnitt og tilgjengelighet](https://nodary.ai/nb/templates/game-design-document#gdd-interface)

### 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._

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

#### 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._

| Element | Viser | Når det er synlig | Prioritet |
| --- | --- | --- | --- |
| [Helse] | [...] | [alltid, i kamp, på forespørsel] | [høy, middels, lav] |
| [Element] | [...] | [...] | [...] |

#### Input

| Handling | Tastatur og mus | Håndkontroll | Berøring |
| --- | --- | --- | --- |
| [Bevege seg] | [WASD] | [Venstre stikke] | [...] |
| [Interagere] | [E] | [A / Kryss] | [...] |
| [Pause] | [Esc] | [Start / Options] | [...] |

#### 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](https://nodary.ai/nb/templates/game-design-document#gdd-gameplay) · [Kunstnerisk retning og lyd](https://nodary.ai/nb/templates/game-design-document#gdd-art) · [Teknisk design](https://nodary.ai/nb/templates/game-design-document#gdd-technical)

### 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

| Valg | Beslutning | Hvorfor |
| --- | --- | --- |
| Spillmotor | [Spillmotor og versjon] | [...] |
| Programmeringsspråk | [...] | [...] |
| Versjonskontroll | [...] | [...] |
| Bygg og distribusjon | [...] | [...] |

#### Mål og budsjetter

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

| Plattform | Bildefrekvens | Oppløsning | Minne | Lastetid | Installasjonsstørrelse |
| --- | --- | --- | --- | --- | --- |
| [PC, minstekrav] | [...] | [...] | [...] | [...] | [...] |
| [Konsoll] | [...] | [...] | [...] | [...] | [...] |

#### Arkitektur

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

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

#### 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

| Risiko | Konsekvens | Hva vi gjør med det | Ansvarlig |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |

#### Åpne spørsmål

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

Se også: [Grensesnitt og tilgjengelighet](https://nodary.ai/nb/templates/game-design-document#gdd-interface) · [Produksjonsplan](https://nodary.ai/nb/templates/game-design-document#gdd-production)

### 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

| Milepæl | Dato | Mål | Ferdig når |
| --- | --- | --- | --- |
| [Prototype] | [...] | [kjerneløkken er morsom] | [...] |
| [Vertical slice] | [...] | [ett nivå i endelig kvalitet] | [...] |
| [Alpha] | [...] | [alle funksjoner på plass, grovt] | [...] |
| [Beta] | [...] | [alt innhold på plass, bare feilretting] | [...] |
| [Lansering] | [...] | [...] | [...] |

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

#### Team

| Rolle | Person | Eier disse dokumentene |
| --- | --- | --- |
| [Kreativ leder] | [navn] | [Spilldesigndokument, Gameplay] |
| [Rolle] | [navn] | [...] |

#### Risikoer

| Risiko | Sannsynlighet | Konsekvens | Hva vi gjør med det | Ansvarlig |
| --- | --- | --- | --- | --- |
| [...] | [lav, middels, høy] | [lav, middels, høy] | [...] | [...] |

#### 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._

| Dato | Beslutning | Bestemt av | Hvorfor | Endret dokument |
| --- | --- | --- | --- | --- |
| [dato] | [...] | [...] | [...] | [...] |

_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](https://nodary.ai/nb/templates/game-design-document#gdd-overview) · [Nivåer og innhold](https://nodary.ai/nb/templates/game-design-document#gdd-levels) · [Teknisk design](https://nodary.ai/nb/templates/game-design-document#gdd-technical)

## Slik bruker du malen

### Skriv oversikten i én økt

Fyll ut tabellen, pitchen og pilarene først, på omtrent en time, sammen med dem som skal lage spillet. Alle andre sider måles mot dem.

### Fyll ut delene etter hvert som beslutningene tas

La heller en seksjon stå tom enn å finne på noe. En tom seksjon er et ærlig åpent spørsmål; en oppdiktet seksjon blir bygget.

### Loggfør hver beslutning

Når en beslutning endrer designet, legger du til en linje i beslutningsloggen i produksjonsplanen og oppdaterer siden den gjelder. Loggen sier hvorfor; siden sier hva som gjelder nå.

### Gi hver side en ansvarlig

Hver del oppgir hvem som er ansvarlig, og når den sist ble gjennomgått. En side ingen eier, er den første som blir utdatert.

## Importer malen i Nodary som et kart

Nodary er et arbeidsområde for spillteam der dokumentene er koblet sammen som stjerner på et kart. Importer .zip-filen, så kommer oversikten med de åtte delene lagt under seg, koblingene mellom sidene bevart og diagrammene tegnet. Deretter kommenterer teamet ditt avsnitt, ber om gjennomganger og ser hva som er endret siden sist, og KI-agenter koblet til via MCP leser designet før de skriver i det.

1. Åpne kartet til et prosjekt og velg «Importer».
2. Velg fanen «Mappe eller ZIP», og deretter «Velg en ZIP-fil».
3. Velg den nedlastede filen, sjekk trestrukturen og importer.

Gratisplanen rommer ti dokumenter per arbeidsområde, prosjektets egen side medregnet: malens ni dokumenter passer i et nytt arbeidsområde og fyller det. Betalte planer har plass til flere.

## Skriv et GDD folk faktisk leser

Et spilldesigndokument svikter på én av to måter: ingen leser det, eller alle leser en gammel versjon. Disse vanene hindrer begge deler.

### Én side per del

En fil på seksti sider blir lest én gang, i starten. Korte, koblede sider blir lest når det betyr noe, og en endring berører én side i stedet for fem.

### Skriv beslutninger, ikke ønsker

«Kampene skal føles bra» avgjør ingenting. «Et treff lander innen 100 millisekunder etter knappetrykket» kan bygges og testes.

### Si hva som fortsatt er åpent

Merk ubesvarte spørsmål som åpne, med hvem som svarer og innen når. En gjetning skrevet som et faktum er slik to avdelinger ender opp med å lage to forskjellige spill.

### Lenk, aldri kopier

Når økonomisiden trenger tidevannskalenderen, lenker den til den. Et faktum som står to steder, sier snart to forskjellige ting.

### Ta vare på hvorfor

Beslutningsloggen viser hvorfor ting er som de er, så et nytt teammedlem ikke omgjør et valg teamet allerede har betalt for.

### Kutt det ingen leser

Hvis en seksjon ikke er åpnet siden den ble skrevet, slå den sammen med en annen eller slett den. Et kort dokument som stemmer, slår et langt som en gang gjorde det.

## Spørsmål om spilldesigndokumenter

### Hva er et spilldesigndokument?

Et spilldesigndokument, eller GDD, beskriver spillet et team lager: pitch, pilarer, mekanikker, systemer, verden, nivåer, grafikk og lyd, og planen for å lage det. Design, grafikk, kode, produksjon og, i stadig større grad, KI-agenter leser det, så det må holdes oppdatert mens spillet endrer seg.

### Hva bør et spilldesigndokument inneholde?

Minst en oversikt på én side med pitch, pilarer, målgruppe og omfang; gameplay og kjerneløkken; systemene og tallene deres; verden og historie; nivåer og innhold; kunstnerisk retning og lyd; grensesnitt og tilgjengelighet; de tekniske rammene; og en produksjonsplan med beslutningslogg. Denne malen har ett dokument for hver av dem.

### Hvor langt bør et GDD være?

Så kort som mulig, så lenge det fortsatt svarer på teamets spørsmål. Oversikten bør få plass på én skjerm. Hver del vokser med beslutningene som tas, ikke med forhåpningene: én side med avklarte regler slår ti sider med muligheter.

### Trenger indie- og smidige team fortsatt et GDD?

De trenger beslutningene skrevet ned, ikke en bibel skrevet på forhånd. Team som itererer raskt, bruker GDD-et som en oversikt over hva spillet er i dag: korte sider, oppdatert når en spilltest endrer noe, med begrunnelsene i beslutningsloggen.

### Hvilket format har malen?

Markdown: rene tekstfiler som alle editorer åpner. Lenker mellom dokumentene er relative lenker, tabeller er Markdown-tabeller, og diagrammene er skrevet i Mermaid, som GitHub, Obsidian og Nodary tegner. Ingenting avhenger av ett bestemt verktøy.

### Kan jeg bruke malen i Obsidian, på GitHub eller i en annen editor?

Ja. Obsidian åpner den utpakkede mappen som et hvelv der alle lenkene virker, og GitHub viser filene med lenker og diagrammer. Verktøy som importerer Markdown én fil om gangen, beholder teksten og tabellene; sjekk hvordan de håndterer lenker mellom filer.

### Hvordan importerer jeg malen i Nodary?

Åpne kartet til et prosjekt, velg «Importer», deretter fanen «Mappe eller ZIP», og velg den nedlastede .zip-filen. Nodary viser først trestrukturen, oppretter så de ni dokumentene med oversikten som overordnet dokument, beholder lenkene mellom dem og tegner diagrammene. Enhver mappe eller .zip med opptil 200 Markdown-filer importeres på samme måte.

### Kan jeg bruke malen til et kommersielt spill?

Ja. Bruk den, endre den og del den til ethvert spill, kommersielt eller ikke, med eller uten Nodary-konto. Nevner du oss, setter vi pris på det, men det er aldri et krav.

Siden: https://nodary.ai/nb/templates/game-design-document