# Game design document mall: börja med en sida, inte fyrtio URL: https://auxworld.app/sv/journal/game-design-document-mall Type: blog Locale: sv Published: 2026-10-27 Updated: 2026-10-29 --- > En game design document mall för indie-designers: sju block på en sida, vad du kan stryka och hur du dokumenterar världar som genereras från en prompt. Du behöver en game design document mall som ryms på en sida, och som sedan får växa först när spelet förtjänar det. Börja med sju block: pitch, core loop, spelarens verb, värld, system, omfattning och öppna frågor. Fyll i dem på en kväll. Stryk allt du inte kan testa i en prototyp den här månaden. Resten av inlägget är själva mallen, plus de delar som de flesta guider hoppar över. ## Varför dör de flesta game design-dokument i vecka två? Föreställ dig ett GDD på fyrtio sidor. Snygg framsida, en innehållsförteckning, ett kapitel om bakgrundshistorien som ingen bad om. Efter två veckor har prototypen glidit iväg och dokumentet är ett fossil. Det är det verkliga misslyckandet. Inte saknade avsnitt, utan en fil som slutar vara sann. Ett GDD är ett arbetsverktyg, närmare en ändringslogg än en bibel. Om dokumentet och bygget inte stämmer överens vinner bygget, och folk slutar öppna dokumentet. Frågan är alltså inte vad ett game design-dokument bör innehålla. Frågan är vilket det minsta dokument du faktiskt kommer att hålla ärligt. ![Whiteboardskiss av en core loop, ritad som fyra rutor kopplade med pilar](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/auxworld/2026-10/7165e4-core.webp) ## Mallen: ett game design-dokument på en sida Kopiera den här dispositionen. Varje block får två till fem rader, aldrig mer vid första genomgången. - **Pitch.** En mening som en främling kan upprepa. "Ett samarbetsbyggt hamnsamhälle där tidvattnet ritar om kartan varje natt." - **Core loop.** Det spelaren gör, om och om igen, på under en minut. Rita den som en cirkel av verb. - **Spelarens verb.** Fem till åtta handlingar. Inte funktioner. Verb: klättra, handla, gömma sig, forka, laga. - **Värld.** Plats, stämning och tre regler som alltid gäller. Vädret räknas som en regel. - **System.** De två eller tre mekanismer som gör verben intressanta. Ekonomi, smygande, hantverk, vad som än bär loopen. - **Omfattning.** Vad som släpps, vad som stryks och vad som är en sträcka. Skriv ett datum bredvid varje post. - **Öppna frågor.** Den ärliga listan över saker du ännu inte vet. Det här blocket är det mest värdefulla på sidan. Lägg märke till vad som saknas: monetisering, marknadsplan, ett kapitel med karaktärernas bakgrund. De hör hemma i separata filer, skrivna när prototypen bevisat loopen. De flesta publicerade mallar börjar med dem, och det är just därför de dokumenten aldrig blir klara. Om du vill ha en längre struktur för ett team som behöver godkännande lägger [GitBooks guide om hur man skriver ett game design-dokument](https://www.gitbook.com/blog/how-to-write-a-game-design-document) upp den klassiska kapitellistan. Dess råd att börja från en sidas version och lägga till detaljer när prototyperna visar behovet är rätt instinkt. ## Vad ska ett core loop-avsnitt egentligen säga? Skippa adjektiven. Skriv loopen som en mening med en timer. `Samla skrot i 40 sekunder -> bär skrotet till bryggan -> byt det mot en uppgradering -> tidvattnet vrider, kartan ändras -> upprepa`Läs den högt. Om ett steg känns dött har du hittat din första prototypuppgift. Om varje steg låter bra men du inte kan säga varför spelaren kommer tillbaka, saknar loopen en anledning. Lägg den som en öppen fråga i stället för att gömma den i brödtexten. Ett test jag gillar: loopmeningen ska få plats på en enda textrad. Om den behöver ett stycke är det två loopar, och då designar du två spel. ## Vilka avsnitt kan du stryka utan ånger? Var obarmhärtig. Ett soloprojekt eller ett projekt med två personer kan oftast släppa dessa redan första dagen: - **Fullständiga karaktärsbiografier.** Behåll ett namn, en önskan och ett fel. Skriv mer när karaktären dyker upp i ett bygge. - **Detaljerade nivåbeskrivningar.** Beskriv nivåns regler, inte rummen. - **Kapitel om plattform och monetisering.** Parkera dem tills loopen fungerar. - **Art bible.** Tre referensbilder och en palett. Det är allt. Hoppa över allt detta om du släpper ett jam-spel på 72 timmar: pitchen, loopen och verben är hela ditt dokument. Behåll hela listan om du har en förläggare, en väg mot konsolcertifiering eller medarbetare som inte kan ställa frågor klockan tolv på natten. [Unitys PDF med mall för game design-dokument](https://connect-prd-cdn.unity.com/20201215/83f3733d-3146-42de-8a69-f461d6662eb1/Game-Design-Document-Template.pdf) är en bra referens för hur mekanik och objektbeteende skrivs ner när ett team är inblandat. Läs den som en katalog, inte som en checklista. ## Var ska du förvara dokumentet? Där du redigerar det varje dag. Det låter självklart tills du ser hur många GDD:n som lever i en PDF som ingen kan jämföra versioner i. Välj ett verktyg som ger dig rubriker, en databas för uppgifter och versionshistorik. En anteckningsapp med databas fungerar bra, eftersom dina öppna frågor och omfattningslistan kan bli spårade poster i stället för punktlistor som ruttnar. Vanlig Markdown i repot är det andra goda svaret. Det ligger bredvid koden, det går att jämföra versioner i med vanliga verktyg och ingen glömmer att uppdatera det under en pull request. Nackdelen är att icke-tekniska teammedlemmar inte kommer att röra det. Oavsett val: lägg enpageren överst och länka vidare till djupare filer. Sidan är kartan. Filerna är terrängen. ![Laptop med en genererad dimmig by bredvid en anteckningsbok med designskisser](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/auxworld/2026-10/21d264-world.webp) ## Ändrar din motor vad du skriver ner? Lite, ja. Motorn avgör vilka verb som är billiga och vilka som är dyra, så system- och omfattningsblocken bör säga det tydligt. Om du jobbar i en fullskalig 3D-motor med stor tillgångspipeline behöver omfattningen en rad för varje tillgångskategori, eftersom innehållet är där tidplaner dör. Om du vill ha en motor med öppen källkod utan royaltyräkning blir omfattningsblocket enklare: ingen licensrad, men en riktig anteckning om vilka funktioner du bygger själv. Och om spelet är 2D med täta mekaniker bär loopavsnittet nästan allt. Små, läsbara dokument passar små, läsbara spel. Poängen är inte att utse en vinnare. Poängen är att raden "Motor och verktyg" inte är en slängd rad. Den ska lista vad motorn gör enkelt, vad den gör smärtsamt och vad du vägrar bygga. ## Hur skriver du ett GDD för en värld som genererar sig själv? Det här är gapet i nästan alla mallar. De utgår från att du placerar varje träd för hand. När en värld genereras från en prompt ändrar designdokumentet form. Du specificerar inte längre rum. Du specificerar villkor: vad som måste gälla i varje värld motorn kan skapa, och vad som får variera. Lägg till två block i enpageren: - **Världsvillkor.** Reglerna som inte får brytas. "Varje bosättning har vatten inom två minuters gång." "Inga återvändsgränder för uppdragsplatser." - **Promptfrön.** De exakta prompterna du använde, sparade som en del av dokumentet. Så här kan ett frö se ut i praktiken: `en dimmig hamnstad vid lågvatten, ett fyr, smala trappor, repbroar mellan taken, ingen syns ännu`Spara prompten, spara det som kom tillbaka och notera vad du skulle forka. Prompten är din spec och din ändringslogg på samma gång. Forka den, ändra en sak, se vad som händer och skriv sedan skillnaden i dokumentet. Den vanan gör en genererad värld till något du kan resonera om, och den ger teammedlemmarna något konkret att granska i stället för en känsla. En varning: genereringskvaliteten varierar mycket mellan verktyg, och vissa funktioner är fortfarande i beta i branschen. Skriv ner versionen och datumet bredvid varje frö, så vet du om ett resultat går att upprepa eller om det var ett lyckat kast. ## Ett snabbt sätt att testa loopen innan du skriver mer Så här kör jag arbetsflödet en kväll på en ny idé. - Skriv enpageren på 30 minuter. Redigera den inte. - Gör pitchen och tre världsregler till en prompt och generera ett första pass av rummet. - Gå igenom core loopen i det rummet, för hand eller i en grov prototyp. - Markera varje steg som kändes dött. De går in som öppna frågor. - Stryk ett verb. Stryk alltid ett. Strykningen är den del folk hoppar över. Ett designdokument som bara växer är en önskelista. Att ta bort ett verb tvingar de kvarvarande att bära mer, och det brukar avslöja vilket system som faktiskt gjorde jobbet. ![Korkskiva med indexkort kopplade med röd tråd, där ett kort sätts upp](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/auxworld/2026-10/0dac63-cards.webp) ## Hur håller du dokumentet levande efter vecka två? Tre vanor, ingen av dem heroisk. **Datera varje öppen fråga.** Om en fråga är äldre än tre veckor och fortfarande öppen, svara på den eller erkänn att du undviker den. **Uppdatera dokumentet samma pass som bygget.** Inte senare. Senare är så fossilet bildas. En redigering på två rader i slutet av en session kostar en minut. **Behåll en lista över dödade idéer längst ner.** Den sparar dig från att debattera samma mekanik varje månad, och det är märkligt motiverande att se hur mycket du faktiskt levererat genom att säga nej. När någon ny ansluter till projektet, ge dem enpageren först och se var de blir förvirrade. Varje förvirrad fråga är en rad som saknas i dokumentet. ## Vad skulle vi faktiskt använda? Om du jobbar ensam eller i par räcker enpageren med sju block plus en lista med promptfrön under den första månaden. Har du ett team, behåll enpageren som dörren in och lägg till separata filer för system och innehåll när prototypen motiverar dem. Har du en förläggare, ge dem den långa versionen, men behåll enpageren som den version du litar på. Öppna en tom sida ikväll och skriv pitchen. En mening. Sedan loopen, med en timer på. Om du inte hinner klart på en halvtimme är idén fortfarande en dröm, och det är bra att veta innan du lägger en månad på den. ## FAQ ### Vad är en game design document mall? Det är en återanvändbar disposition för att skriva ner vad ditt spel är, hur det spelas och vad du ska bygga. De mest användbara versionerna börjar med pitch, core loop, spelarens verb, värld, nyckelsystem, omfattning och öppna frågor, och de är tillräckligt korta för att du faktiskt ska uppdatera dem. ### Hur lång ska ett game design-dokument vara? Så lång som det behövs för att undvika förvirring, och inte längre. Många team börjar med en sidas version och lägger till separata filer för system eller innehåll när prototyperna bevisat idén. Ett dokument på fyrtio sidor som skrivs före någon prototyp blir oftast inaktuellt inom några veckor. ### Vad ska ett GDD innehålla för en soloutvecklare? Pitch, core loop, spelarens verb, världsregler, två eller tre nyckelsystem, en daterad omfattningslista och öppna frågor. Hoppa över fullständiga karaktärsbiografier, monetiseringsplaner och detaljerade art bibles tills en spelbar prototyp motiverar dem. ### Behövs ett game design-dokument fortfarande? Ja, i en lättare form. Du behöver ingen bibel, men du behöver en gemensam och aktuell beskrivning av loopen och omfattningen. Utan den kommer teammedlemmar och ditt framtida jag att gissa, och bygget glider bort från idén. ### Var ska jag förvara mitt game design-dokument? Där du redigerar det varje dag. En anteckningsapp med databas fungerar bra för att spåra öppna frågor och omfattning, och vanlig Markdown i repot fungerar bra för utvecklarteam eftersom det kan jämföras versioner i tillsammans med koden. Ha enpageren överst oavsett. ### Hur dokumenterar man en spelvärld som genererats från en prompt? Skriv ner världsvillkor, alltså de regler som måste gälla i varje genererat resultat, och spara de exakta prompterna som frön. Notera verktygsversionen och datumet bredvid varje frö, skriv ner vad som kom tillbaka och logga vad du skulle forka. Prompten blir både spec och ändringslogg.