Membuat game dengan banyak karakter, map, quest, sistem progression, multiplayer, hingga fitur Live Ops memang terdengar menarik.
Masalahnya, semakin besar scope, semakin banyak pula dependency, risiko teknis, dan pekerjaan lintas tim yang harus disinkronkan.
Di sinilah Strategi Production Planning berperan penting. Production plan yang baik bukan sekadar kalender berisi tanggal deadline.
Ia membantu tim menentukan apa yang benar-benar harus dibuat, urutan pengerjaan yang masuk akal, milestone yang dapat diuji, serta bagian mana yang perlu dipotong ketika biaya atau waktu mulai melenceng.
Mulai dengan Mendefinisikan Scope secara Konkret
Kalimat seperti “kita akan membuat action RPG open world besar” belum cukup menjadi scope.
Tim perlu menerjemahkannya menjadi komponen yang dapat diestimasi: jumlah region, tipe musuh, weapon class, quest, cinematic, sistem crafting, multiplayer feature, UI, audio, localization, hingga target platform.
Semakin konkret breakdown-nya, semakin mudah produser melihat biaya sebenarnya.
Atlassian mendefinisikan scope creep sebagai bertambahnya pekerjaan di luar scope awal tanpa penyesuaian yang sepadan terhadap waktu, budget, atau resource. Masalah ini sering muncul melalui permintaan kecil yang tampak masuk akal tetapi terus menumpuk.
Karena itu, buat juga daftar out of scope.
Menuliskan fitur yang tidak akan dibuat terkadang sama pentingnya dengan menentukan fitur yang akan dibuat. Batas tersebut mencegah ide menarik berubah menjadi pekerjaan tambahan tanpa keputusan formal.
Pecah Scope Menjadi Milestone yang Bisa Dinilai
Game kompleks sulit dikendalikan jika tim hanya mempunyai satu target besar bernama “launch”.
Gunakan milestone sebagai titik validasi.
Unity menyarankan milestone pertama dibuat dengan scope yang fokus, berisi fitur berprioritas tinggi dan critical dependencies. Jika jumlah core feature terlalu banyak, pekerjaan dapat dibagi ke beberapa milestone agar waktu lebih mudah dikelola.
Jangan Jadikan Milestone Sekadar Tanggal
Milestone harus mempunyai kondisi keberhasilan.
Misalnya “Combat Milestone selesai 15 Mei” masih terlalu kabur.
Lebih jelas jika kriterianya adalah: basic melee combat playable, tiga archetype musuh berfungsi, damage feedback tersedia, controller support bekerja, dan build lolos smoke test.
Dengan begitu, semua tim memahami arti kata “selesai”.
GDC Production Workshop 2026 menggambarkan fase production sebagai rangkaian beberapa milestone menuju Alpha, termasuk user testing, pemeliharaan schedule, dan pembaruan delivery plan selama produksi.
Gunakan Vertical Slice untuk Menguji Asumsi Besar
Salah satu risiko proyek game kompleks adalah membuat banyak konten sebelum pipeline dan gameplay utamanya benar-benar terbukti.
Vertical slice membantu mengurangi risiko tersebut.
Buat satu bagian kecil yang mendekati kualitas target akhir. Misalnya satu quest lengkap dengan environment, combat, enemy AI, animation, VFX, UI, dialogue, audio, save system, dan performance target.
Tujuannya bukan membuat demo cantik untuk dipamerkan saja.
Vertical slice harus menjawab pertanyaan produksi: berapa lama membuat satu level? Apakah pipeline art bekerja? Apakah teknologi mampu mencapai target visual? Berapa banyak revisi yang dibutuhkan?
GDC Production Workshop menempatkan first playable dan vertical slice sebagai deliverable penting pre-production, bersama tools, pipeline, core mechanics, game loops, serta detailed production plan dan revised budget.
Data dari slice kemudian dapat digunakan untuk memperbaiki estimassi produksi keseluruhan.
Petakan Dependency sebelum Membuat Timeline
Tidak semua pekerjaan dapat berjalan paralel.
Animator mungkin membutuhkan rig. Level designer membutuhkan gameplay systems. UI membutuhkan data dari backend. QA membutuhkan build yang cukup stabil untuk diuji.
Jika hubungan tersebut tidak dipetakan, sebuah task kecil dapat menghentikan banyak tim.
Atlassian menjelaskan bahwa dependency mapping membantu meningkatkan scheduling accuracy, resource planning, dan risk management karena tim dapat melihat urutan pekerjaan serta titik handoff yang kritis.
Cari Critical Dependency
Tidak semua dependency memiliki dampak sama.
Prioritaskan sistem yang memblokir banyak pekerjaan lain.
Misalnya inventory backend mungkin bukan fitur paling menarik secara visual, tetapi jika crafting, loot, equipment, shop, quest reward, dan save system semuanya bergantung padanya, keterlambatan sistem tersebut dapat menyebar ke seluruh proyek.
Production planning harus melihat impact of delay, bukan hanya ukuran task.
Prioritaskan Fitur Berdasarkan Nilai dan Risiko
Ketika scope besar, semua orang mempunyai fitur favorit.
Namun tidak semua fitur mempunyai nilai yang sama terhadap identitas game.
Buat kelompok sederhana seperti Must Have, Important, Nice to Have, dan Post-Launch Candidate. Dengan struktur ini, tim sudah mengetahui fitur apa yang bisa dikurangi ketika schedule mulai tertekan.
Jangan menunggu tiga bulan sebelum launch baru membicarakan pemotongan.
GDC Production Workshop bahkan menempatkan decisiveness untuk memotong fitur demi menjaga release date sebagai salah satu kemampuan penting produksi, sekaligus menunjukkan bahwa kompromi scope, timeline, budget, dan quality adalah bagian nyata dari pekerjaan produser.
Prioritass juga sebaiknya mempertimbangkan ketidakpastian.
Sistem networking eksperimental mungkin perlu dibuktikan lebih awal daripada cosmetic customization yang relatif mudah diprediksi.
Gunakan Capacity, Bukan Optimisme, untuk Membuat Sprint
Production schedule sering gagal karena dirancang berdasarkan kondisi ideal.
Semua orang diasumsikan tersedia penuh, tidak ada bug besar, tidak ada sick leave, dan tidak ada revisi desain.
Kenyataannya berbeda.
Scrum Guide menjelaskan bahwa forecast pekerjaan menjadi lebih percaya diri ketika developer mempertimbangkan performa masa lalu, kapasitas yang akan tersedia, serta Definition of Done.
Jika tim rata-rata menyelesaikan 80 unit pekerjaan per sprint, jangan merencanakan 130 hanya karena deadline mendekat.
Overcommitment biasanya tidak membuat tim tiba-tiba lebih cepat.
Ia hanya memindahkan masalah ke sprint berikutnya dan membuat estimasi semakin tidak dapat dipercaya.
Terapkan Change Control untuk Ide Baru
Perubahan tidak bisa dihindari dalam game development.
Playtest mungkin menunjukkan combat tidak menyenangkan. Publisher meminta target platform tambahan. User research menemukan onboarding sulit dipahami.
Masalahnya bukan adanya perubahan, tetapi perubahan tanpa trade-off.
Atlassian merekomendasikan scope baseline dan change control agar permintaan baru dinilai berdasarkan dampaknya terhadap waktu, biaya, dan resource.
Setiap permintaan besar sebaiknya menjawab tiga pertanyaan:
Apa nilai perubahan ini?
Berapa biaya dan dependency-nya?
Apa yang harus dipindahkan atau dikurangi sebagai konsekuensinya?
Prinsipnya sederhana: new scope requires a new trade-off.
Cara ini menjaga kreativitas tanpa membiarkan perencanan berubah menjadi daftar keinginan yang terus bertambah.
Buat Production Plan sebagai Dokumen Hidup
Timeline enam bulan lalu hampir pasti tidak sepenuhnya akurat hari ini.
Production plan perlu diperbarui berdasarkan velocity, milestone results, technical discoveries, hiring, outsourcing, dan playtest.
Namun jangan mengubah baseline diam-diam setiap kali proyek terlambat.
Simpan versi awal agar tim dapat memahami penyebab perubahan.
Dengan dokumentasi seperti itu, produser dapat melihat apakah masalah berasal dari estimasi buruk, dependency tersembunyi, revisi berulang, scope creep, atau kapasitas tim.
Production planning akhirnya bukan tentang menebak masa depan secara sempurna.
Tujuannya adalah membuat ketidakpastian terlihat cukup awal sehingga tim masih mempunyai pilihan sebelum masalah menjadi krisis.
Strategi Production Planning membantu proyek game kompleks tetap terkendali dengan memecah scope menjadi milestone, menguji asumsi lewat vertical slice, memetakan dependency, dan mengatur perubahan secara disiplin.
Jangan mengejar rencana yang terlihat sempurna di spreadsheet. Bangun sistem perencanaan yang dapat beradaptasi dengan kenyataan produksi, lalu review milestone secara rutin sebelum scope dan schedule mulai menjauh.