Apa jebakan terbesar yang harus dipertimbangkan ketika mengembangkan game baru?

Saya sebenarnya baru saja mulai melacak (terima kasih David Young atas koreksi nomenklaturnya) beberapa permainan berbasis web baru untuk Facebook beberapa minggu yang lalu dan saya baru saja dibanjiri dengan blok mental dan waktu yang menyebalkan dari pengodean ulang. Saya sedang mengerjakan sesuatu yang mirip dengan RPG gaya turn based (Vampire Wars). Saya memiliki keterampilan untuk membuat kode permainan, tetapi saya berusaha keras untuk mendapatkan pola desain yang benar dan membuat produk tersebut cocok dengan apa yang saya lihat di mata pikiran saya.

Biasanya ketika membangun sebuah situs web saya suka 'berpikir dalam kode' dan saya merasa lebih cepat bagi saya untuk hanya mengubah kode / HTML untuk mengubahnya. Ini mungkin karena saya SANGAT nyaman dengan apa yang saya lakukan dan saya tahu apa yang diharapkan. seperti yang telah saya lakukan berulang kali. Pada titik ini dengan pengembangan game saya menemukan diri saya mulai di atas kertas lagi (seperti saya dulu dengan situs web) dan saya bertanya-tanya apakah ini hanya kurangnya fokus dan intuisi saya dengan logika game atau apakah ini cara yang tepat untuk mengeluarkan pikiran saya di kemajuan pengkodean.

Saya akan sangat menghargai beberapa saran tentang cara yang benar menyerang masalah ini dan membuat saya tetap bertugas. Saya dengan cepat belajar betapa berbedanya mesin game dari situs web bisnis standar! Setiap kali saya mendapatkan sesuatu di tempatnya, rasanya hanya mooshy dan tidak lengkap dan menjadi frustasi.

Diperpanjang

Sebagai contoh, mesin pertempuran yang telah memberi saya begitu banyak masalah baru-baru ini membutuhkan keterampilan serangan sederhana dan kemudian membuat gulungan acak antara -50% dan + 50% dan kemudian melipatgandakan keterampilan serangan asli terhadap persen itu. Hal yang sama dilakukan dengan pertahanan dan kemudian saya menyatukan mereka untuk menentukan apakah ada kerusakan yang dilakukan terhadap kesehatan musuh. Kurasa aku harus menyadari bahwa aku berada di atas kepalaku ketika aku mulai bertanya pada diriku sendiri apakah itu bahkan cara yang tepat untuk melakukannya, atau apakah ada cara yang 'benar'. Satu kesalahan utama yang saya temukan dengan ini adalah dua karakter di sekitar level yang sama dapat memiliki beberapa 'gulungan' di mana serangannya adalah -50% dan pertahanan adalah + 50% jadi saya berakhir dengan beberapa urutan pertempuran yang sangat panjang di mana tidak ada yang melakukan apa pun. GAGAL

Mungkin posting saya seharusnya meminta tautan yang disarankan yang menggambarkan logika permainan sederhana.

Akhir Ekstensi

Terima kasih sebelumnya!

menambahkan terlalu banyak fitur. Fokus pada inti gim, bangun, lalu jika semuanya berfungsi dengan baik, tambahkan fitur. Orang terlalu fokus untuk menambahkan hal-hal keren, dan tidak pernah menyelesaikan apa pun.

Ini adalah artikel yang bagus tentang cara membuat prototipe game. Dari pertanyaan Anda sepertinya Anda kehilangan ide tentang apa yang seharusnya menjadi prototipe.

Prototyping: Anda (Mungkin) Melakukannya Salah

Blurb:

Kesalahan # 4: Membangun sistem, bukan permainan
Saat Anda membuat prototipe, jika Anda menemukan diri Anda mengerjakan sesuatu yang tidak secara langsung memajukan Anda, berhenti di situ. Sebagai pemrogram, kami memiliki kecenderungan untuk mencoba menggeneralisasi kode kami, dan membuatnya elegan dan dapat menangani setiap situasi. Kami menemukan bahwa gatal sangat sulit tidak tergores, tetapi kita perlu belajar caranya. Butuh waktu bertahun-tahun untuk menyadari bahwa ini bukan tentang kode, ini tentang permainan yang Anda kirim pada akhirnya.

Jangan menulis sistem komponen permainan yang elegan, lewati editor sepenuhnya dan sembunyikan status dalam kode, hindari kegilaan XML yang didorong data, self-parsing, XML, dan hanya kode hal yang terkutuk itu.

Edit:

Saya menambahkan ini hanya untuk memperjelas perbedaan antara Prototipe dan Kode Pelacak.

Ingatlah selalu: Prototipe dirancang untuk dibuang! Kode Pelacak tidak.

Jebakan Prototipe

... Pendekatan kode pelacak menangani masalah yang berbeda. Anda perlu tahu bagaimana aplikasi secara keseluruhan hang bersama. Anda ingin menunjukkan kepada pengguna Anda bagaimana interaksi akan bekerja dalam praktiknya, dan Anda ingin memberikan kerangka arsitektur untuk menggantung kode kepada pengembang Anda. Dalam hal ini, Anda dapat membuat pelacak yang terdiri dari implementasi sepele dari algoritma pengemasan kontainer (mungkin seperti first-come, first-served) dan antarmuka pengguna yang sederhana namun berfungsi. Setelah Anda memiliki semua komponen dalam aplikasi yang disatukan, Anda memiliki kerangka kerja untuk menunjukkan kepada pengguna dan pengembang Anda. Seiring waktu, Anda menambah kerangka ini dengan fungsionalitas baru, menyelesaikan rutinitas yang terhenti. Tetapi kerangka tetap utuh, dan Anda tahu sistem akan terus berperilaku seperti itu ketika kode pelacak pertama Anda selesai.

Perbedaannya cukup penting untuk menjamin pengulangan. Prototyping menghasilkan kode sekali pakai. Kode pelacak ramping tetapi lengkap, dan membentuk bagian dari kerangka sistem akhir. Anggap prototyping sebagai pengintaian dan pengumpulan intelijen yang terjadi sebelum satu pelacak peluru ditembakkan.

Informasi Lebih Lanjut tentang desain Kode Pelacak, dari The Pragmatic Programmer

Pelacak Peluru dan Prototipe

Jebakan: Tidak Memisahkan logika Anda dari data Anda. Tidak menguji bahwa data Anda menghasilkan hasil yang diinginkan.

Dari komentar Anda di pos Joe:

Anda ingin saya membuat kode mesin pertempuran untuk pertemuan monster, BOOM! Saya telah menulis ulang mesin saya setidaknya tiga kali minggu ini dan saya tidak pernah merasa nyaman dengan itu. Maksud saya, matematika itu berhasil, tetapi ketika saya mencobanya hanya terasa tidak enak. Apakah itu masuk akal?

Sepertinya Anda sedang menggabungkan mesin dengan data di sini. Mesin pertemuan monster Anda harus didorong oleh data. Jika data yang mempengaruhi keseimbangan / kegembiraan permainan Anda salah, seharusnya tidak perlu menulis ulang mesin Anda sepenuhnya - cukup atur variabel keseimbangan Anda sampai terasa benar.

Namun, karena variabel keseimbangan terkadang saling tergantung, mengubah satu variabel menjadi lebih baik satu skenario dapat memiliki efek (negatif) yang luas pada skenario lain.

Untuk menguji bahwa data Anda yang baru di-tweak tidak membuat banyak kasus lain, ada baiknya untuk menyimpan beberapa kasus uji di sekitar dan memastikan mereka tidak rusak setelah tweaking. Berikut adalah contoh yang dibuat untuk bagaimana Anda akan menguji ini.

TestResult TestPlayerKillsMonsterDuringAttack(PlayerStats, MonsterStats, seed)
{
   Player player(PlayerStats);
   Monster monster(MonsterStats);


EncounterEngine.SeedRNG(seed);

   while(1)
   {
     result = EncounterEngine.Attack(player, monster);
     if (result == PLAYER_DEAD)
       return TEST_FAIL;
     if (result == MONSTER_DEAD)
       return TEST_PASS;
     // result == MONSTER_DAMAGED, PLAYER_DAMAGED is expected. 
   }
}

Misalnya. Jika Anda menyebutnya dengan PlayerStats.Level == 5 dan MonsterStats.Level == 3, Anda akan mengharapkan pemain untuk selalu mengalahkan monster ini pada akhirnya.

Jebakan di sini, sejauh yang saya bisa lihat, adalah bahwa Anda memperlakukan pemrograman dan desain game sebagai tugas yang sama, padahal sebenarnya itu adalah tugas yang terpisah. Seperti yang Anda sarankan, ini bukan masalah pemrograman atau algoritmik (Anda dapat membuat kode sistem pertempuran dengan cara apa pun yang Anda inginkan), ini tentang apa yang menyenangkan dan menarik bagi pemain.

Jawabannya adalah, cari sumber daya pada desain game dan keseimbangan game. Sebenarnya ada universitas yang mencurahkan seluruh program studi empat tahun untuk topik yang Anda ajukan, jadi memberi Anda jawaban cepat dan kotor tidak mungkin (dengan cara yang sama Anda mungkin akan bingung jika seseorang berkata " ya, saya punya ide untuk permainan ini tetapi saya tidak tahu bagaimana memprogramnya, apa yang harus saya perhatikan? "). Ada buku, kursus, dan tulisan online di luar sana tentang desain game; cari mereka.

Jebakan terbesar saat menulis gim adalah mengkhawatirkan apakah Anda menggunakan pola desain yang tepat dan bukan hanya menulis kode yang Anda sukai.

Saya akan merekomendasikan artikel Steve Pavlina tentang manajemen waktu dan motivasi diri: http://stevepavlina.narod.ru/

Dia juga seorang programmer. Eksperimen gaya hidupnya telah membangkitkan minat media arus utama.