Mengapa konten hard-code jelek?

Saya tahu sebagian besar game menyimpan teks dialog dalam file, tetapi saya juga melihat beberapa game berbasis teks benar-benar memprogram konten (peta, pilihan, kemungkinan perintah pemain, teks cerita) ke dalam kode game.

Saya dapat memikirkan beberapa alasan, tetapi apa alasan utama mengapa bahkan permainan teks menyimpan semua file di luar program?

Detail implementasi sedikit berbeda antara menyimpan konten dalam sesuatu seperti format XML populer, menguraikannya, lalu merender peta / menampilkan teks berdasarkan variabel yang dibuat dari file XML, dan hanya meninggalkan file XML sepenuhnya. Keduanya berakhir dengan string yang ditampilkan ke layar. Bukankah perbedaannya hanya notasi?

Beberapa game bahkan menahan grafik (ASCII art?) Di dalam kode. Saya tahu ini tidak benar, dan saya bisa menebak beberapa alasan mengapa itu buruk, tetapi saya juga tidak tahu alasan utama mengapa hal itu buruk.

Sangat populer untuk memiliki sebagian besar konten di luar program. Bahkan Dwarf Fortress tidak menggunakan karakter ASCII yang sebenarnya, tetapi gambar karakter ASCII dimuat ke dalam memori.

Saya terutama bertanya karena ini sedikit PITA untuk membuat, mengurai, dan bekerja dengan file XML. Anda tahu ... dibandingkan dengan alternatif malas hanya membuat setiap ruang bawah tanah unik (konten) kelasnya sendiri.

Ada beberapa alasan untuk itu. Saya hanya akan menyentuh beberapa:

1. Itu membuat kode sumber Anda berantakan. Jika Anda memiliki banyak dialog (pohon), sebagian besar basis kode Anda hanyalah teks yang tidak ada hubungannya dengan kode gim Anda yang sebenarnya.
2. Anda harus mengkompilasi ulang setiap kali Anda berubah begitu banyak sebagai satu karakter.
3. Dialog itu sendiri sulit dinavigasi. Saya membayangkan mencoba menerapkan seluruh pohon dialog, apalagi beberapa, sepenuhnya di dalam sumber Anda akan menghasilkan kekacauan spaghetti dan bersarang if, switches dan sebagainya. Yang kemudian menghasilkan kode yang rentan terhadap kesalahan, sulit dibaca dan lebih sulit untuk debug.
4. Jika Anda ingin memungkinkan orang mengubah atau memperluas permainan Anda, itu jauh lebih mudah jika mereka tidak harus berurusan dengan kode sumber untuk mengubah sesuatu.
5. Poin di atas bahkan lebih penting jika Anda bekerja dalam tim. Anda tidak ingin penulis Anda harus mengacaukan kode hanya dengan memasukkan sepotong dialog.
6. Parsing XML atau format file standar lainnya cukup mudah dilakukan jika Anda menggunakan perpustakaan yang ada, sehingga biaya penerapannya sangat rendah sambil memberi Anda banyak keuntungan dan menghindari masalah yang disebutkan di atas dan banyak lagi.
7. Seperti yang ditunjukkan @MiloPrice di bawah ini, juga jauh lebih mudah untuk melokalkan game jika teks Anda ada di file eksternal. Anda dapat menambahkan bahasa dengan menambahkan file, tim Anda dapat mengurus terjemahan tanpa harus menyentuh sumbernya (yang sangat penting jika Anda membiarkan orang menerjemahkan yang tidak seharusnya melihat semua kode Anda - pikirkan freelancer, orang-orang dari komunitas yang bukan milik tim Anda dll).

Menempatkan data konten game dalam kode berarti bahwa untuk melihat potensi perubahan atau iterasi dari data konten game itu, Anda harus mengkompilasi ulang game itu sendiri. Ini buruk karena dua alasan:

• Banyak bahasa tempat game ditulis memiliki waktu kompilasi yang panjang. C ++ khususnya bisa sangat buruk dalam hal ini, dan C ++ adalah bahasa yang sangat umum untuk gim komersial besar. Ini kurang dari masalah dengan bahasa seperti C # dan Java, tetapi masih tidak secepat bisa menyimpan data game dalam file eksternal yang bisa di-hot-load saat game benar-benar berjalan untuk melihat perubahan.

• Banyak game yang dikembangkan oleh tim yang sering terdiri dari pengembang non-teknis (desainer dan seniman) yang memproduksi konten. Tidak hanya orang-orang non-teknis yang tidak ingin harus mengkompilasi ulang permainan, atau berurusan dengan "alat programmer yang rumit," untuk beralih pada konten mereka, mungkin diinginkan untuk meminimalkan paparan kode sumber hanya untuk para programmer (karena semakin sedikit orang yang memiliki akses ke kode sumber, semakin sedikit orang yang dapat membocorkannya - secara tidak sengaja atau tidak).

Saya pikir Anda melebih-lebihkan kompleksitas memuat data dari teks atau file XML. Sebagian besar waktu Anda harus menggunakan perpustakaan untuk melakukan ini, yang membuat proses penguraian XML / JSON / apa pun lebih mudah. Ya, ada sedikit biaya di muka untuk menulis sistem pemuatan level yang digerakkan oleh data tetapi umumnya akan menghemat banyak waktu dalam jangka panjang versus berton-ton kelas unik untuk mewakili setiap level.

Gim yang lebih kecil atau lebih sederhana mungkin tidak memiliki banyak manfaat dari investasi jangka panjang dari pendekatan berbasis data, jadi kecuali jika pengembang menggunakan kerangka / mesin yang ada yang mendukungnya, mungkin akan lebih efisien bagi mereka untuk hanya menyandikan data di kode permainan.

Tentu saja ada sejumlah alasan mengapa setiap game tertentu dapat memilih untuk memasukkan data mereka dalam file eksternal (atau tidak); tidak layak untuk mendaftar semuanya. Pada tingkat tertentu, mereka semua biasanya bermuara pada kecepatan iterasi tambahan atau fleksibilitas yang tidak dapat dimiliki untuk membangun kembali-gim.

Seperti biasa, seperti biasa, itu tergantung. Tapi pertama-tama, saya ingin berdebat bahwa pengkodean keras tidak buruk dengan sendirinya.

Saya memiliki konten kode keras, khususnya teks dialog, dalam beberapa permainan sederhana, dan dunia tidak berakhir. Kami programmer menyukai hal-hal yang abstrak, tetapi ingat bahwa setiap lapisan abstraksi yang Anda buat akan membuat program Anda lebih kompleks dan lebih sulit untuk dipahami.

Jika gim Anda cukup sederhana sehingga Anda dapat membuat hardcode beberapa konten di dalamnya, saya pasti akan mempertimbangkannya demi kesederhanaan.

Namun, ini tidak terlalu berskala. Tentu saja alasan paling umum untuk menempatkan konten di sumber daya luar adalah untuk menyederhanakan kerja tim, karena satu orang atau tim dapat fokus pada penulisan game, sementara yang lain dapat fokus pada pembuatan dan pemolesan konten.

Namun, menarik garis antara program dan konten tidak selalu benar-benar sepele. Bisa dikatakan bahwa tekstur adalah konten 100%; tetapi bagaimana dengan tekstur yang dihasilkan secara prosedural? Teks dialog dapat dianggap konten 100%; tetapi bagaimana dengan kapan dialog berubah tergantung pada tindakan Anda sebelumnya? Elemen lain yang dapat dianggap 100% bagian dari program, seperti skrip atau bayangan, juga dapat dianggap sebagai bagian dari konten permainan. Haruskah mereka dikodekan? haruskah mereka dimuat sebagai sumber daya eksternal?

Ingat juga, bahwa setiap jenis konten yang Anda dukung dalam gim Anda harus memiliki kode pemuatan dan interpretasi yang terkait dengannya, jadi secara umum, jika ragu, saya akan merekomendasikan konten hard coding, dan hanya membawanya ke sumber daya eksternal ketika Anda benar-benar membutuhkan fleksibilitas itu (bukan ketika Anda berpikir Anda -mungkin- membutuhkannya, tetapi ketika Anda benar-benar melakukannya)

Akhirnya, satu keuntungan dari menyimpan data dalam file sumber daya adalah Anda dapat memuatnya hanya saat Anda membutuhkannya (karena itu mungkin mempercepat waktu pemuatan game), dan menurunkannya saat Anda tidak membutuhkannya lagi (karena itu memungkinkan Anda memiliki lebih banyak konten) dari yang bisa muat di memori). (Sudut Nitpickers: DLL sumber daya dapat dianggap sebagai sumber daya eksternal)

Alasan besar untuk menyimpan dalam file teks adalah usabilitas ulang. Membuat kerangka permainan teks yang membaca peta, dialog, dan sumber daya lainnya dari file teks memungkinkan Anda menggunakan kembali kerangka kerja Anda untuk permainan lain. Melampaui permainan teks ini adalah bagaimana judul anggaran besar seperti Call of Duty merilis game baru setiap tahun.

Alasan lain adalah portabilitas. Anda dapat menggunakan file yang sama untuk web, pc, Mac, Android, dll. Yang perlu Anda lakukan hanyalah membuat kerangka kerja untuk platform yang berbeda ini, dan sebagian besar data gim tidak tersentuh.

Ketika melampaui permainan berbasis teks yang memiliki skrip dan data yang disimpan dalam file akan mengurangi waktu kompilasi ulang dan memungkinkan Anda membuat antarmuka untuk memanipulasi data dengan lebih mudah.

Demi membuat perubahan lebih cepat, itu mempercepat pengembangan pada produksi yang lebih besar dengan ton.

Anda tidak perlu mengajar semua orang untuk mempelajari cara masuk dan mengedit sumber untuk membuat perubahan sederhana. Dengan menyeretnya keluar dari kode sebenarnya, semakin banyak orang mendapatkan kesempatan untuk bermain-main, lebih mudah untuk mengetahui opsi apa yang dapat Anda mainkan dan seluruh proses penyelesaian berbagai bagian permainan Anda membutuhkan waktu yang jauh lebih sedikit. Bahkan Q&A dapat membantu dengan itu.

Saya tidak percaya belum ada yang menyebutkan ini, tetapi alasan utama adalah untuk membuat lokalisasi BANYAK lebih mudah. Jika Anda perlu mendukung bahasa Inggris, Prancis, Jerman, Spanyol, Portugis, Italia, Rusia, Cina, dan bahasa apa pun yang Anda tuju, hardcod mengharuskan Anda memiliki kode-belakang yang terpisah untuk setiap bahasa. Ini juga berarti bahwa jika Anda perlu menghapus konten tertentu (baca: sensor), Anda perlu mengubah kode itu sendiri untuk menghindarinya, alih-alih mengatakan "ganti saja minigame pemeriksaan anal ini dengan spanduk pasif-agresif ini yang secara grafis menjelaskan apa yang terjadi ". Ini juga agak tidak ramah bagi konsumen, karena kemungkinan mereka harus memulai kembali permainan untuk mengubah bahasa, karena Anda perlu memuat perpustakaan lain. Akhirnya,

Di sisi lain, jika Anda menggunakan sumber daya eksternal, mendukung bahasa yang berbeda berarti memuat file sumber daya yang berbeda. Ini dapat dengan mudah dilakukan saat game sedang berjalan. itu berarti bahwa Anda dapat memiliki basis kode tunggal, pengembangan yang sangat menyederhanakan. Dan itu juga berarti bahwa Anda dapat dengan mudah menambahkan dukungan setelah rilis untuk bahasa lain. Akhirnya, itu berarti Anda dapat membiarkan pengguna memilih untuk tidak menginstal bahasa tertentu (fitur yang tidak sering terjadi di game, tetapi yang masih memungkinkan) untuk menghemat ruang disk dan bandwidth.

Saya pikir ungkapan kuncinya adalah pemisahan kekhawatiran .

Jika kode Anda tidak menyertakan teks, maka kode yang didapat kurang kompleks. Programmer yang menulis kode tidak harus memikirkan teks tertentu dan dapat fokus pada kode.

Dia tidak harus memikirkan lokalisasi. Orang yang melakukan pelokalan tidak perlu khawatir tentang kode.

Saya pikir terlalu mudah untuk menjadi orang yang 'layu-daripada-putih' dan merekomendasikan dengan hangat menggunakan file sumber daya teks eksternal.

Mengapa? Karena ada pilihan di sini yaitu menyeimbangkan biaya / masalah / keuntungan setiap solusi.

Saat menggunakan file eksternal ... Ya, saya kira jawaban yang lain menjelaskan manfaatnya dengan cukup baik. Tapi bagaimana dengan biayanya? Anda harus mendefinisikan formalisme yang valid, membangun juru bahasa, menyetujui format file, dan lebih buruk lagi ... membangun aplikasi lain -an editor-. Yang merupakan masalah 0,00% jika Anda adalah anggota dari tim coder 50 membangun proyek besar. Tetapi jika Anda sendirian: Anda mandek.

Sekali lagi, saya tidak meremehkan manfaat fleksibilitas yang besar dari sumber daya eksternal: pemrograman berbasis data bagi saya tampaknya merupakan cara untuk bermain video-game. Tapi jangan lupa biayanya.

Di sisi lain, memiliki teks di dalam kode memungkinkan untuk prototyping cepat, jadi harus lebih disukai dalam waktu yang pertama. Maka saran saya adalah, ketika proyek matang, untuk menganalisis jenis data yang diperlukan untuk memodelkan dialog (mood / history-state / ...). Kemudian pada titik tertentu Anda memutuskan beberapa kelas / aturan / format file dan pergi untuk hal yang nyata, memungkinkan orang lain untuk mengedit / memisahkan kode dari konten dan sebagainya. ATAU untuk permainan dengan dialog sederhana (Mario ...) Anda hanya menganggap biayanya terlalu tinggi, dan Anda menjaga beberapa string / perilaku tetap tersandi kode.
Panggilanmu.

(Keterangan tentang pelokalan: itu hanya tabel hash, jadi ini masalah yang independen dan mudah dipecahkan.)

Saya kira lisensi juga bisa menjadi alasan untuk tidak memasukkan konten dalam kode.

Sebagai contoh,

• kode Anda mungkin FLOSS , tetapi Anda sama sekali tidak ingin melisensikan konten Anda (mungkin Anda ingin menerbitkan kode game Anda sehingga orang lain dapat menggunakannya untuk membuat game serupa dengan konten yang berbeda)
• kode Anda mungkin FLOSS, tetapi Anda ingin menggunakan lisensi Creative Commons untuk konten Anda (karena lisensi perangkat lunak tidak berfungsi baik untuk konten dan sebaliknya)
• kode Anda mungkin merupakan hak milik , tetapi Anda menggunakan kembali konten gratis
• kode Anda mungkin merupakan hak milik, tetapi Anda ingin mempublikasikan konten Anda sendiri di bawah lisensi bebas / gratis