Desain game seluler: iterasi vs. perencanaan dan bahaya MVP

Untuk semua desainer game yang tidak berencana, saya ingin mengatakan:
"Berhenti! Kamu Berbahaya. Anda adalah pengembang yang melelahkan. Anda menyia-nyiakan waktu dan sumber daya berharga yang bisa dihemat dengan mudah dengan cukup memperhatikan perencanaan. Menyiapkan desain berubah menjadi keterlambatan dalam pengembangan secara keseluruhan. Tergesa-gesa memeras fitur setengah matang baru akan kembali kepada Anda dalam bentuk pengeluaran yang tidak direncanakan. Bekerja dengan baik! "

Bagaimana perencanaan kualitas dilakukan?

Sebagai aturan, desain game mobile dibagi menjadi dua sekolah dasar prinsip pengembangan:

1. Iterasi - meletakkan mekanik dasar, dan kemudian beralih sampai sesuatu yang berharga diperoleh; konsep proyek sebelum pengembangan lebih lanjut.
2. Perencanaan - dengan cermat memikirkan setiap fitur, setiap jendela, semua dependensi dan interaksi antara fitur-fitur utama sebelum dimulainya pengembangan.

Biasanya, penganut sekolah iterasi berasal dari dunia PC, di mana orang terbiasa menjual game yang paling menarik bagi pengguna dalam konfigurasi dasar dengan biaya satu kali tetap. Game seperti itu sering memiliki tingkat retensi pemain yang tinggi dan monetisasi yang rendah.
Menurut pendapat saya, ada terlalu banyak orang yang terlalu terbawa oleh metode iterasi. Orang-orang ini mengangkat MVP (produk minimum yang layak dalam Bahasa Inggris) ke status kultus dan menjadikan metode MVP sebagai penopang universal dan alasan yang murah agar tidak memikirkan semua fitur dengan sangat hati-hati. Para pendukung pendekatan MVP sering membuat argumen seperti:

• "Kita bisa menjalankannya nanti."
• “Kami akan memikirkan monetisasi nanti, tetapi untuk saat ini menarik untuk dilakukan.

Sayangnya, pengembang non-teknis tidak mengerti bahwa kode permainan itu bukan karet. Bukan untuk Anda merakit blok plastik LEGO. Permainan ini tidak plastisin, tidak dapat digambar ulang dengan kuat tanpa konsekuensi yang signifikan. Itu karena kode (terutama kode game dengan jumlah hardcode yang cukup) relatif tidak fleksibel.

Dalam hal ini, saya memiliki sudut pandang yang agak radikal: Saya percaya bahwa banyak perancang gim yang menggunakan metode iterasi dalam gim bebas-main seluler hanya berbahaya karena seluruh tim pengembangan dapat merusak kemalasan mereka.

Dalam mantra baru untuk pengembangan game mobile, kita tidak boleh berbicara tentang MVP dengan penekanan pada "minimum" untuk mengembangkan produk yang layak, tetapi sesuatu yang lebih.

Hukum Kim:

Kembangkan Produk yang Berkelanjutan Minimal dengan Perencanaan yang Paling Berkelanjutan

Industri game seluler terlalu berat bagi orang yang tidak ingin menginvestasikan waktu dan upaya dalam merencanakan proyek mereka.
Cukup sering saya melihat jenis-jenis acara berikut:

• Ide-ide semi-mentah, kurang dipikirkan diberikan untuk pengembangan.
• Banyak pengembang, dalam mengejar desain game yang trendi dan paling menguntungkan, memasukkan fitur ke dalam game yang ada yang terlihat sangat konyol di sana.
• Interaksi fitur dan pengaruhnya satu sama lain dalam game tidak dipikirkan dengan baik.

Kepada semua desainer game yang termasuk dalam kategori ini, saya ingin mengatakan:

"Stop! Kamu Berbahaya. Anda adalah pengembang yang melelahkan. Anda menyia-nyiakan waktu dan sumber daya berharga yang bisa dihemat dengan mudah dengan cukup memperhatikan perencanaan. Menyiapkan desain berubah menjadi keterlambatan dalam pengembangan secara keseluruhan. Tergesa-gesa memeras fitur setengah matang baru akan kembali kepada Anda dalam bentuk pengeluaran yang tidak direncanakan. Bekerja dengan baik! "

Bagaimana perencanaan kualitas dilakukan?

Bahkan, semuanya bermuara pada tugas-tugas dasar berikut:

1. UI. Pastikan antarmuka mendukung fitur Anda. Buat layout jendela utama terlebih dahulu.
2. Aliran pengguna. Sebelum memberikan fitur baru untuk pengembangan, pastikan semua jendela dan kombinasinya dalam aliran pengguna diperhitungkan dan dipikirkan. Jenis aliran apa? Baca di sini: UI Seluler dan Desain Game: Layar vs. Mengalir
3. Kasus perbatasan. Pikirkan semua kasus batas utama. Apa itu? Borderline case adalah situasi permainan yang berada di luar alur permainan normal, tetapi mereka juga perlu dikerjakan. Periksa bahwa dalam kasus batas tidak ada jebakan.
4. Dampak pada sistem.Pikirkan tentang bagaimana fitur baru akan memengaruhi keseimbangan dan ekonomi gim Anda. Bagaimana itu akan memengaruhi sistem lain dalam gim Anda. Dan di berbagai bagian antarmuka? Pastikan tidak ada kontradiksi di mana pun.
5. Dampak pada proyek. Bagaimana fitur baru akan memengaruhi gameplay, parameter desain, dan monetisasi? Jika Anda segera menambahkan fitur PvE baru ke gim PvP, ini dapat menyebabkan BENCANA. Bagaimana ini akan mempengaruhi monetisasi yang diharapkan dan aktual? (Info lebih lanjut di sini: Desain Game berbasis Monetisasi: Kontribusi ARPDAU ) Pikirkan!

Namun tetap saja, ada saatnya lebih baik menggunakan pendekatan berulang daripada perencanaan. Misalnya, dalam percobaan dengan jenis permainan baru, jika ini adalah tugas utama dan risiko utama. Juga, intinya bukan dalam perencanaan TOP. Pertimbangkan masalah desain di atas sebanyak yang diperlukan untuk setiap fitur tertentu, jenis permainan, tujuan Anda, dll. Ini adalah kasus khusus Anda yang akan menentukan Perencanaan Berkelanjutan Maksimum Anda. Tidak ada solusi standar untuk semua masalah.

Tergantung pada situasinya, perencanaan yang lebih hati-hati, sebagai suatu peraturan, membutuhkan jenis permainan berikut:

• Lebih kompleks - kompleks, multi-sistem, dengan sejumlah besar hubungan; di sini Anda perlu memahami bagaimana fitur baru akan memengaruhi semua hal lain dalam game.
• Lebih banyak UI - juga lebih kompleks, tetapi dalam hal sejumlah besar jendela;
• Multisistem - semakin keras gim Anda, semakin banyak sistem yang dimilikinya.



Untuk menyimpulkan:

• Saya berharap publikasi ini membantu salah satu dari Anda meningkatkan peluang keberhasilan produk Anda melalui perencanaan.
• Anda perlu memahami kapan harus menggunakan perencanaan secara situasional dan kapan harus menggunakan iterasi.
• Gunakan teknik di atas untuk mengurangi iterasi produksi; bagian utama dari perencanaan harus dilakukan pada tahap pertama pengembangan game, ketika biaya perubahan masih relatif kecil.

Source: https://habr.com/ru/post/id383131/