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.
sumber
just making every unique dungeon (content) its own class.Itu hanya membuat saya menggigil. Pemisahan data dari logika adalah prinsip mendasar bagi saya sehingga saya terkejut masih ada pengembang yang melanggarnya.Jawaban:
Ada beberapa alasan untuk itu. Saya hanya akan menyentuh beberapa:
if,switches dan sebagainya. Yang kemudian menghasilkan kode yang rentan terhadap kesalahan, sulit dibaca dan lebih sulit untuk debug.sumber
constarray dengan durasi penyimpanan statis). Ini menghemat semua kode, dan biaya memori runtime, dari memuat / mengonversi representasi data eksternal saat runtime. Tentu saja semua alasan Anda lainnya untuk menjaga data eksternal tetap berlaku.Don't Starvemengikuti pendekatan ini dan ini adalah salah satu game dengan penulisan terbaik yang pernah saya lihat. Banyak game lain di masa lalu dan sekarang juga melakukan ini, serta aplikasi (dan jarang utilitas). Saya akan mengatakan bahwa secara keseluruhan, di luar proyek-proyek kecil dan utilitas kecil, layering berat dan pemisahan selalu menjadi teman Anda.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.
sumber
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)
sumber
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.
sumber
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.
sumber
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.
sumber
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.
sumber
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.)
sumber
Saya kira lisensi juga bisa menjadi alasan untuk tidak memasukkan konten dalam kode.
Sebagai contoh,
sumber