Bagaimana Anda mempersiapkan fitur creep?

Bagaimana saya bisa bersiap untuk fitur creep selama praproduksi?

Creep fitur adalah ketika Anda berada dalam fase produksi dan memutuskan "Akan keren jika ini fitur!" Itu menambah n jam ke waktu pengembangan yang tidak diperhitungkan, dan kecuali Anda Blizzard, tidak punya waktu untuk. Anda tidak dapat menganggapnya sebagai fitur keren selama praproduksi, karena fitur ini hanya ditemukan selama produksi.

Apa yang dapat saya lakukan selama praproduksi untuk memperhitungkan atau mencegah atau mempersiapkan creep fitur?

Haruskah saya mengizinkan fitur creep dan memotong fitur yang kurang diinginkan? Atau akankah ini menimbulkan masalah karena arsitekturnya tidak dirancang untuk fitur-fitur baru? Haruskah saya mengatakan tidak ada fitur kecuali mereka cocok dengan arsitektur yang ada?

Saya tahu ini adalah pertanyaan luas, tapi saya harap itu tidak ditutup seperti itu. Ini adalah masalah utama dalam pengembangan game, dan harus dipertimbangkan.

Meskipun tentu saja tidak ada aturan keras mengenai pra-produksi, ada berbagai heuristik untuk membantu. Beberapa fitur merayap adalah wajar dan perlu - tidak ada rencana yang bertahan kontak pertama dengan kenyataan, dan Anda mungkin tidak tahu apa yang akan "keren" sampai Anda melihatnya.

Pertama, tahapkan perkembangan Anda. Gambar garis besar Anda menjadi peta fitur, dan kemudian cari cara untuk mengelompokkan fitur Anda ke dalam iterasi yang dapat diuji , masing-masing dengan tenggat waktu . Setelah Anda memulai iterasi, tahan untuk menambahkan fitur baru ke dalamnya. Setiap kebutuhan teknis yang tidak terduga tentu saja harus masuk ke iterasi saat ini, tetapi ide - ide baru untuk fitur harus masuk ke daftar untuk dipertimbangkan di masa depan. Anda kemudian dapat mempertimbangkan apakah akan menambahkannya ke iterasi setelah yang sudah selesai.

Ini mengikuti dari metode MoSCoW , di mana Anda mengategorikan fitur seperti:

• Harus memiliki - fitur yang penting untuk iterasi saat ini menjadi stabil , yang bisa dikatakan dapat diuji . Jika iterasi tidak akan berfungsi tanpanya, itu harus ada.
• Harus memiliki - fitur yang harus dilakukan pada beberapa titik, tetapi jika iterasi berjalan seiring waktu dapat didorong ke iterasi berikutnya . Hal-hal yang diperlukan oleh penerbit, misalnya, bisa buka di sini.
• Bisa memiliki - fitur yang menurut Anda mungkin penting untuk iterasi saat ini tetapi dapat dibatalkan dari proyek. Ini semua adalah fitur pemoles yang penting .
• Tidak akan memiliki - item yang berpotensi mengumpankan simpanan , fitur yang diidentifikasi dalam iterasi ini untuk dipertimbangkan untuk iterasi selanjutnya.

Idealnya Anda ingin pembangunan menjadi penyempurnaan progresif, bukan semua atau tidak sama sekali. Bekerja dalam tenggat waktu akhir, fitur yang paling tidak penting harus didorong sampai akhir, jadi apa pun yang Anda tidak dapatkan akan menjadi hal yang boleh dipotong. Pastikan untuk memperkirakan berapa lama setiap fitur akan diperlukan untuk mengembangkan dan memperbaiki estimasi tersebut saat Anda berjalan. Jangan pernah kompres jadwal untuk memberikan ruang bagi lebih banyak fitur. Tolak mendorong tenggat waktu (iterasi atau final) ke masa depan - pindahkan atau potong fitur, jika mungkin. Jika Anda mencapai tenggat waktu dan permainan masih berantakan, maka Anda tahu sudah saatnya untuk mengevaluasi kembali keputusan Anda secara serius dan mempertimbangkan untuk membatalkan proyek sebelum berubah menjadi jurang waktu / uang.

• Rencanakan untuk menggunakan sebagian kecil dari waktu pra-produksi yang tersedia untuk set fitur dasar.
• Basis featureset harus rendah berisiko, fitur high-reward, sehingga Anda tidak memiliki merayap di mereka
• Setel fitur dasar minimal dan tidak dapat dinegosiasikan - harus ada - jika tidak ada dasar yang solid untuk bekerja dan Anda akan diliputi keraguan diri / sindrom "haruskah saya mengganti ini"
• Pastikan iterasi paling awal dari gim Anda cukup menarik sehingga Anda dapat membeli fitur creep. Gim yang pada dasarnya tidak mengesankan tidak akan berhasil, apalagi dengan creep.
• Ketahui terlebih dahulu berapa margin creep yang Anda mampu, jadi Anda bisa menggunakan margin itu dengan bijak.
• Gunakan teknologi yang dibangun sebelumnya dan sangat umum seperti Unity, dan gunakan secara kanonik untuk meningkatkan fleksibilitas sehingga fitur creep tidak terlalu berdampak pada arsitektur yang ada
• Jangan membangun subsistem yang rumit - pendekatan Pemrograman eXtreme cocok di sini
• Mintalah orang lain (perancang & pembuat kode) yang otaknya dapat Anda ketuk secara berkala untuk membantu Anda memprioritaskan fitur mana yang akan Anda biarkan merayap, mintalah seseorang yang berpengalaman meninjau kode Anda sebagai poin utama untuk pertanyaan-pertanyaan ini.
• Anda masih harus membatasi fitur creep, jadi teruskan prioritaskan dan ketahui di mana harus menggambar garis

Pada akhirnya, itu bukan sesuatu yang saya sarankan untuk pemula, karena Anda harus dapat membuat keputusan yang tepat di setiap tahap dan itu tidak mudah bahkan untuk yang paling berpengalaman sekalipun. Jika Anda tidak yakin tentang keputusan yang tepat, maka miliki kebijakan "jangan merayap melampaui titik ini".

Anda juga dapat melihat bagaimana poin pertama dan satu tentang menggunakan teknologi yang Anda kenal dengan baik berarti Anda membutuhkan pengalaman substansial baik dalam prototyping cepat (game jams) dan toolset yang Anda pilih.