Mall för speldesigndokument

Fil Mall för speldesigndokument/Speldesigndokument.md

Speldesigndokument

Så använder du mallen: kursiva rader är vägledning. Ersätt dem med dina egna ord och ta sedan bort dem. Värden inom hakparentes fyller du i själv. Håll den här sidan till ungefär en skärm: det är sidan alla läser först, och alla andra delar av designen ligger en länk bort.

I korthet

Pitch

Två eller tre meningar: vem spelaren är, vad hen gör och vad som gör spelet annorlunda. Skriv den så att den skulle fungera även på en butikssida.

Exempel (Saltmarrow, ett exempelspel): Kratta salt, dyk efter minnen, hinn hem före tidvattnet. Ett co-op-spel om utforskning och crafting för upp till fyra spelare, på saltslätter där en dränkt arkivstad stiger ur havet två gånger om dagen.

[Din pitch]

Designpelare

Tre till fem regler som varje funktion måste tjäna. En pelare som skulle kunna beskriva vilket spel som helst, som ”rolig strid”, är ingen pelare. En funktion som inte tjänar någon pelare stryks; en funktion som bryter mot en pelare görs om.

1. [Pelare ett]: [vad den betyder, i en mening]
2. [Pelare två]: [vad den betyder, i en mening]
3. [Pelare tre]: [vad den betyder, i en mening]

Exempel (Saltmarrow, ett exempelspel): Tidvattnet är klockan. Tid är den enda resurs som aldrig växer: varje system läser av tidvattnet, och ingenting pausar det.

Målgrupp

Vilka spelet är för, vad de spelar i dag och när de slutar spela. Nämn riktiga spel och riktiga vanor, inte bara ett åldersspann.

• Primära spelare: [vilka de är och hur de spelar]
• Det här spelar de i dag: [tre eller fyra spel]
• De slutar spela när: [...]
• Sekundära spelare: [...]

Jämförbara spel

Tre eller fyra spel som ditt team och dina spelare redan känner till. Säg vad ni tar från vart och ett och, lika användbart, vad ni lämnar.

Omfattning

Vad den första releasen innehåller, och vad den uttryckligen inte innehåller. Det är den andra listan som hindrar omfattningen från att växa i det tysta.

• I första releasen: [...]
• Inte i första releasen: [...]
• Avgörs senare: [...]

Resten av designen

Varje del är ett eget dokument. Länka till det i stället för att kopiera från det, så att varje faktum finns på ett ställe och ändras på ett ställe.

• Gameplay: kärnloopen, mekanikerna, kontrollerna och progressionen
• System och ekonomi: varje system, dess regler och dess siffror
• Värld, berättelse och karaktärer: miljön, berättelsen och människorna i den
• Banor och innehåll: varje plats, den första timmen och innehållsbudgeten
• Konstnärlig ledning och ljud: hur spelet ser ut och låter
• Gränssnitt och tillgänglighet: skärmar, HUD, input och tillgänglighet
• Teknisk design: motor, målplattformar, arkitektur och pipeline
• Produktionsplan: milstolpar, team, risker och beslutsloggen

Mallen är fri att använda, ändra och dela. Den kommer från Nodary, där filerna importeras som en karta av länkade dokument.

Fil Mall för speldesigndokument/Speldesigndokument/01 Gameplay.md

Gameplay

Ägare: [namn] · Status: utkast · Senast granskad: [datum]

Vad spelaren gör från en minut till nästa, och varför hen fortsätter. Börja med loopen: allt annat i dokumentet hänger på den.

Kärnloop

Den loop spelaren upprepar mest, i fyra till sex verb. Om teamet inte kan rita den är den inte fastslagen än.

flowchart LR
  n0["Planera"]
  n1["Utforska"]
  n2["Samla"]
  n3["Tillverka"]
  n4["Uppgradera"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
  n4 --> n0

Exempel (Saltmarrow, ett exempelspel): Skörda eller dyka, 8 till 14 minuter: kratta salt utan risk, eller dyka efter kristaller som kanske är värda mer? Varje moment ska ställa spelaren inför en fråga. Ett moment utan fråga är bara rutinarbete.

Mekaniker

En rad per mekanik. Pelarkolumnen håller varje mekanik ärlig: en mekanik som inte tjänar någon pelare hamnar på strykningslistan.

Kontroller

Spelarens verb och hur vart och ett ska kännas. Knapplayouten för varje enhet finns i Gränssnitt och tillgänglighet.

• [Verb]: [hur det utförs och hur det ska kännas]
• [Verb]: [...]

Progression

Vad som växer under en session och över hela spelet, och hur spelaren ser det växa. Namnge det långsiktiga målet.

• Under en session: [...]
• Mellan sessioner: [...]
• Långsiktigt mål: [...]

Utmaning och misslyckande

Hur svårigheten ökar, vad ett misslyckande kostar och hur spelaren kommer tillbaka in. Ett misslyckande som bara kostar tid lär ut mindre än ett som kostar ett val.

• Svårigheten ökar genom: [...]
• Ett misslyckande kostar: [...]
• Så kommer spelaren tillbaka: [...]

Exempel (Saltmarrow, ett exempelspel): En dykare som fortfarande är kvar i arkivet när hornet ljuder förlorar kristallerna i väskan och kommer upp vid närmaste torn, men behåller sitt salt.

Öppna frågor

• [Fråga], [vem som besvarar den], [senast när]

Se även: Speldesigndokument · System och ekonomi · Banor och innehåll

Fil Mall för speldesigndokument/Speldesigndokument/02 System och ekonomi.md

System och ekonomi

Ägare: [namn] · Status: utkast · Senast granskad: [datum]

Varje system i spelet, reglerna det följer och siffrorna bakom det. Siffrorna ändras varje vecka: håll dem i tabeller eller kalkylblad, och håll resonemanget här.

System

En rad per system. Ett system som inte matar något är dekoration. Ett system som allt annat matar in i är spelets ryggrad och förtjänar ett eget dokument.

Exempel (Saltmarrow, ett exempelspel): Varje system läser av tidvattnet: skördens avkastning, risken för storm, priserna i byn, till och med hur länge en karaktär orkar prata.

Resurser och valutor

För varje resurs: varifrån den kommer (källor) och vart den tar vägen (sänkor). En ekonomi med fler källor än sänkor drabbas av inflation: fyll i båda kolumnerna innan du balanserar något.

Belöningar och dropchanser

Loot-tabeller, belöningschanser och eventuell garantiregel (pity). Säg vad en spelare kan förvänta sig: hur många försök det tar tills hälften av spelarna har ett föremål, och tills nio av tio har det. Den kostnadsfria kalkylatorn för dropchanser räknar ut det från en tabell med vikter.

Balanseringsreglage

De få värden en designer ändrar för att göra spelet lättare, snabbare eller generösare, med nuvarande värde och det intervall som redan testats. När ett av dem ändras, notera varför i beslutsloggen i produktionsplanen.

Öppna frågor

• [Fråga], [vem som besvarar den], [senast när]

Se även: Gameplay · Banor och innehåll · Produktionsplan

Fil Mall för speldesigndokument/Speldesigndokument/03 Värld, berättelse och karaktärer.md

Värld, berättelse och karaktärer

Ägare: [namn] · Status: utkast · Senast granskad: [datum]

Världens regler, berättelsen spelaren upplever och människorna i den. Lore som aldrig når spelaren hör hemma i egna dokument, länkade härifrån.

Miljö

Var och när, i tre meningar, och den enda regel i världen som spelaren känner av när hen spelar.

Exempel (Saltmarrow, ett exempelspel): En biblioteksstad som försökte överleva havet genom att odla salt. Det fungerade: saltet bevarade böckerna och dränkte läsarna. Två gånger om dagen blottar tidvattnet den.

[Din miljö]

Ton

Tre ord, vart och ett med ett spel, en film eller en bok som sätter ribban. Sedan vad tonen inte är: det avgör fler diskussioner än vad den är.

• Ton: [...]
• Referenser: [...]
• Aldrig: [...]

Handlingen i stora drag

Berättelsen så som spelaren upplever den, moment för moment, inte bakgrundshistorien. Notera hur varje moment når spelaren: en mellansekvens, en replik, ett föremål hen hittar, själva banan.

Karaktärer

När en karaktär har mer än några repliker, ge hen ett eget dokument (en profil, referenser, exempeldialog) och länka det från tabellen.

Skrivregler

Konventionerna varje skribent följer: namn och stavningar, ord som den här världen aldrig använder, den längsta repliken som ryms på skärmen. Skrivna tidigt sparar de veckor åt lokaliseringsteamet.

• [Regel]
• [Regel]

Öppna frågor

• [Fråga], [vem som besvarar den], [senast när]

Se även: Speldesigndokument · Banor och innehåll · Konstnärlig ledning och ljud

Fil Mall för speldesigndokument/Speldesigndokument/04 Banor och innehåll.md

Banor och innehåll

Ägare: [namn] · Status: utkast · Senast granskad: [datum]

Varje plats spelaren besöker och allt innehåll spelet behöver, med hur mycket av varje. Listan blir produktionens backlog, så håll siffrorna ärliga.

Platser och banor

Regler för level design

Regler som gäller i varje bana: hur spelaren vägleds, hur långt det är mellan checkpoints, hur hemligheter signaleras. Skriv dem en gång här i stället för i varje bana.

• [Regel]
• [Regel]

Den första timmen

Spelarens första timme, steg för steg: vad hen gör, vad hen lär sig och det första ögonblick hen skulle berätta om för en vän. De flesta spelare som slutar, slutar här.

Innehållsbudget

Hur mycket av varje slags innehåll den första releasen behöver, och vem som gör det. Stäm av budgeten mot produktionsplanen innan någon börjar bygga.

Öppna frågor

• [Fråga], [vem som besvarar den], [senast när]

Se även: Gameplay · Värld, berättelse och karaktärer · Produktionsplan

Fil Mall för speldesigndokument/Speldesigndokument/05 Konstnärlig ledning och ljud.md

Konstnärlig ledning och ljud

Ägare: [namn] · Status: utkast · Senast granskad: [datum]

Hur spelet ser ut och låter, beskrivet så exakt att två grafiker som arbetar var för sig gör saker som passar ihop.

Visuella regler

Tre till fem regler om form, färg, ljus och detaljnivå. ”Stiliserat” är ingen regel; ”varje siluett går att läsa på trettio meters håll” är det.

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

Referenser

Lägg in referensbilder under varje regel och säg vad ni tar från var och en: paletten, ljuset, formerna. Aldrig ”allt”.

Palett

Assetfamiljer

Vad varje familj av assets har gemensamt, dess budget (polygoner, texturstorlek, bildrutor) och vem som godkänner den.

Ljud

Stämningen i musiken, ljudeffekterna och rösterna, och den spelinformation som ljudet bär: varningar, belöningar, tidens gång.

• Musik: [...]
• Ljudeffekter: [...]
• Röster: [språk och antal repliker, eller inga]
• Information som ljudet bär: [...]

Exempel (Saltmarrow, ett exempelspel): Två minuter innan tidvattnet vänder ljuder ett horn över slätterna. Tidvattnet syns på skärmen, hörs i mixen och känns i handkontrollen.

Granskningar

Vem som godkänner grafik och ljud, och när. Håll feedbacken på själva bilden, fäst vid punkten den gäller: det sparar en runda med ”vilken, den till vänster?”

• Grafiken godkänns av: [...]
• Ljudet godkänns av: [...]

Öppna frågor

• [Fråga], [vem som besvarar den], [senast när]

Se även: Värld, berättelse och karaktärer · Gränssnitt och tillgänglighet

Fil Mall för speldesigndokument/Speldesigndokument/06 Gränssnitt och tillgänglighet.md

Gränssnitt och tillgänglighet

Ägare: [namn] · Status: utkast · Senast granskad: [datum]

Allt spelaren läser, trycker på och navigerar i, och hur spelet anpassar sig till spelare som ser, hör eller rör sig annorlunda.

Skärmar och flöde

Varje skärm och hur spelaren tar sig mellan dem, från start till avslut. Ett diagram hittar återvändsgränderna innan de byggs.

flowchart LR
  n0["Titelskärm"]
  n1["Huvudmeny"]
  n2["Spela"]
  n3["Inställningar"]
  n4["Paus"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n2 --> n4
  n4 --> n2
  n4 --> n1

HUD

Vad som syns på skärmen under spelet, och varför varje element förtjänar sin plats. Det spelaren kollar mer sällan än en gång i minuten kan ligga i en meny.

Input

Tillgänglighet

Bocka av varje punkt, eller skriv varför den inte gäller. Beslutade tidigt kostar de flesta lite; tillagda sent kostar de mycket.

• All input kan mappas om
• Handlingar där en knapp hålls in kan ställas om till av/på
• Undertexterna visar vem som talar, och textstorleken går att ändra
• Viktiga ljud har även en visuell signal
• Ingen information förmedlas enbart med färg
• Texten kan göras större
• Timers kan saktas ned eller stängas av
• Kameraskakningar och blixtar kan minskas

Text och språk

Språken vid lansering, och reglerna som håller översättning möjlig: ingen text inbakad i bilder, plats för text som är upp till en tredjedel längre än engelskan, typsnitt som täcker alla skriftsystem ni släpper på.

• Språk vid lansering: [...]
• Språk senare: [...]
• Typsnitt: [...]

Öppna frågor

• [Fråga], [vem som besvarar den], [senast när]

Se även: Gameplay · Konstnärlig ledning och ljud · Teknisk design

Fil Mall för speldesigndokument/Speldesigndokument/07 Teknisk design.md

Teknisk design

Ägare: [namn] · Status: utkast · Senast granskad: [datum]

De tekniska valen som formar designen, och de gränser designen måste hålla sig inom. Detaljerad arkitektur kan ligga i tekniska dokument som länkas härifrån.

Motor och verktyg

Prestandamål och budgetar

Siffrorna varje avdelning bygger mot. Utan dem upptäcks prestandaproblemen först i slutet.

Arkitektur

De viktigaste delarna av spelets kod och hur de pratar med varandra. Ett diagram med fem rutor slår fem sidor prosa.

flowchart TD
  n0["Input"]
  n1["Speltillstånd"]
  n2["Rendering"]
  n3["Ljud"]
  n4["Sparfiler"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n1 --> n4

Sparning och online

• Sparning: [vad som sparas, när och var]
• Online: [inget, peer-to-peer, dedikerade servrar]
• Spelardata: [vad som samlas in och var det lagras]

Pipeline

Hur en asset eller en textrad tar sig från sin upphovsperson till ett spelbart bygge, och hur lång tid det tar. En långsam pipeline minskar i det tysta antalet iterationer ett team hinner med.

[Din pipeline]

Tekniska risker

Öppna frågor

• [Fråga], [vem som besvarar den], [senast när]

Se även: Gränssnitt och tillgänglighet · Produktionsplan

Fil Mall för speldesigndokument/Speldesigndokument/08 Produktionsplan.md

Produktionsplan

Ägare: [namn] · Status: utkast · Senast granskad: [datum]

När spelet släpps, vem som gör det, vad som kan stoppa det och varje beslut som fattats på vägen.

Milstolpar

”Klar när” är kolumnen folk hoppar över. Utan den är en milstolpe bara ett datum.

Team

Risker

Beslutslogg

Varje beslut som ändrar designen: vad som beslutades, av vem, varför och vilket dokument som ändrades. När någon om sex månader frågar varför det fungerar så här, är det den här tabellen som svarar.

Exempel (Saltmarrow, ett exempelspel): 12 september: ingen strid, hotet kommer bara från tidvattnet och stormarna. Beslutat av den kreativa chefen och systemdesignern, för att hålla spelet lugnt och tidspressen skarp. Ändrat dokument: designpelarna.

Öppna frågor

• [Fråga], [vem som besvarar den], [senast när]

Se även: Speldesigndokument · Banor och innehåll · Teknisk design