Mengapa konten hard-code jelek?


41

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.


9
Game berbasis teks membuat kode keras banyak konten, tapi saya pikir itu hanya karena waktu ketika mereka dikembangkan dan pilihan desain yang buruk. Hal yang sama mungkin berlaku untuk Benteng Kerdil. Saya pribadi telah mengambil semua game berbasis teks dan memindahkan konten di luar sumber ke dalam basis data. Itu membuat hidup saya jauh lebih mudah.
Glen Swan

7
i18n akan sangat sulit dilakukan dengan konten yang disematkan dalam sumber.
mundur

5
Tidak begitu yakin ini khusus pengembangan game. Di masa depan pertimbangkan untuk bertanya pada programmer SE atau stackoverflow.
MichaelHouse

13
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.
Lilienthal

4
Apa pun yang Anda putuskan, sadari bahwa konten hardcoding memungkinkan lebih banyak kasus khusus. Ingin bos tertentu hanya muncul antara tengah malam dan 07:00 (waktu nyata)? Jauh lebih mudah untuk membuat hardcode daripada membuat cara umum bagi monster untuk hanya muncul pada waktu tertentu.
user253751

Jawaban:


85

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).

10
Saya tidak akan mengatakan bahwa itu akan membuat kode Anda berantakan. Jika tidak, konten atau tidak, apa pun dapat dianggap berantakan secara massal. Anda dapat menyusun konten dalam struktur yang baik seperti kode. Tapi, sisa poin masih tetap kuat.
Glen Swan

28
Kemudahan lokalisasi / terjemahan adalah manfaat besar lainnya.
Milo P

2
@Christian: Anda dapat memiliki program berbasis data di mana data tertanam dalam program dalam format yang dapat langsung digunakan di tempat (misalnya dalam C atau C ++, besar, semoga- 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.
R ..

2
Secara pribadi saya mendukung pendekatan yang lebih kuat untuk alasan yang sama disebutkan di sini: Pindahkan sebagian besar kode Anda dalam bahasa scripting juga. Bangun sebuah inti dalam C / C ++, sematkan bahasa seperti Python atau Lua dan ekspor API ke dalamnya. 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.
mechalynx


30

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.


Saya tidak berpikir waktu kompilasi benar-benar penting tetapi sebagai pengembang kami selalu berusaha untuk "kode rapi" ... ini adalah alasan yang cukup bagus untuk memisahkan hal-hal di dalamnya sendiri ... konten harus konten bukan kode!
Perang

4
@Wardy Waktu kompilasi benar-benar penting dalam C ++. Saya telah bekerja dengan solusi yang membutuhkan waktu lebih dari 15 menit untuk membangun, baik karena ukuran proyek, penggunaan template yang agresif atau bahkan kemalasan pengembang (termasuk header yang tidak perlu). Dan saya yakin inilah masalahnya dengan game komersial besar.
concept3d

1
@ concept3d: Saya berharap proyek saya 15 menit. Pembangunan yang bersih di server khusus membutuhkan waktu ~ 50 menit.
Mooing Duck

semakin sedikit orang yang memiliki akses ke kode sumber, semakin sedikit orang yang akan menderita kerusakan otak yang disebabkan oleh C ++. : P
Sarge Borsch

Saya pikir beberapa orang mungkin kehilangan titik hot-reload - tidak ada yang peduli jika butuh 30 detik untuk mengkompilasi ulang permainan, artis tidak ingin memulai kembali permainan, mereka ingin pintasan keyboard, sehingga mereka dapat menguji animasi yang berbeda dan tekstur dengan cepat. Sebenarnya ini adalah salah satu hal yang paling mereka inginkan. Melihat bagaimana hal-hal terlihat di luar permainan adalah satu hal tetapi melihatnya dalam permainan adalah yang terpenting.
wolfdawn

7

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)


7
"tetapi ingat bahwa setiap lapisan abstraksi yang Anda buat akan membuat program Anda lebih kompleks dan lebih sulit untuk dipahami." Saya harus tidak setuju, abstraksi dapat membuat program lebih sederhana dan tentunya harus membuatnya lebih mudah untuk dipahami.
NPSF3000

1
@ NPSF3000 abstraksi akan menambah kompleksitas, tetapi dapat menghapus lebih banyak kompleksitas daripada yang mereka tambahkan.
user253751

2
@immibis, jadi jumlah total kompleksitas proyek setelah menerapkan abstraksi harus lebih rendah dari sebelumnya.
NPSF3000

3
@ NPSF3000: Maksud saya adalah Anda tidak boleh membuat abstraksi hanya karena Anda bisa. Terkadang data hardcoding lebih sederhana, lebih mudah dimengerti dan lebih mudah di sekitar. Lebih sering daripada tidak, saya telah melihat game menyusuri jalan menuju softcoding , yang menurut saya sangat disesalkan. Juga perlu diingat bahwa menambahkan abstraksi selalu lebih mudah daripada menghapusnya, jadi saya seorang pendukung tegas menambahkan abstraksi hanya ketika Anda membutuhkannya.
Piyama Panda

@PandaPajama melakukan sesuatu 'hanya karena Anda bisa' cenderung menyebabkan masalah, terlepas dari apa sesuatu itu. Itu tidak berarti bahwa sesuatu itu secara inheren kompleks, yang merupakan titik perhatian saya. Juga, apa yang membuat Anda berpikir menambahkan abstraksi lebih mudah daripada menghapusnya? Dari atas kepala saya, saya akan berpikir sebaliknya - menambahkan abstraksi terlambat dapat berarti refactoring yang signifikan, tetapi saya tidak dapat langsung memikirkan kasus di mana menghapus abstraksi yang tidak perlu akan menjadi kompleks. Mengubah dari XML ke string hardcoded seharusnya sepele.
NPSF3000

3

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.


1
Tentu saja, memiliki sebagian besar barang yang dapat digunakan kembali cenderung memaksa Anda untuk menghindari melakukan sesuatu yang "istimewa", di luar aturan yang sudah Anda miliki. Saya jelas tidak menganjurkan game-game besar hardcoding, tetapi ini sangat berguna ketika Anda membuat prototip atau menulis game eksperimental - ini memberi Anda lebih banyak fleksibilitas. Itu datang dengan harga, tentu saja, jadi biasanya ide yang baik untuk memperbaiki semuanya setelah gameplay benar-benar bekerja. Gameplay adalah bagian yang sulit - pastikan Anda dapat mengujinya tanpa menyelam melalui neraka arsitektur: D Biasanya lebih mudah untuk menemukan bentuk umum setelah Anda memiliki beton.
Luaan

3

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.


3

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.


3

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.


3

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.)


Beberapa dari hal-hal ini masih benar jika Anda memasukkan teks ke dalam kode. Anda masih memerlukan format tertentu, cara menavigasi pohon, dan sebagainya. Dengan mengingat hal itu, biaya tambahan apa pun untuk menerapkan sumber konten eksternal tampaknya relatif rendah, terutama karena perpustakaan dan editor yang matang ada untuk penguraian, penulisan, pengeditan, dan pembuatan file-file ini. Bergantung pada kerumitan dialog Anda, Anda bahkan dapat pergi tanpa editor khusus dan cukup menggunakan editor teks standar.
Christian

1
Tentu: mungkin saya tidak cukup jelas, maksud saya hanya setelah beberapa iterasi Anda tahu apa bentuk dialog Anda (dari garis lurus polos ke pohon kompleks atau mesin negara). Pada langkah-langkah pertama beberapa (paling mudah) seandainya + beberapa string kode keras ok imho. Kemudian ketika Anda dapat dengan jelas melihat kebutuhan Anda, membuat pilihan, setelah mengevaluasi biaya / manfaat dari setiap solusi.
GameAlchemist

Jalan tengah yang saya gunakan pada proyek one-man game saya saat ini adalah memiliki konten hard-coded yang dihasilkan dari file yang diuraikan sebelum waktu kompilasi. Dalam banyak kasus itu akan menjadi solusi terburuk dari kedua dunia, tetapi untuk apa yang saya butuhkan sebenarnya cukup bagus.
glenatron

2

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
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.