Bisakah saya menggunakan fitur creep untuk keuntungan saya? [Tutup]

Bisakah saya menggunakan fitur creep untuk keuntungan saya?

Setiap kali saya membuat prototipe game, fitur ditambahkan secara tidak sengaja. Ini terjadi baik secara kebetulan, atau kebetulan mudah untuk menambahkan berdasarkan konten yang ada.

Jika saya tahu genre gamenya, bisakah saya mulai membuat mekanik dasar dan menambahkan fitur saat sudah jelas?

Misalnya, jika saya ingin membuat platformer 2d selama 6 bulan, dapatkah saya mulai membuat berlari, melompat, menembak, dll. Dan menambahkan mekanik inti saat saya secara tidak sengaja menemukan mereka? Atau apakah ini terlalu berisiko untuk investasi waktu tanpa rencana yang telah ditentukan?

Logika saya di balik ini adalah bahwa desain akan lebih memuaskan. Pilihan desain akan lebih mudah dibangun berdasarkan apa yang mudah dibuat (berdasarkan waktu).

Singkatnya, apakah ada yang salah dengan membangun game sebelum saya mendesainnya?

Itu pertanyaan yang menarik. Terutama karena menjawabnya menimbulkan dilema nuansa abu-abu versus hitam-vs-putih.

Adakah yang salah dengan membangun game sebelum saya mendesainnya?

Jika Anda menganggap pertanyaan itu sebagai tipe ya atau tidak, jawabannya hanya bisa: ya, ada. Jika jawabannya bisa lebih bernuansa, maka itu berubah. Alasan: Anda tidak harus membangun permainan sebelum beberapa merancang. Tapi Anda yakin bisa menghemat bagian dari desain untuk nanti.

Artinya, saya tidak berpikir Anda harus melihat masalah ini sebagai tindakan atau tidak. Sebaliknya, itu adalah sesuatu yang harus Anda pikirkan dalam hal derajat. Merayap fitur mungkin merupakan akar kedua dari semua kejahatan dalam hal pengembangan game (yang pertama, seperti yang dimiliki Donald Knuth kepada kami, adalah bahwa "optimasi prematur adalah akar dari semua kejahatan" ). Namun, dalam pengalaman saya, tidak memikirkan salah satu fitur utama, yaitu tidak memiliki setidaknya desain dasar di mana Anda ingin pergi dengan mekanik dasar Anda, juga bukan ide yang baik.

Alasan utama pertama adalah bahwa ada baiknya sumber daya bijaksana (termasuk waktu sebagai sumber daya) untuk memiliki beberapa perencanaan untuk memandu Anda - karena mencapai jalan buntu sepanjang waktu karena coba-dan-kesalahan yang berlebihan bisa sama seperti buang-buang waktu sumber daya harus menyertakan fitur yang tidak terduga.

Alasan utama kedua, game-design-wise, adalah koherensi. Game-desain yang baik memiliki koherensi konseptual, atau konsistensi jika Anda inginkan. Artinya, permainan-keseluruhan, sejarah, implementasi, bahkan grafik, harus sesuai satu sama lain semulus mungkin. Sangat tidak mungkin bahwa desain-game akan mencapai sesuatu seperti itu jika fitur-fitur utamanya baru diketahui saat bepergian. Jika tidak untuk hal lain, karena dalam perjalanan memiliki banyak keacakan: hal-hal yang akan Anda tuju mungkin memiliki dampak yang sangat berbeda tergantung pada kapan pada saat proses pengembangan Anda menemukannya .

Saya tidak bermaksud mengatakan bahwa Anda tidak harus melakukan apa yang Anda katakan. Saya hanya mengklaim bahwa Anda harus menemukan keseimbangan.

Misalnya, jika saya ingin membuat platformer 2d selama 6 bulan, dapatkah saya mulai membuat berlari, melompat, menembak, dll. Dan menambahkan mekanik inti saat saya secara tidak sengaja menemukan mereka? Atau apakah ini terlalu berisiko untuk investasi waktu tanpa rencana yang telah ditentukan?

Saya akan mulai dengan memperkenalkan sedikit modifikasi pada kalimat Anda. Dengan membuat berlari, melompat, menembak dan lain-lain, Anda sudah menerapkan mekanisme inti. Apa yang akan Anda tambahkan saat bepergian dalam contoh Anda adalah fitur permainan khusus.

Bukan karena Anda tahu game akan menjadi platform 2D, bahwa berlari, melompat, atau menembak tidak dapat berbeda-beda tergantung pada desain game. Bisakah pemain Anda berlari di dinding? Bisakah pemain Anda melayang di udara ketika melompat? Bahkan, dapatkah pemain Anda menembak sambil berlari? Apakah pemain Anda menembak hanya dalam arah linier atau melalui parabola? Keputusan ini bisa sangat tergantung pada fitur permainan.

Tapi saya mengerti maksud Anda: mekanik ini sering memiliki beberapa bagian yang bervariasi sangat sedikit. Jadi, jika Anda melakukan beberapa game-desain dan memutuskan fitur-fitur dasar sebanyak memastikan bagaimana berlari, melompat, menembak, dll akan bekerja, itu awal. Kemudian Anda bisa menggunakan mekanik ini dan terus membangunnya.

Tentu saja nanti Anda masih dapat menemukan fitur baru yang mengharuskan Anda mengubah mekanisme ini - tidak peduli seberapa mendasarnya mereka. Tetapi kuncinya di sini adalah probabilitas. Probabilitas bahwa ini akan terjadi terlalu sering akan lebih kecil jika Anda setidaknya berpikir tentang konsekuensi dari berlari, menembak, melompat dan lain-lain untuk ide-ide dasar yang Anda miliki untuk permainan.

Terakhir, jika Anda ingin pergi ke rute itu, saya akan menyarankan yang berikut ini. Anggap saja sebagai proses berulang. Anda melakukan pemikiran desain tingkat awal yang luas. Anda menerapkan apa yang tampaknya mendasar dan lebih "universal" dalam gim Anda, agar berhasil. Kemudian Anda melakukan lebih banyak pemikiran desain, mengevaluasi kembali apa yang Anda terapkan dan pergi untuk beberapa implementasi lagi.

Saat melakukan proyek rumit seperti permainan, Anda sering tidak dapat membuat semua fitur yang Anda inginkan, karena Anda kehabisan waktu / uang atau karena mereka ternyata tidak sebagus yang Anda harapkan. Ini dikenal sebagai fitur creep. Tapi ada sisi lain dari ini; Anda juga akan menemukan fitur-fitur yang menurut Anda tidak Anda perlukan, tetapi ketika proyek mulai terbentuk kebutuhan mereka menjadi jelas.

Inilah sebabnya orang membuat prototipe - sehingga mereka dapat mempelajari mana yang berhasil dan yang tidak, sehingga mereka dapat memotong fitur yang tidak berfungsi , tetapi juga agar mereka dapat menemukan fitur baru yang akan luar biasa . Jika Anda tidak melakukan salah satu dari hal-hal yang tidak Anda pelajari , Anda salah melakukannya.

Ini pada dasarnya adalah sentimen yang diungkapkan dalam ceramah yang disebut Advanced Prototyping , oleh Chris Hecker dan Chaim Gingold, yang mencakup banyak contoh dari pekerjaan mereka di Spore, di mana mereka sering terkejut dengan apa yang berhasil dan apa yang tidak, sejauh mendesain ulang keseluruhan sistem berdasarkan umpan balik prototipe.

Contoh lain adalah proses desain untuk Left 4 Dead ; pada awalnya permainan hanya memiliki zombie dasar, tetapi dari bermain-main dengan pemain berpengalaman, para desainer menemukan bahwa para pemain terjebak bersama secara efektif dan permainan itu terlalu mudah, sehingga mereka menambahkan zombie khusus untuk memecah tim terpisah dan menjaga permainan tetap menarik.

Tentu saja, ini tidak berarti Anda harus membangun game Anda tanpa desain sebelumnya . Anda harus memastikan bahwa inti permainan Anda menyenangkan sebelum melanjutkan, karena itu sering kali merupakan bagian tersulit dalam membuat permainan.

Saya akan mengatakan ya, lakukanlah. Tetapi rencanakan beberapa fitur / kelas umum sebelumnya untuk memiliki kohesi antara setiap komponen baru.

Unity dikenal dengan pendekatan komponennya untuk pengembangan game, dan akan memungkinkan bentuk pengembangan ini dengan mudah. Jika Anda tidak menggunakan Unity, Anda bisa meniru pendekatan semi-komponen. Saya tidak terbiasa dengan mesin game lain.

Objek game kesatuan semuanya memiliki komponen transformasi. Ini menyatakan posisi, rotasi, dan skala objek. Jadi buat kelas 'transform' umum untuk menyimpan nilai-nilai ini, plus referensi ke objek game yang sebenarnya mungkin.

Ambil komponen 'Lompat', misalnya. Minta semua logika bekerja dengan kelas transformasi objek game untuk melakukan manipulasi posisi. (Atau mesin Anda akan memiliki kelas bawaan yang sudah serupa.) Anda dapat melampirkan kelas 'Lompat' ini ke objek apa pun, dan kelas akan menganimasikan posisi transformasi ketika suatu aksi dipicu (Jump.PerformJump () atau apa pun). Kelas Jump tidak perlu tahu apa-apa tentang pemiliknya (atau, setidaknya, info minimal).

Sekarang Anda dapat bersenang-senang membuat satu ton komponen, kemudian melampirkannya ke objek game, menggabungkannya pada satu objek, dll. Misalnya: Lari, Lompat, Lengkungkan, MovingTile, FireWeapon (tentukan sprite 'peluru', dan perilaku untuk membuat komponen generik), dll.

Buat setiap komponen generik mungkin untuk memungkinkan penggunaan ganda / variasi. Untuk FireWeapon, Anda dapat menentukan sprite peluru, kecepatan, kerusakan, dll. Anda bisa mencoba membuat atribut-atribut tersebut dinormalisasi, sehingga kecepatan dan kerusakan ditentukan antara 0 dan 1. Kemudian skalakan itu ke nilai maksimum gim. Dengan cara ini Anda hanya khawatir tentang perbedaan relatif antara senjata. Plus ini beradaptasi dengan pengaturan global seperti kesulitan di mana kesulitan yang lebih tinggi memiliki kerusakan maks lebih tinggi, dll.

Sebelum Anda menyadarinya, Anda memiliki persenjataan komponen untuk dipasang, dan sekarang Anda dapat dengan cepat berkembang untuk semua jenis permainan.

Ringkas: sebagian besar waktu Anda tidak dapat memiliki satu langkah desain diikuti dari satu langkah pengkodean tunggal. Anda harus mengganti mereka. Sebagai aturan umum, cobalah untuk menghormati apa yang sudah dirancang (bukan apa yang sudah dikodekan).

Tentang tidak memiliki desain awal (hanya sketsa atau gambar mental): jika Anda tidak memiliki desain, Anda tidak memiliki desain. Anda harus melakukan sesuatu untuk mendapatkannya. Tetapi selama Anda mulai membangun satu, cobalah menghormatinya, jangan datang dengan yang baru setiap waktu.

Lakukan eksperimen dan dapatkan fitur acak mungkin berbahaya atau tidak. Bahkan mungkin bermanfaat atau tidak dapat dihindari. Misalnya: Anda tahu bahwa Anda ingin mendukung lompatan (banyak RPG 3D / 2D tidak diizinkan melompat). Bagaimana kamu bisa tahu? Karena Anda membayangkan peta permainan yang membutuhkan lompatan untuk mengurutkan hambatan? Jadi implementasi lompatan cukup baik selama memungkinkan pemain menyortir halangan itu atau apakah ia harus memenuhi karakteristik tertentu seperti ketinggian maksimum yang bisa dicapai, bisa itu didorong oleh item atau objek permainan di peta, fisika harus mencakup akselerasi atau bouncing ( ketika Mario melompat ke musuh Dia mendapatkan dorongan untuk naik lagi dan itu sangat penting untuk bermain game)?

Jika Anda sudah dapat menjawab pertanyaan-pertanyaan itu maka dokumen desain Anda (imajiner atau nyata) sangat lengkap. Jika Anda tidak bisa menjawabnya, maka desain Anda tidak lengkap. Dalam hal ini, Anda harus kembali bekerja dalam desain atau melakukan eksperimen untuk mengisi kekosongan. Peluangnya mungkin sangat terbuka atau sangat membatasi. Jika beberapa level permainan Anda akan mengalami hambatan, dan Anda hanya perlu melompat untuk mereka maka ada banyak kebebasan untuk menentukan ketinggian maksimum yang dapat dicapai atau kecepatan, mungkin Anda memutuskan untuk berpura-pura ada mesin fisika mulai semuanya hanya untuk tingkatkan visual animasi lompatan tetapi Anda tidak memerlukannya untuk hal lain. (Dalam banyak game RPG 2D Anda tidak bisa melompat kapan pun Anda mau, tetapi selama ada satu lubang ubin di peta, mencoba masuk ke dalamnya secara otomatis memicu lompatan ke ubin lantai di sebelah ubin lubang)

Saya mengerti bahwa tidak apa-apa untuk pergi ke kode tanpa desain yang lengkap selama Anda menghormati apa yang sudah diputuskan. Juga mungkin tidak dapat dihindari dalam beberapa situasi karena dunia permainan dapat dibangun dari berbagai proses berpikir yang berbeda. Sebagai contoh permainan kartu: Saya tahu saya ingin kartu memiliki Attack dan Defense, sejumlah kartu dalam tabel pada waktu tertentu dan bahwa pemain pada gilirannya dapat memilih dengan serangan kartu mana kartu lain. Ini mungkin terlihat bagi sebagian orang sebagai desain yang sudah lengkap, tetapi kemudian muncul keseimbangan permainan, hanya mungkin melalui banyak simulasi. Setelah banyak simulasi saya memutuskan bahwa kartu dengan Attack 10 dikalahkan, saya bisa menghapusnya dari permainan tetapi saya sangat menyukainya sehingga saya akan melakukan sesuatu yang berbeda, Saya akan membuat aturan baru yang mengatakan bahwa jika seorang pemain menyerang dengan kartu seperti itu tidak dapat menyerang dengan kartu lain selama giliran itu. Sekarang saya memiliki aturan baru yang memperkaya mekanisme permainan, tetapi menerapkannya pada satu kartu terlihat aneh (seperti hack kotor), saya menyadari itu terlihat aneh dan kemudian saya memutuskan untuk membuat set kartu baru yang memiliki angka tinggi tetapi aturan pembatasan baru berlaku untuk mereka. Sekarang saya memiliki mekanik permainan yang lebih kompleks, dibangun di atas yang asli lebih sederhana, menurut pendapat saya, saya mengubahnya untuk keuntungan saya untuk membuat permainan yang lebih baik.

Sekarang, satu hal tentang contoh terakhir itu, dalam contoh permainan kartu yang diusulkan, kartu baru dapat menghasilkan aset baru (kenaikan biaya, peningkatan waktu). Tetapi saya pikir ini adalah contoh yang baik dari membiarkan peluang yang hanya Anda lihat ketika pengkodean memengaruhi keputusan desain Anda dengan cara yang baik.

Saya tidak berpikir sebagian besar permainan yang kami mainkan sepenuhnya dirancang sebelum pengkodean, saya yakin mereka harus membuat keputusan yang sulit untuk mematuhi jadwal dan sebagainya.

Ketika orang lain membayar semuanya: jelaskan, negosiasikan.