# Template Game Design Document yang Benar-Benar Dibuka URL: https://koroverse.app/id/journal/template-game-design-document Type: blog Locale: id Published: 2026-10-16 Updated: 2026-10-16 --- > Template game design document yang berguna dimulai dari satu halaman. Panduan ini membahas lima blok inti, design pillars yang bisa menolak fitur, cara memisahkan lore, dan pilihan tool. Template game design document yang berguna dimulai dari satu halaman, lalu tumbuh hanya ketika permainannya memang membutuhkannya. Mulai dengan lima blok: pitch, design pillars, core loop, daftar sistem, dan pertanyaan terbuka. Lore, catatan level, dan detail lainnya baru ditambahkan ketika playtest membuktikan bahwa mekaniknya memang berjalan. Di bawah ini kamu akan menemukan kerangka yang kami pakai untuk proyek TTRPG dan video game indie, beserta bagian mana yang biasanya paling cepat basi. ## Mengapa kebanyakan game design document mati di minggu ketiga? Penyebab utamanya biasanya ambisi. Seseorang membuka file kosong, menempelkan kerangka 20 bagian dari forum, lalu menghabiskan satu akhir pekan mengisi kotak untuk mekanik yang belum pernah diuji. Di minggu ketiga, permainannya sudah bergerak, tapi dokumennya belum. Tidak ada yang membukanya lagi, dan tidak ada yang mau mengakuinya. Panduan GDD dari Game Dev Beginner menyebut masalah ini dengan jelas: dokumen yang terlalu besar dan terlalu rinci menuntut kerja berat di awal, hampir selalu sudah usang, dan menjadi kaku ketika desainnya masih berubah. Solusinya adalah bertahap. Tulis dulu satu halaman, lalu sekitar sepuluh halaman ketika bentuk permainan mulai terlihat, dan versi lengkap hanya ketika konten mulai diproduksi. Tahap ini lebih penting untuk desainer TTRPG daripada untuk tim video game. Desainer TTRPG sering sekaligus menjadi penulis, kepala sistem, dan playtester. Tidak ada engineer yang menunggu spesifikasi darimu. Dokumen itu punya satu tugas: mencegahmu bertentangan dengan dirimu sendiri antara sesi keempat dan sesi keempat puluh. Lewati template 40 halaman kalau kamu bekerja sendirian, karena kamu tidak akan sanggup merawatnya. [Definisi game design document di Wikipedia](https://en.wikipedia.org/wiki/Game_design_document) menyebutnya sebagai dokumen hidup, yang berarti tidak ada yang berharap dokumen itu selesai di hari pertama. ## Apa yang harus ada di template game design document yang benar-benar dibuka orang? Lima blok ini menutupi bulan pertama hampir setiap proyek. Buat masing-masing cukup singkat agar seluruh halaman bisa dibaca dalam dua menit. - **Pitch.** Dua kalimat. Siapa yang memainkannya, apa yang mereka lakukan, dan apa yang membedakannya dari game terdekat yang sudah mereka mainkan. - **Design pillars.** Tiga atau empat pernyataan yang menjadi ukuran untuk setiap keputusan berikutnya. "Setiap pertarungan selalu menghabiskan sesuatu yang permanen" adalah pillar. "Seru dan menarik" bukan. - **Core loop.** Hal yang diulang-ulang oleh pemain. Di dungeon crawl, mungkin menjelajah, memilih, mengambil risiko, lalu membelanjakan. Dalam kampanye politik, mungkin intrik, pengaruh, konsekuensi, lalu akibatnya. - **Daftar sistem.** Hanya nama, dengan satu baris untuk setiap sistem. Jangan tentukan angka dulu. - **Pertanyaan terbuka.** Bagian paling berguna di halaman ini, dan justru yang paling sering dilewatkan oleh template. Tulis apa yang belum kamu ketahui, dan beri tanggal. Tambahkan juga change log di bagian bawah, meski hanya satu baris per minggu. Ketika playtest mematikan sebuah ide, catat keputusan beserta alasannya. Kalau tidak, kamu sendiri di masa depan akan mencoba lagi ide yang sama. Format pertanyaan terbuka juga tidak perlu rumit. Tulis pertanyaannya dalam satu kalimat, beri tanggal saat pertanyaan itu muncul, dan tambahkan nama sesi playtest yang kemungkinan besar akan menjawabnya. Dengan begitu, setiap pertanyaan punya jalan untuk ditutup. Pertanyaan yang sudah terjawab tidak perlu dihapus. Pindahkan saja ke change log dengan jawabannya, supaya riwayat keputusanmu tetap terlihat. ![Papan gabus dengan sembilan kartu indeks kosong tertempel dalam grid, satu tangan sedang menyesuaikan satu kartu](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/koroverse/2026-10/eb3440-inline1.webp) ## Bagaimana menulis design pillars yang bisa kalah dalam sebuah perdebatan? Sebuah pillar layak dipertahankan karena ia bisa menolak sesuatu. Kalau kamu tidak bisa menyebut satu fitur yang akan ditolak oleh pillar itu, berarti ia hanya hiasan. Uji setiap pillar dengan daftar potong. Ambil tiga fitur yang paling kamu sukai, lalu tanyakan pillar mana yang dilayani masing-masing. Fitur yang tidak melayani apa pun masuk ke rak "mungkin nanti", dan rak itu boleh sangat panjang. Ini jam paling sulit dalam seluruh proses, dan nilainya lebih besar daripada bagian template mana pun. Berikut contoh dari setting kampanye yang berpusat pada wabah. Pillar pertama: kelangkaan itu terlihat, jadi setiap sumber daya penyembuh dicatat di atas meja. Pillar kedua: faksi menginginkan obat yang berbeda, jadi tidak ada satu perawatan yang menyelesaikan semuanya. Pillar ketiga: peta menyusut, jadi perjalanan makin mahal seiring cerita maju. Lalu datang usulan mantra kebangkitan. Pillar pertama menolaknya. Keputusan itu butuh sepuluh detik, bukan debat empat puluh menit. **Worth knowing:** pillar bukan slogan pemasaran. Ia internal dan blak-blakan, dan kadang terdengar agak tidak enak didengar. Itu tidak masalah. ## Di mana lore seharusnya berada di GDD, dan kapan ia justru menghalangi? Lore adalah bagian yang paling cepat bertambah dan paling jarang dibaca. Kebanyakan dokumen menguburnya di bagian "Cerita" di paling bawah, atau membiarkannya menelan seluruh file. Dua-duanya tidak berhasil. Pisahkan materi berdasarkan fungsinya. Lore yang mengubah cara bermain, seperti dendam faksi yang membuka quest atau kutukan yang membentuk sebuah class, tinggal di dalam sistem yang ia pengaruhi. Lore yang hanya membangun suasana tinggal di halaman Codex terpisah, yang tidak perlu dibuka untuk mengambil keputusan desain. Ujinya sederhana: kalau paragraf itu dihapus dan tidak ada mekanik, lemparan dadu, atau pilihan pemain yang berubah, paragraf itu milik Codex. Pemisahan ini juga melindungi kanon. Ketika sebuah fakta hidup di dua tempat, keduanya akan saling menjauh. Pilih satu rumah untuk setiap fakta dan tautkan dari tempat lain. Kanon adalah sebuah janji, dan setiap inkonsistensi merusaknya. ![Laptop tertutup di samping buku catatan kosong, pensil, dadu, dan tumpukan buku di atas meja game master](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/koroverse/2026-10/74d10f-inline2.webp) Desainer yang mengerjakan game dengan narasi yang kuat sering menambahkan halaman timeline pendek dan daftar "siapa tahu apa". Keduanya murah. Keduanya bisa menghemat revisi berhari-hari ketika sebuah pengungkapan di akhir harus mendarat dengan benar. ## Tool mana yang sebaiknya menyimpan template kamu: Notion, Obsidian, atau dokumen biasa? Alat itu kurang penting dibanding apakah dokumennya tetap berada di tempat yang sudah kamu pakai setiap hari. Dokumen di tab yang tidak pernah kamu buka adalah dokumen mati. Notion adalah pilihan standar untuk tim kecil karena halaman bisa saling tertaut, database menampung item dan faksi, dan kolaborator tidak perlu menyiapkan apa pun. Sudah ada opsi siap pakai, termasuk [template GDD untuk Notion](https://www.notion.com/templates/game-design-document-gdd) dengan bagian untuk kontrol, game loop, desain level, dan aturan. Kelemahannya adalah ketergantungan pada satu platform dan godaan untuk membuat database bagi hal-hal yang tidak membutuhkannya. Obsidian cocok untuk desainer solo yang menginginkan file Markdown biasa di disk. Backlink bekerja dengan baik di sini: tautkan sebuah faksi ke setiap adegan tempat ia muncul, dan kamu mendapat pengecekan konsistensi secara gratis. Ia tetap bertahan meski vendor-nya menghilang, yang penting jika proyekmu berjalan bertahun-tahun. GitBook cocok ketika dokumen perlu bersifat publik atau semi-publik, misalnya untuk grup playtest atau halaman backer crowdfunding. Google Docs biasa sudah cukup untuk game jam. Hindari alat dengan model izin yang rumit kecuali penerbit memintanya. Apa pun pilihanmu, tetapkan satu aturan: dokumen diperbarui di akhir setiap playtest, sebelum siapa pun pulang. Sepuluh menit, tanpa pengecualian. ## Apa yang ditambahkan setelah prototipe lolos playtest? Setelah tiga atau empat sesi dengan pemain sungguhan, halaman satu-halaman itu layak mendapat lapisan berikutnya. Tambahkan bagian-bagian berikut sesuai urutan ini, dan hanya ketika masalahnya memang muncul. **Detail sistem.** Angka, tabel, dan kasus-kasus pinggiran. Tulis ini saat kamu mengunci sebuah sistem, jangan sebelumnya. Untuk TTRPG, di sinilah ekonomi aksi, rentang kerusakan, dan biaya sumber daya dicatat, bersama teks aturan seperti yang tertulis. Untuk video game, tambahkan data yang akan dibaca oleh engineer. **Daftar konten.** Item, musuh, faksi, dan lokasi. Gunakan daftar dengan satu baris per entri, lalu tulis di ujung setiap baris pillar yang dilayaninya. Baris yang tidak melayani apa pun adalah kandidat untuk dipotong. **Antarmuka dan alur.** Tata letak lembar karakter untuk tabletop, atau alur layar untuk digital. Sketsa dengan tangan sebelum kamu mendeskripsikannya dengan teks. **Catatan produksi.** Milestone, cakupan, risiko, serta apa yang masuk rilis pertama dan apa yang tidak. Jika kamu berencana menjual hasilnya di DriveThruRPG atau Itch.io, di sinilah teks halaman produk dan asumsi harga mulai disusun. Bagian pitch atau pemasaran adalah dokumen terpisah untuk pembaca yang berbeda. Penerbit dan backer ingin konteks pasar dan keunggulan unik. Playtester kamu ingin aturan. Kalau keduanya dicampur, hasilnya adalah file yang tidak melayani siapa pun. ![Peta wilayah yang digambar tangan dengan miniatur yang dicat, menandai wilayah setiap faksi](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/koroverse/2026-10/4279d7-inline3.webp) ## Bisakah AI membantu menulis game design document, dan di mana ia gagal? AI membantu membuat draf untuk bagian yang membosankan dan gagal di bagian yang penting. Minta model memperluas daftar sistem menjadi tabel kasus pinggiran, dan kamu akan mendapat draf pertama yang layak dalam semenit. Minta ia memilih pillar untukmu, dan kamu akan mendapat pillar yang terdengar seperti game lain. Ia cepat menghasilkan sesuatu. Keputusannya tetap membutuhkan pemeriksaan manusia. Penggunaan praktis yang paling berguna adalah pengecekan konsistensi. Berikan Codex dan daftar sistem, lalu tanyakan di mana dua halaman saling bertentangan. Alat yang dibangun di sekitar story bible yang panjang, seperti Novelcrafter, memang dirancang untuk referensi silang semacam ini. Perlakukan hasilnya sebagai daftar tersangka, bukan vonis, dan periksa setiap tanda terhadap halamanmu sendiri. Satu aturan yang tegas: model tidak pernah menulis bagian pertanyaan terbuka. Halaman itu adalah daftar jujur tentang apa yang belum kamu ketahui, dan menyerahkannya kepada AI berarti tujuannya hilang. ## Apa yang dibuang, dan apa yang dipertahankan? Tunda template penuh sampai sebuah mekanik bertahan setidaknya tiga sesi nyata. Lewati esai "target audiens" kalau kamu tidak bisa menyebut lima orang sungguhan yang akan memainkannya. Lewati bagian monetisasi yang rinci untuk game yang belum menemukan loop-nya. Lewati bagian mana pun yang tidak bisa kamu bayangkan dibacakan keras-keras kepada kolaboratormu. Pertahankan pillar, pertanyaan terbuka, dan change log. Ketiganya melakukan sebagian besar pekerjaan. Dokumen yang hanya berisi ketiganya, diperbarui setiap minggu, lebih baik daripada file 30 halaman yang rapi tapi tidak ada yang membukanya sejak Maret. Template itu adalah janji kepada dirimu di masa depan tentang apa yang sudah kamu putuskan dan mengapa. Buatlah cukup pendek agar kamu bisa menepatinya. ## FAQ ### Apa isi minimum template game design document? Lima blok: pitch dua kalimat, tiga sampai empat design pillars, core loop, daftar sistem dengan satu baris per sistem, dan pertanyaan terbuka yang diberi tanggal. Tambahkan change log satu baris per minggu di bagian bawah. ### Berapa panjang ideal game design document untuk proyek solo? Mulailah dari satu halaman. Tambahkan sekitar sepuluh halaman ketika bentuk permainan mulai terlihat, dan baru buat versi lengkap ketika konten mulai diproduksi. Template 40 halaman biasanya tidak terawat oleh pengembang solo. ### Apa yang dimaksud design pillar yang bisa kalah? Pillar yang mampu menolak sebuah fitur. Ujinya: ambil tiga fitur favoritmu dan tanyakan pillar mana yang dilayani masing-masing. Jika sebuah pillar tidak pernah menolak apa pun, ia belum cukup spesifik. ### Di mana lore sebaiknya ditulis dalam GDD? Lore yang mengubah mekanik atau pilihan pemain tinggal di dalam sistem yang terkait. Lore yang hanya membangun suasana masuk ke halaman Codex terpisah. Setiap fakta sebaiknya punya satu rumah dan ditautkan dari tempat lain. ### Bisakah AI menulis game design document sepenuhnya? AI berguna untuk membuat draf bagian yang rutin dan untuk pengecekan konsistensi antarhalaman. Pillar, keputusan desain, dan pertanyaan terbuka tetap harus ditulis manusia. Anggap hasil AI sebagai daftar tersangka yang perlu diperiksa. ### Kapan game design document harus diperbarui? Di akhir setiap playtest, sebelum sesi berakhir. Sisihkan sepuluh menit untuk memperbarui halaman dan change log, termasuk mencatat ide yang dimatikan beserta alasannya agar tidak diulang.