Apa yang saya pikirkan adalah seberapa lengkap dokumen desain Anda sebelum memulai implementasi proyek? Saya sedang berbicara tentang proyek-proyek menengah hingga sangat kecil dengan tim yang sangat kecil di sini di mana bahkan sepenuhnya menyempurnakan seluruh dokumen mungkin hanya beberapa lusin halaman.
Apakah Anda mulai dengan kerangka kerja kasar dan mulai menyempurnakan rincian pada saat implementasi yang sama mulai?
Apakah Anda benar-benar menyempurnakan setiap bagian sepenuhnya sebelum implementasi bahkan dimulai? Jika demikian, berapa persen perubahan yang Anda lihat setelah implementasi dimulai?
Jika Anda memiliki pengalaman dengan salah satu dari dua skenario yang saya uraikan, saya ingin mendengar pendapat Anda tentang masalah apa yang terjadi pada rute tertentu dan apa kendala yang menurut Anda membantu Anda hindari.
Jawaban:
Jika ide permainan sangat didasarkan pada beberapa konsep gameplay yang tidak biasa , saya prototipe itu segera dari awal, menggunakan proyek sebelumnya sebagai templat. 95% dari waktu ini mengarah pada menyadari bahwa itu tidak menyenangkan seperti yang saya bayangkan, dan untuk membuatnya menyenangkan akan membutuhkan lebih banyak sumber daya daripada nilainya.
Jika saya sedang mengerjakan proyek lain sementara itu, saya mengambil waktu saya, membuat orat-oret untuk mendapatkan gambaran seperti apa prototipe itu seharusnya (cobalah untuk tidak terganggu oleh sketsa seni). Kemudian saya membaginya dengan teman-teman, sebagian untuk melihat apakah mereka memiliki masukan, tetapi sebagian besar untuk membuat diri saya memikirkan hal-hal yang tidak jelas segera (selalu ada banyak hal, bahkan untuk orang-orang terpandai memikirkan ide-ide sederhana). Setelah beberapa jam seperti ini, saya akan menuliskan beberapa konsep kunci yang harus ada dalam arsitektur, secara harfiah ~ 20 kata. Lalu saya bisa membuat prototipe ketika saya punya waktu.
sumber
Saat ini desain game saya sudah cukup detail sebelum memulai.
Saya akan menyempurnakan sebagian besar kelas penting, menggambar beberapa mock-up (gambar biasanya mengerikan), melakukan deskripsi permainan.
Meskipun ini terutama karena memiliki perjalanan yang panjang untuk bekerja, dan tidak ada lagi yang harus dilakukan. Saya lebih suka menghabiskan lebih sedikit waktu untuk melakukan ini, dan lebih banyak waktu pemrograman, karena menyempurnakan kelas yang kemungkinan besar akan berubah sepertinya berlebihan.
sumber
Bekerja pada tim kecil di permainan kecil (tim satu orang di permainan kasual kecil), saya pindah dari "desain berat" ke "desain cepat." Saya menemukan pengembangan berulang (dua minggu fokus pada satu tujuan, misalnya gameplay inti) membantu menyempurnakan desain, dan memberi Anda sesuatu untuk dimainkan, yang berarti Anda tidak akan mengubah pikiran dan membatalkan 90% dari apa yang Anda rancang tampak bagus "di atas kertas" tetapi tidak dalam game.
Karena itu, saya menghabiskan sebagian besar waktu desain saya di gameplay inti dan mekanik (bagaimana permainan utama akan berfungsi), dan itu jarang berubah banyak - itu mendapat tweak dan kadang-kadang saya mengambil ide-ide baru atau menjatuhkan ide-ide lama; tetapi tidak ada yang berjalan tanpa prototipe yang berfungsi.
Di sisi teknis, apa pun harus mendapatkan setidaknya beberapa menit sebelum membuat kode nyata. Tapi, Anda selalu bisa refactor nanti.
sumber
Dokumentasi desain memiliki biaya pemeliharaan; karena hal berubah Anda harus kembali dan membaca kembali dan memperbarui dokumen yang ada. Dengan demikian, itu harus menjadi tujuan produksi untuk meminimalkan jumlah dokumentasi yang dapat dipelihara karena akan memaksimalkan waktu yang dihabiskan untuk benar-benar membangun permainan.
Dari sana, berarti Anda tidak ingin merancang semuanya sampai ke detail terkecil sebelumnya, karena Anda tahu betul bahwa setengahnya akan berubah, dan kemudian Anda akan berurusan dengan banyak waktu yang terbuang. Lakukan desain minimum yang diperlukan untuk mulai membuat game inti. Setelah selesai, ulangi sesuai kebutuhan, lalu ulangi proses untuk setiap fitur baru.
sumber