Template Dokumen Desain Game: Mulai dari Satu Halaman

Kamu butuh template dokumen desain game yang muat di satu halaman, lalu tumbuh hanya saat gamenya memang membutuhkannya. Mulai dengan tujuh blok: pitch, core loop, player verbs, dunia, sistem, scope, dan pertanyaan terbuka. Isi semuanya dalam satu malam. Potong apa pun yang tidak bisa kamu uji di prototipe bulan ini. Sisa artikel ini adalah template itu sendiri, ditambah bagian-bagian yang paling sering dilewatkan panduan lain.

Mengapa sebagian besar dokumen desain game mati di minggu kedua

Bayangkan GDD setebal 40 halaman. Sampul cantik, daftar isi, bab lore yang tidak diminta siapa pun. Di minggu kedua, prototipe sudah melenceng dan dokumennya jadi fosil.

Itu kegagalan yang sebenarnya. Bukan karena ada bagian yang hilang, tapi karena file itu berhenti jujur. GDD adalah alat kerja, lebih mirip changelog daripada kitab suci. Kalau dokumen dan build tidak sejalan, dokumen yang kalah, dan orang berhenti membukanya.

Jadi pertanyaannya bukan "apa saja isi dokumen desain game?" tapi "dokumen terkecil apa yang benar-benar akan kujaga tetap jujur?"

Template dokumen desain game satu halaman

Salin kerangka ini. Setiap blok cukup dua sampai lima baris, jangan lebih di percobaan pertama.

1. Pitch. Satu kalimat yang bisa diulang orang asing. "Kota pelabuhan co-op tempat air pasang menulis ulang peta setiap malam."

2. Core loop. Yang dilakukan pemain, berulang-ulang, dalam kurang dari satu menit. Gambarkan sebagai lingkaran kata kerja.

3. Player verbs. Lima sampai delapan aksi. Bukan fitur. Contoh kata kerja: memanjat, berdagang, bersembunyi, bercabang, memperbaiki.

4. Dunia. Tempat, suasana, dan tiga aturan yang selalu benar. Cuaca dihitung sebagai aturan.

5. Sistem. Dua atau tiga mekanisme yang membuat kata kerja itu menarik. Ekonomi, stealth, crafting, apa pun yang menggerakkan loop.

6. Scope. Apa yang rilis, apa yang dipotong, dan apa yang stretch goal. Beri tanggal di samping tiap item.

7. Pertanyaan terbuka. Daftar jujur tentang hal-hal yang belum kamu ketahui. Blok ini yang paling berharga di halaman itu.

Perhatikan apa yang tidak ada: monetisasi, rencana marketing, bab latar belakang karakter. Itu milik file terpisah, ditulis saat prototipe membuktikan loop-nya. Kebanyakan template yang beredar justru dimulai dari situ, dan itulah sebabnya dokumen-dokumen itu tidak pernah selesai.

Kalau kamu butuh struktur yang lebih panjang untuk tim yang perlu persetujuan, panduan GitBook tentang cara menulis game design document memuat daftar bab klasiknya. Sarannya untuk mulai dari versi satu halaman lalu menambah detail setelah prototipe berjalan adalah naluri yang tepat.

Core loop sebaiknya ditulis seperti apa

Buang kata sifat. Tulis loop sebagai satu kalimat dengan timer.

Cari rongsokan selama 40 detik -> bawa ke dermaga -> tukar dengan satu upgrade -> air pasang, peta berubah -> ulangi

Sekarang bacakan keras-keras. Kalau satu langkah terasa mati, kamu sudah menemukan tugas prototipe pertamamu. Kalau tiap langkah terdengar oke tapi kamu tidak bisa bilang kenapa pemain kembali, berarti loop-nya kekurangan alasan. Jadikan itu pertanyaan terbuka, jangan dikubur di bawah prosa.

Satu tes yang aku suka: kalimat loop harus muat dalam satu baris teks. Kalau butuh satu paragraf, itu dua loop, dan kamu sedang mendesain dua game.

Bagian mana yang boleh dipangkas tanpa menyesal?

Jangan setengah-setengah. Proyek solo atau berdua biasanya bisa membuang ini sejak hari pertama:

• Bio karakter lengkap. Simpan nama, keinginan, dan satu kelemahan. Tulis lebih banyak saat karakter muncul di build.

• Deskripsi level detail. Jelaskan aturan level, bukan tiap ruangan.

• Bab platform dan monetisasi. Parkir dulu sampai loop-nya berjalan.

• Art bible. Tiga gambar referensi dan satu palet warna. Cukup.

Lewati semua ini kalau kamu sedang membuat game jam dalam 72 jam: pitch, loop, dan verbs adalah seluruh dokumenmu. Simpan daftar lengkapnya kalau kamu punya publisher, jalur sertifikasi konsol, atau kontraktor yang tidak bisa bertanya padamu jam dua belas malam.

PDF template GDD dari Unity layak dijadikan referensi tentang cara menuliskan mekanik dan perilaku objek setelah tim terlibat. Bacalah sebagai katalog, bukan daftar centang.

Di mana dokumen disimpan, dan apakah engine mengubah isinya?

Simpan di tempat yang kamu edit setiap hari. Kedengarannya jelas, sampai kamu sadar betapa banyak GDD yang tinggal di PDF yang tidak bisa di-diff siapa pun.

Pilih alat yang memberimu heading, database untuk tugas, dan riwayat versi. Aplikasi catatan berbasis database cocok, karena pertanyaan terbuka dan daftar scope-mu bisa menjadi item yang dilacak, bukan poin-poin yang membusuk.

Markdown biasa di repo adalah jawaban lain yang bagus. Ia tinggal di dekat kode, mudah di-diff, dan tidak ada yang lupa memperbaruinya saat pull request. Kekurangannya, rekan non-teknis tidak akan menyentuhnya.

Apa pun pilihanmu, letakkan satu halaman ringkas di paling atas dan tautkan ke file yang lebih dalam. Halaman itu peta. File-file itu wilayahnya.

Engine juga ikut menentukan. Sedikit, tapi cukup untuk diperhatikan. Engine menentukan verbs mana yang murah dan mana yang mahal, jadi blok sistem dan scope-mu harus menyebutkannya dengan jelas.

Kalau kamu memakai engine 3D penuh dengan pipeline aset besar, scope perlu baris untuk setiap kategori aset, karena konten adalah tempat jadwal berakhir.

Kalau kamu ingin engine open-source tanpa hitungan royalti, blok scope-mu jadi lebih sederhana: tanpa baris lisensi, tapi dengan catatan jujur tentang fitur mana yang akan kamu bangun sendiri.

Dan kalau gamenya 2D dengan mekanik yang rapat, bagian loop memikul hampir semuanya. Dokumen yang kecil dan mudah dibaca cocok untuk game kecil yang mudah dibaca.

Intinya bukan memilih pemenang. "Engine dan tools" bukan baris asal-asalan. Ia harus mencantumkan apa yang dipermudah engine, apa yang menyulitkan, dan apa yang tidak akan kamu bangun.

Bagaimana menulis GDD untuk dunia yang membuat dirinya sendiri?

Ini celah yang hampir ada di setiap template. Mereka mengira kamu menaruh setiap pohon dengan tangan.

Saat dunia digenerate dari prompt, dokumen desain berubah bentuk. Kamu tidak lagi menentukan ruangan. Kamu menentukan batasan: apa yang harus benar di setiap dunia yang bisa dihasilkan engine, dan apa yang boleh bervariasi.

Tambahkan dua blok ke satu halaman:

• Batasan dunia. Aturan yang tidak boleh patah. "Setiap pemukiman punya air dalam dua menit berjalan kaki." "Tidak ada lokasi quest buntu."

• Benih prompt. Prompt persis yang kamu pakai, disimpan sebagai bagian dari dokumen.

Begini bentuk benih dalam praktik:

kota pelabuhan berkabut saat air surut, satu mercusuar, tangga sempit, jembatan tali antar atap, belum ada siapa pun yang terlihat

Simpan prompt-nya, simpan hasilnya, dan catat apa yang akan kamu fork. Prompt itu sekaligus spesifikasi dan changelog-mu. Fork, ubah satu hal, lihat apa yang terjadi, lalu tulis selisihnya di dokumen. Kebiasaan ini membuat dunia yang digenerate menjadi sesuatu yang bisa kamu nalar, dan memberi rekan tim sesuatu yang konkret untuk dikritik, bukan sekadar perasaan.

Satu peringatan: kualitas generasi sangat bervariasi antar alat, dan beberapa fitur masih beta di seluruh industri. Tulis versi dan tanggal di sebelah setiap benih, supaya kamu tahu apakah hasilnya bisa diulang atau cuma lemparan dadu yang beruntung.

Batasan dunia juga perlu diuji, bukan hanya ditulis. Ambil satu benih, generate lima hasil, dan periksa apakah setiap hasil memenuhi aturan yang kamu tulis. Kalau empat dari lima melanggar satu batasan, batasannya mungkin terlalu longgar, atau prompt-mu terlalu bebas. Keduanya bisa diperbaiki, tetapi hanya kalau kamu melihatnya di dokumen, bukan di kepala.

Cara cepat menguji loop sebelum menulis lebih banyak

Ini alur malam yang aku jalankan untuk ide baru.

1. Tulis satu halaman dalam 30 menit. Jangan diedit.

2. Ubah pitch dan tiga aturan dunia menjadi prompt, lalu generate draf pertama ruangnya.

3. Jalani core loop di ruang itu, dengan tangan atau di prototipe kasar.

4. Tandai setiap langkah yang terasa mati. Itu masuk pertanyaan terbuka.

5. Potong satu verb. Selalu potong satu.

Pemotongan itulah yang sering dilewatkan orang. Dokumen desain yang hanya tumbuh adalah daftar keinginan. Membuang satu verb memaksa verb yang tersisa memikul beban lebih, dan biasanya itu membuka sistem mana yang sebenarnya bekerja.

Setelah lima langkah itu, bandingkan dua hal: halaman sebelum dan sesudah pemotongan, dan catatan apa yang muncul di prototipe. Kalau halamannya jadi lebih pendek tapi loop-nya terasa lebih tajam, kamu berada di jalur yang benar. Kalau loop-nya jadi kabur, verb yang dibuang ternyata menopang sesuatu. Kembalikan, lalu tulis alasannya di bagian "ide yang dibunuh" supaya kamu tidak membuat kesalahan yang sama dua kali.

Bagaimana menjaga dokumen tetap hidup setelah minggu kedua?

Tiga kebiasaan, tidak ada yang heroik.

Beri tanggal pada setiap pertanyaan terbuka. Kalau sebuah pertanyaan sudah lebih dari tiga minggu dan belum terjawab, jawab sekarang, atau akui bahwa kamu sedang menghindarinya.

Perbarui dokumen di sesi yang sama dengan build. Bukan nanti. "Nanti" adalah cara fosil itu terbentuk. Mengedit dua baris di akhir sesi hanya memakan satu menit.

Simpan daftar "ide yang dibunuh" di bagian bawah. Daftar itu mencegahmu memperdebatkan mekanik yang sama tiap bulan, dan anehnya memotivasi melihat betapa banyak yang sudah kamu kirim hanya dengan berkata tidak.

Saat ada orang baru di proyek, berikan dulu versi satu halaman dan perhatikan di mana dia bingung. Setiap pertanyaan kebingungan adalah baris yang hilang dari dokumen.

Kalau kamu sendiri atau berdua, satu halaman dengan tujuh blok plus daftar benih prompt sudah cukup untuk bulan pertama. Kalau kamu punya tim, simpan satu halaman sebagai pintu depan dan tambahkan file terpisah untuk sistem dan konten saat prototipe membenarkannya. Kalau kamu punya publisher, berikan versi panjangnya, tapi tetap simpan satu halaman sebagai versi yang kamu percayai.

Buka halaman kosong malam ini dan tulis pitch-nya. Satu kalimat. Lalu loop-nya, dengan timer. Kalau kamu tidak bisa menyelesaikannya dalam setengah jam, idenya masih mimpi, dan itu berguna untuk diketahui sebelum kamu menghabiskan sebulan untuknya.