Iklan
My Journal

[Gamelog] Cara Membuat Game Design Document

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.

gdd sensor

Contoh Dokumen GDD

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.

Contoh penggunaan Trello buat ngerangkum GDD. Maap banyak yg disensor hehehe

Contoh penggunaan Trello buat ngerangkum GDD. Maap banyak yg disensor hehehe, rahasia perusahaan

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.

Iklan
About Adam Ardisasmita (1205 Articles)
CEO Arsanesia | Google Launchpad Mentor | Intel Innovator | Writer Dailysocial.id and Dicoding.com | Blogger ardisaz.com | Gagdet, Tech, and Community enthusiast.

14 Comments on [Gamelog] Cara Membuat Game Design Document

  1. Tri Sagirani // 25/03/2015 pukul 10:31 am // Balas

    Lagi-lagi saya dapat ilmu baru. Btw….boleh saya minta contoh template GDD nya pak??? thank’s sebelumnya

    Suka

  2. Kalau untuk app development, adakah dokumentasi semacam ini untuk guideline? Trus namanya apa, App Design Documentation kah hehehe..
    Thanks alot, tetep semangat sharing ya mas Adam

    Suka

  3. Reblogged this on Arrokh's.

    Suka

  4. hallo kak, boleh kasih referensi buat gdd tools nya ga ya?? soalnya saya lg thesis ngebahas nya 3 gdd tools buat game yg d kembangin kampus saya.
    terima kasih.

    Suka

  5. Salam maz ADAM, terima kasih banget loh.. awalnya saya memiliki beberapa ide yang ingin saya kembangkan bersama teman2. Otomatis saya research d mbah google, dan pas berbicara soal anggaran.. saya temukan situs maz ini. Perihal GDD ini maz.. jujur saya ingin sekali “kalau boleh”.. file GDD (template atau apalah…) yang ada maz pakai sebagai acuan dalam proses ini (walaupun udah 2x y maz bilang confidential, hehe..)

    tapi mungkin ada 1 or 2 file yang mungkin sudah tidak terpakai oleh maz, yang bisa saya jadikan bahan pembelajaran saya. “kalau boleh”… THANK U for the articles.

    ps :
    saya baru baca di “about” ternyata anda orang hebat !!!.. ^_^

    Zidon Johan

    Suka

  6. mas, saya mau tanya..
    kalau misalnya ada rencana mau buat prototype dulu apa GDD untuk prototype dan untuk versi fullnya dibedakan?

    Suka

  7. untuk buat sofware gdd kira2 coding bahasa yg mana mas

    Suka

  8. kak Adam, saya Alfan mahasiswa Teknologi Game PENS 2014 izin untuk mengutip artikel ini.

    Suka

1 Trackback / Pingback

  1. [GameLog] Tugas Seorang Game Tester Untuk Quality Assurance | Ardisaz

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: