Setahun yang lalu, saya sempat ngobrol-ngobrol dengan beberapa developer game di GDM yang sudah berhasil rilis gamenya. Pada saat itu saya bertanya:
Seberapa molor waktu pengerjaan gim yang dilakukan, dibandingkan dengan perencanaan di awal?
Rata-rata mereka menjawab waktu actual pengerjaan meleset dua hingga tiga kali lipat. Hal ini serupa dengan apa yang kita alami di Algorocks. Beberapa game kita memang molor hingga tiga kali lipat. Apa yang kita rencanakan akan selesai dalam enam bulan, molor menjadi dua tahun (meskipun ada tambahan spesifikasi).
Ngeri, kan? 🥲
Kalau waktu pengembangan molor, otomatis biaya juga ikut melambung. Dan kita tahu sendiri, mayoritas indie game developer biasanya belum punya modal yang kuat. Belum lagi kalau waktu pengerjaan molor, moral tim pasti ikut kena imbas.
Menurut studi dari McKinsey & Company, 17% proyek IT berakhir dengan kegagalan total, sementara 45% melebihi anggaran, dan 7% meleset dari jadwal lebih dari 200%. Kita beruntung Mckinsey tidak melakukan survei di GDM, karena hasilnya bisa jadi lebih jelek lagi 😁🙏
Hal ini sesuai dengan buku yang baru-baru ini saya baca dan berjudul “How Big Things Get Done” (Bent Flyvbjerg, Dan Gardner). Di buku ini diceritakan beberapa tips dan karakteristik proyek-proyek yang berhasil dan tepat waktu. Buku ini membahas tips dan karakteristik proyek-proyek besar yang sukses dan tepat waktu. Contohnya sih proyek mega, seperti terowongan bawah tanah atau gedung pencakar langit. Tapi ternyata, prinsip yang sama juga bisa diterapkan pada proyek yang lebih kecil, termasuk pengembangan game.
Mungkin tips-tips yang ada pada buku ini bukan hal baru, tapi yang bikin buku ini beda adalah cara mereka menyaring tips yang benar-benar punya dampak besar. Dan saya tahu dampaknya signifikan karena beberapa tips tersebut sudah kita pakai di Algorocks, namun kita menggunakan tips tersebut setelah beberapa kali “jatuh bangun”. Sekarang pengembangan game kita jauh lebih lancar. Andai saja saya baca buku ini beberapa tahun lalu, pasti bisa menghemat banyak waktu dan biaya! 🥲
Berikut adalah beberapa insights yang saya dapatkan dari buku How Big Things Get Done dan relevansinya pada pengembangan gim.
Think Fast, Act Slow Think Slow, Act Fast
Dua dari tiga proyek yang gagal disebabkan oleh perencanaan yang buruk (Riset dari The Standish Group). Dan jujur, kita nggak bisa bikin perencanaan yang baik kalau kita terburu-buru.
Kenapa kita sering terburu-buru dalam melakukan perancangan? Karena sering kali kita (baca: saya) tidak menganggap perancangan sebagai bagian dari progress. Sering kali kita ingin segera melihat bentuk ketika jadi. Padahal salah satu cara paling utama untuk membuat proses pengembangan gim lancar jaya adalah dengan memastikan perancangan dilakukan dengan baik. Ingat, revisi ketika perancangan membutuhkan biaya yang jauh lebih murah daripada revisi ketika game sudah jadi.
Tapi terlalu lama dalam perencanaan juga tidak baik. Terlalu banyak waktu yang dihabiskan untuk perencanaan dapat menyebabkan tim kehilangan momentum dan motivasi. Selain itu, perencanaan yang berlebihan sering kali menghasilkan detail yang mungkin tidak relevan atau justru menjadi “usang” seiring dengan perkembangan proyek.
Jadi kapan kita dianggap terburu-buru dan kapan kita dianggap terlalu lama? Jawabnya tentu bergantung pada gim yang akan kita buat (dan budget yang ada). Tapi sebagai patokan, menurut saya pribadi perencanaan seharusnya dilakukan sekitar 20-30% dari total waktu pengembangan gimnya. Jika kita rencanakan total waktu pengembangan gim adalah 6 bulan, maka waktu perencanaannya sekitar 4-6 minggu. Tapi sekali lagi, ini sangat bergantung dari jenis gim dan kondisi studio yang membuat. Game casual untuk mobile misalnya, membutuhkan waktu perencanaan yang jauh lebih singkat.
Mulai dari Kanan ke Kiri
Ini bukan tentang menulis huruf hijaiyah, tapi tentang memvisualisasikan hasil akhir dulu, lalu merunut ke belakang. Dengan fokus pada hasil akhir, kita memiliki visi yang lebih jelas tentang pengalaman apa yang ingin kita berikan ke pemain. Dengan fokus dengan hasil akhir terlebih dahulu, kita akan dipaksa untuk berfikir hasil akhir apa yang kita inginkan. “Experience apa yang ingin dihadirkan?”, “Bagaimana bentuk art stylenya?”, “Apa yang menarik untuk pemain?”
Ini juga mengapa pendekatan membuat trailer di awal (setelah validasi core gameplay dan art syle), menjadi suatu pendekatan yang menarik. Saya pertama kali mengenal konsep membuat trailer di awal game development dari video Derek Lieu (Cek video Derek Lieu disini). Setelah melihat video ini, saya langsung dengan impulsive, collaborative, dan abusive memutuskan untuk game kita berikutnya (Teeny Tiny Tank) kita akan fokus pada membuat trailer di awal. Pada saat ini trailer tersebut belum jadi. Namun efek positif dari membuat trailer di awal sudah sangat terasa.
Dengan membuat game trailer di awal, kita dipaksa untuk berpikir “apa yang menarik untuk ditampilkan di game ini?” dan bukan fokus pada mekanik saja. Membuat trailer di awal juga membuat tim memiliki visi yang lebih jelas tentang gim apa yang akan dibuat. Belum lagi tentunya dengan adannya trailer di awal, kita juga bisa segera mengumpulkan wishlist.
Prototyping
Membuat game itu penuh risiko. Apa yang kita bayangkan menyenangkan belum tentu terasa sama ketika sudah jadi. Salah satu cara terbaik untuk mengurangi risiko adalah dengan membuat prototipe. Prototipe membantu kita menguji gameplay dan validasi art style sebelum masuk ke tahap yang lebih jauh.
Misalnya, jika kita ragu apakah core gameplay yang dirancang akan memberikan pengalaman sesuai harapan, kita dapat membuat prototipe sederhana menggunakan bentuk dasar atau assets dari internet. Dengan cara ini, kita bisa langsung menguji dan merasakan apakah gameplay tersebut memenuhi ekspektasi. Untuk validasi art style kita bisa posting di media sosial beberapa art-style yang berbeda dan melihat responnya. Tentunya kita harus punya benchmark respon yang dianggap bagus itu seperti apa.
Membuat prototype itu memang membutuhkan waktu (dan tentunya biaya). Tetapi dibandingkan dengan resiko yang kita hindari, waktu dan biaya ini akan terhitung sangat murah.
Libatkan orang yang berpengalaman
Libatkan orang yang berpengalaman. Atau mungkin lebih tepat: libatkan orang yang berpengalaman (dan sudah sukses) MESKIPUN HARUS MEMBAYAR LEBIH MAHAL.
Pengalaman saya pribadi, kita bisa menghemat biaya dan waktu hingga 50% karena melibatkan seseorang yang memang berpengalaman dan mampu di bidangnya. Bukan hanya itu, proses development juga terasa lebih lancar karena kita jarang sekali harus “redo” apa yang sudah kita kerjakan. Proses yang lancar ini akan meningkatkan moral tim kita.
Tim yang baik adalah “Koentji”
Bayangkan sebuah lomba dayung dimana kapalnya yang dikemudikan oleh kru yang tidak seirama; Sebagus-bagus kapalnya, pasti perfomanya tidak akan maksimal. Tim yang bagus bukan cuma yang punya skill teknis, tapi juga visi yang sama dan bisa berlari dengan kecepatan yang sama.
Ada penelitian yang mengatakan satu orang toxic pada suatu perusahaan akan mempengaruhi paling tidak lima orang lainnya (sumber: trust me). Oleh karena itu hindari “toxic people”. Mereka seperti lubang di kapal—satu saja sudah bisa membuat kapal tenggelam. Sering kali, mengeliminasi satu orang toxic jauh lebih baik daripada menyimpan masalah di kemudian hari.
Company is literally group of people. Semakin baik orang-orangnya, semakin baik kerja samanya, semakin baik company-nya. Jika ada anggota tim yang tidak bekerja dengan maksimal dan tidak dapat diperbaiki, sebaiknya segera dikeluarkan. Apa yang kadang kita anggap “menolong” atau “tidak tega” sebanarnya tidak fair untuk anggota tim lainnya dan juga pada orang tersebut. Ingat, bisa jadi seseorang yang tidak cocok pada tim kita akan cocok pada tim di perusahaan lain (begitu pula sebaliknya).
Temukan bagian “Lego” pada proyek kita
Ada banyak keutungan dengan melihat gim kita sebagai kumpulan modul-modul.
Satu, dengan membagi gim kita sebagai modul-modul kita bisa fokus mengerjakan satu modul terlebih dahulu, lalu menggunakan modul yang sudah selesai untuk bagian-bagian yang lain. Misalnya kita bisa fokus pada membuat satu level dengan baik, lalu menggunakan modul tersebut untuk level-level lainnya. Atau kita bisa menganggap satu deck kartu sebagai suatu modul, dan ketika experience deck kartu tersebut sudah baik, kita gunakan deck tersebut untuk membuat deck-deck lainnya.
Dua, dengan membagi gim kita menjadi modul-modul, maka kita juga bisa menggunakan modul tersebut untuk proyek yang lain. Misalnya pada game kita, “Dadoo”. Dadoo adalah permainan multiplayer yang menggabungkan ular tangga dengan card game/deckbuilder. Dengan melihat unsur deckbuilder/card game sebagai suatu modul, kami bisa menggunakan modul tersebut utnuk game kami selanjutnya “Teeny Tiny Tank” yang merupakan gabungan tower defense dengan card game.
Penutup
Pengembangan game, seperti halnya proyek besar lainnya, adalah perjalanan yang penuh dengan tantangan. Namun, tantangan tersebut bukanlah sesuatu yang harus ditakuti, melainkan peluang untuk belajar, berinovasi, dan tumbuh.
Buku “How Big Things Get Done” mengajarkan kita bahwa sukses dalam proyek besar bukan tentang memiliki sumber daya yang melimpah atau teknologi tercanggih, tetapi tentang bagaimana kita merencanakan, beradaptasi, dan berkolaborasi dengan tim.
Sebagai penutup, ingatlah besarnya tantangan dalam membuat gim juga merupakan peluang karena artinya tidak semua orang bisa membuat gim dengan mudah. Siapa yang bisa memecahkan “formula”-nya adalah orang yang akan sukses. Selamat berkarya, dan semoga setiap game yang kita buat membawa kita semakin dekat dengan impian kita!