Full production adalah tahap ketika jumlah konten meningkat dengan cepat. Puluhan level mulai dibuat, character masuk pipeline, quest bertambah, dan biaya produksi ikut membesar.
Jika asumsi dasar proyek masih salah pada fase ini, perbaikannya bisa sangat mahal. Karena itu, Menggunakan Vertical Slice sebaiknya dipandang sebagai gerbang keputusan, bukan sekadar milestone presentasi.
Slice memberi kesempatan kepada developer untuk melihat apakah core experience, quality bar, workflow, dan scope benar-benar cocok dengan kapasitas proyek.
Satu potongan kecil yang representatif dapat mengungkap risiko yang tidak terlihat dalam design document maupun prototype sederhana.
Vertical Slice Harus Mewakili Core Experience
Tidak semua bagian game cocok dijadikan vertical slice.
Pilih pengalaman yang benar-benar merepresentasikan identitas produk.
Jika game adalah stealth-action, jangan membuat slice yang sebagian besar berisi walking sequence.
Jika game berfokus pada tactical combat, slice harus menguji combat tersebut dalam kondisi mendekati permainan sebenarnya.
Unity mendefinisikan vertical slice sebagai bagian kecil playable yang menunjukkan major systems, features, dan art dari keseluruhan game.
Karena itu, mulai dengan product pillars.
Misalnya:
combat berbasis positioning;
environment interaktif;
dan companion cooperation.
Slice harus membuktikan ketiga hal tersebut.
Jangan memilih bagian yang mudah dibuat hanya agar milestone terlihat sukses.
Vertical slice yang bagus justru sengaja menguji bagian yang paling menentukan keberhasilan proyek.
Gunakan Slice untuk Menetapkan Quality Bar
Kalimat seperti “visual harus AAA” atau “combat harus terasa premium” terlalu abstrak untuk production planning.
Vertical slice membuat target tersebut konkret.
Art director dapat menunjukkan kualitas environment yang dibutuhkan. Animator memiliki contoh fidelity final. Audio memahami kepadatan soundscape. QA mempunyai baseline performance.
Pada KILL KNIGHT, PlaySide membuat vertical slice visual terpisah untuk memvalidasi direction dan memastikan tone maupun technical execution berada pada target sebelum produksi penuh.
Setelah quality bar terlihat, tim bisa bertanya:
Berapa lama pembuatannya?
Apakah kualitas ini bisa direplikasi 30 kali?
Apakah hardware target mampu menjalankannya?
Quality bar bukan sekadar soal estetika.
Ia juga menentukan biaya.
Target visual yang 20% lebih tinggi kadang bisa menghasilkan beban produksi jauh lebih besar daripada 20%.
Ukur Apakah Pipeline Bisa Diskalakan
Satu kesalahan besar adalah menganggap keberhasilan membuat satu scene otomatis berarti tim bisa membuat 50 scene.
Mungkin scene tersebut selesai karena seluruh senior artist bekerja langsung di dalamnya.
Itu tidak scalable.
Vertical slice harus membantu membangun pipeline yang bisa digunakan oleh tim produksi yang lebih luas.
Game Developer menyebut tools, pipeline, dokumentasi, core systems, serta gameplay validation sebagai output penting pre-production.
Perhatikan hal praktis:
Berapa banyak manual handoff?
Berapa kali asset harus diperbaiki?
Apakah naming convention berjalan?
Apakah build automation stabil?
Apakah designer bisa membuat content tanpa selalu meminta programmer?
Jika pipeline membutuhkan lead developer untuk memperbaiki setiap content integration, full production akan cepat mengalami bottleneck.
Vertical slice seharusnya menemukan masalah tersebut lebih awal.
Uji Risiko yang Memiliki Efek Domino
Tidak semua risiko harus mendapat perhatian sama.
Prioritaskan risiko yang dapat memblokir banyak area proyek.
Misalnya game open world bergantung pada streaming technology.
Jika streaming tidak bekerja, environment scope, world density, art memory budget, AI, bahkan traversal bisa terkena dampak.
Karena itu, masukkan critical dependency tersebut ke slice.
Pendekatan vertical slice secara tradisional memang digunakan untuk mengurangi risiko membuat banyak konten yang kemudian harus diulang ketika asumsi inti berubah.
Game Developer mencatat bahwa metode tersebut membangun pengalaman polished dalam skala kecil sebelum bulk content diproduksi.
Semakin mahal efek domino sebuah kegagalan, semakin awal sistem itu harus diuji.
Jangan habiskan slice hanya untuk bagian yang sudah diketahui bisa dibuat.
Uji Scope dengan Production Rate Nyata
Design document mungkin mengatakan game membutuhkan 40 mission.
Tetapi apakah 40 realistis?
Vertical slice membantu menghitung content production rate.
Misalnya satu mission representatif membutuhkan tiga minggu sejak greybox sampai playable polished.
Namun produksi penuh tidak berarti 40 × 3 minggu karena pekerjaan dapat berlangsung paralel dan asset bisa digunakan kembali.
Tetap saja, angka tersebut memberikan baseline.
Pengembangan Guacamelee! memberi contoh nyata tentang penggunaan fase vertical slice sebelum produksi penuh: DrinkBox menyebut sekitar empat bulan preliminary prototyping, empat bulan tambahan untuk vertical slice, kemudian sekitar 18 bulan full production.
Tidak ada ratio waktu universal yang harus diikuti.
Insight yang penting adalah produksi skala besar dimulai setelah tim memperoleh pemahaman lebih baik terhadap game dan proses pembuatannya.
Slice memberikan data untuk menantang scope yang terlalu optimistis.
Gunakan Slice untuk Menentukan Apa yang Harus Dipotong
Vertical slice bukan hanya membuktikan apa yang harus dibuat.
Ia juga membantu menentukan apa yang tidak layak dibuat.
Bayangkan slice memiliki destruction, dynamic weather, companion AI, dan procedural encounters.
Setelah diuji, destruction menyerap 30% waktu engineering tetapi hanya memberi sedikit pengaruh pada pengalaman utama.
Itu kandidat pemotongan.
Lebih baik menemukan fakta tersebut sekarang daripada setelah destruction sudah diterapkan ke 15 level.
Unity Learn mengajarkan vertical slice sebagai milestone yang dibangun melalui prioritas fitur dan asset. Production plan mereka juga memisahkan milestone refinement dari milestone final yang fokus memperbaiki masalah serta visual polish tanpa menambah fitur baru.
Ini adalah prinsip penting: slice perlu mempunyai batas scope.
Jangan menjadikannya alasan menambah semua fitur menarik sebelum production.
Hindari Vertical Slice yang Terlalu “Palsu”
Ada risiko lain: slice dibuat sangat khusus untuk presentasi sehingga tidak mewakili cara game sebenarnya akan diproduksi.
Misalnya seluruh scene di-script secara manual.
AI hanya bekerja pada satu arena.
Loading disembunyikan.
Asset dibuat dengan metode yang tidak mungkin digunakan pada skala penuh.
Secara visual hasilnya bagus, tetapi risiko produksi belum divalidasi.
Slice yang dibuat untuk publisher memang perlu terlihat meyakinkan, namun tetap harus memberikan informasi internal yang jujur.
Game Developer memperingatkan bahwa tim dapat menghabiskan waktu terlalu besar pada polished vertical slice sampai mengurangi waktu yang sebenarnya dibutuhkan untuk perencanaan dan produksi.
Ukuran keberhasilan bukan “apakah demo terlihat luar biasa?”
Pertanyaannya adalah “apakah proses pembuatannya mencerminkan production reality?”
Buat Risk Register setelah Slice
Setelah build selesai, dokumentasikan semua temuan.
Kelompokkan risiko menjadi technical, design, content, pipeline, performance, resource, atau schedule.
Contohnya:
High Risk: multiplayer synchronization belum stabil.
Medium Risk: animation pipeline menghasilkan banyak rework.
Low Risk: UI style masih membutuhkan refinement.
Kemudian beri owner dan mitigation plan.
Dengan cara ini, vertical slice tidak berakhir sebagai file build yang tersimpan setelah presentasi.
Ia berubah menjadi data produksi.
Jika satu sistem memerlukan investigasi tambahan, masukkan ke milestone berikutnya sebelum content team mulai bergantung pada sistem tersebut.
Dokumentassi risiko sederhana bisa menyelamatkan banyak waktu karena pembelajaran slice tidak hilang di antara meeting dan pergantian anggota tim.
Gunakan Go, Pivot, atau Stop sebagai Hasil yang Sah
Banyak tim merasa vertical slice harus berakhir dengan keputusan “lanjut full production”.
Padahal tidak selalu.
Ada tiga hasil yang sama-sama valid.
Go: konsep, teknologi, pipeline, dan biaya terlihat cukup sehat.
Pivot: potensinya kuat tetapi beberapa aspek perlu berubah.
Stop: risikonya terlalu tinggi dibanding budget atau nilai produk.
Pre-production yang menemukan bahwa proyek tidak viable sebenarnya telah menghemat biaya besar.
Game Developer menggambarkan vertical slice sebagai gameplay validation yang membantu menentukan apakah proyek layak dipertimbangkan untuk masuk full production.
Karena itu, jangan menilai slice hanya berdasarkan seberapa bagus build-nya.
Nilailah berdasarkan kualitas keputusan yang bisa dibuat setelah melihat hasilnya.
Menggunakan Vertical Slice sebelum full production membantu tim memvalidasi quality bar, pipeline, scope, dependency, dan production rate ketika biaya perubahan masih relatif murah.
Bangun slice yang benar-benar mewakili core experience, bukan sekadar demo presentasi.
Setelah selesai, dokumentasikan risiko dan gunakan hasilnya untuk memilih apakah proyek siap dilanjutkan, perlu dipivot, atau harus dikurangi sebelum investasi membesar.