Siapa yang males membuat dokumentasi? Jawabannya mungkin hampir semua developer males bikin dokumentasi. Jauh lebih seru eksekusi (coding, gambar, dll) dibandingkan ngetik-ngetik dokumen di word. Banyak yang kalau baru denger kata dokumen aja udah mau muntah :p hahaha

Tapi dalam proyek software, dalam hal ini game, keberadaan Game Design Document itu sangat penting. Mengapa? Yang pertama adalah proyek pengembangan game biasanya cyclenya panjang (minimal 3 bulan). Dalam cycle yang panjang itu, scope bisa berubah-ubah, fitur atau definisi bisa aja ada yang lupa, dan lain sebagainya. Mau ada weekly meeting pun, bisa aja hasil weekly meeting tiap minggu berubah-ubah sehingga game gak kelar-kelar.

Ditambah lagi game development itu multidisiplin. Ada programmer, ada artist, ada game designer, ada animator, ada music composer, dan lain-lain. Satu kata atau kalimat bisa multitafsir dan bisa bikin miss comunication kalau gak didefinisikan dengan baik. Adanya GDD adalah sebagai kitab acuan agar scope tidak melebar kemana-mana, proyek bisa ditrace sudah sampai mana, dan yang paling penting semua orang on the same page tentang apa yang mau dibuat.

Pertanyaan besarnya adalah apa sih isinya GDD dan gimana cara bikinnya? Sekitar tiga-empat tahun yang lalu saya sempat cari-cari referensi dan tidak menemukan standar bakunya. Ada dokumen yang tebalnya ratusan halaman ada yang cuma beberapa lembar. Yang bener yang mana? Gak ada yang salah, karena GDD itu ternyata dinamis bergantung dengan game dan kebutuhannya.

Pertama-tama, saya sempat membuat GDD yang dirancang menggunakan dokumen yang cukup tebal. Di awal agak kerjaan karena harus mentranslasi semua fitur, interaksi, layar, dan elemen di dalam game ke dalam satu dokumen. Dengan template yang saya gunakan, biasanya dibagi jadi beberapa bab.

Bab 1: Game Overview

Di bab ini biasanya cuma sehalaman, menjelaskan gamenya tentang apa, cerita besarnya gimana, genre-nya apa, untuk platform apa, dan lain-lain. Jadi orang yang baca halaman ini bisa langsung ngeh, oh ini game begini toh. Biasanya di sini saya kasih menu flow biar kebayang berapa layar di dalam game ini jadi orang langsung dapet seberapa besar game ini.

Bab 2: Core Gameplay

Di bab ini isinya adalah rule dan core game. Misalkan gamenya Angry Bird, berarti isinya adalah core game berupa repetisi dari melempar burung yang dipengaruhi gravitasi. Beberapa rule yang ada di dalamnya misalkan ada rule fisika berupa gravitasi, tumbukan dengan objek, dan lain sebagainya. Lalu ada rule urutan burung predefine, level development berdasarkan apa, dan yang paling penting objektif dari core gamenya apa. Kalau Angry Bird, objektif utamanya ngebunuh babi, objektif keduanya ngehancurin banyak objek, dan objektif ketiganya adalah ngumpulin item.

Bab 3: Game Mechanic and Interaction

Bab ini yang mulai agak ribet, karena tiap rule dan komponen mekanik di dalam game harus didefinisikan di sini. Setiap tombol memberikan efek apa, kalau user beli item A tapi gak cukup uangnya keluar layar apa, kalau user pakai senjata B dikombinasikan dengan senjata C jadi apa, kalau user nyangkul tanah tapi ternyata ada batunya di layar keluar apa, dan lain sebagainya. Setiap opsi yang bisa dilakukan di dalam game harus dijelaskan kondisinya.

Salah satu tantangan terberat di bab ini adalah balancing. Kita harus menghitung misalkan ada currency di dalam game, bagaimana economic system di game ini. Berapa harga yang sesuai untuk tiap item, berapa pendapatan pemain setiap kali main, seberapa besar effort pemain sehingga layak mendapatkan sejumlah uang dan lain-lain. Belum lagi juga harus balancing untuk rule-rule yang lain di dalam game, terutama untuk level development.

Bab 4: Wireframe

Bab ini sebenernya gak sulit, tapi banyak. Semua mekanik yang sudah didefinisiin di Bab 3 (biasanya dalam bentuk flow chart), harus dibuat representasinya untuk masing-masing layar. Layar loading, layar menu, layar gameplay, layar konfirmasi pembayaran, layar feedback, dan lain sebagainya. Tapi gak dalam bentuk udah berwarna dan ada objeknya, cukup kotak-kotak aja kok dalam bentuk wireframe. Biasanya saya pakai software Omnigraffle untuk bikin wireframe.

Bab 5: Game Module Breakdown

Nah ini yang agak menantang karena kita harus membuat list untuk masing-masing anggota tim. Untuk programmer harus dibuatin modul-modulnya apa aja, untuk artist harus dibikin list visual aset yang perlu dibuat apa aja (game terakhir itu saya bikin list aset sampai 500an benda saya list), animasi apa saja yang perlu dibuat, sfx apa saja yang ada, dan lain-lain

---

Jadi banyak banget kan? Hahaha Biasanya saya butuh 2-3 minggu untuk menyelesaikan GDD untuk game yang scope pengerjaannya 2-3 bulan. Jadi emang makan waktu banget ngerjain GDD itu. Terus balik lagi, ujung-ujungnya GDD dibaca gak? Dijadikan rujukan gak? Waktu pertama banget, GDD gak berhasil jadi rujukan padahal udah capek-capek dibuat. Kenapa? Karena sepanjang perjalanan banyak banget perubahan (mungkin karena masih baru bikin GDD jadi belum kebayang apa aja komponen di dalam game).

Akhirnya kita pindah ke Trello  Saya pernah ngejalanin proyek satu cycle hanya pakai Trello. Jadinya sih enak, semua terkontrol dan terukur. Tapi jadinya kita gak bisa dapet big picture dari game itu dan yang ada backlog dari fitur yang mau dibikin nambah terus :p hahaha. Buat game designer (dan client) butuh GDD, tapi buat yang ngerjain lebih enak pakai Trello, akhirnya sekarang saya kombinasikan keduanya.

GDD tetap saya bikin full untuk satu game. Jadi ketahuan kalau ada change request, pergeseran timeline dan deadline, hingga scope creeping. Buat ke client juga jadi lebih enak diskusi apa yang bisa ditambah apa yang enggak. Mana yang prioritas mana yang bukan. Nah untuk ke tim, saya modelnya tetap pakai weekly meeting dan pekerjaannya dipecah-pecah ke trello. Jadi daripada pusing baca GDD setebel itu, semua yang perlu dilakukan sudah dibagi-bagi permodul di Trello dan siap dikerjakan. So far sih efektif pakai itu. Jadi silahkan dicoba yah 🙂

Sebenernya saya pengen share template GDD yang pernah dibuat, tapi karena most of GDD confidential dan tiap GDD beda-beda strukturnya (bergantung jenis game-nya), jadi semoga dengan ulasan singkat di artikel ini bisa kebayang yah apa gunanya GDD dan kurang lebih backbone GDD itu seperti apa. Semoga bermanfaat.