Menyunting Dokumen Desain Game

===Pengantar===
Dokumen Desain Game, atau dalam bahasa Inggris disebut Game Desin Document (GDD) keberadaannya sangat penting. GDD menjadi berkas 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. Karena biasanya proyek pengembangan game cyclenya panjang (minimal 3 bulan). Sehingga scope bisa berubah-ubah, fitur atau definisi bisa aja ada yang lupa.

Alasan lainnya adalah pengembangan game yang melibatkan 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. 

Isi dari GDD itu dinamis bergantung dengan game dan kebutuhannya. Namun secara garis besar, dari semua isi yang ada akan terbagi menjadi 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. Jadi orang yang baca halaman ini bisa langsung memahami maksudnya. Biasanya di sini terdapat 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 game 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 dalam bentuk wireframe. Biasanya 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