Bagaimana memilih cara menyimpan data?

Beri seorang pria ikan dan Anda memberinya makan selama sehari. Ajari pria memancing dan Anda memberinya makan seumur hidup. - Pepatah Cina

Saya bisa bertanya penyimpanan data seperti apa yang harus saya gunakan untuk proyek aktual saya, tetapi saya ingin belajar memancing , jadi saya tidak perlu meminta ikan setiap kali memulai proyek baru.

Jadi, sampai saya menggunakan dua metode untuk menyimpan data pada proyek non-game saya: file XML, dan database relasional. Saya tahu bahwa ada juga jenis database lain, dari jenis NoSQL . Namun saya tidak akan tahu apakah ada lebih banyak pilihan yang tersedia bagi saya, atau bagaimana memilih di tempat pertama, selain memilih secara sewenang-wenang.

Jadi pertanyaannya adalah sebagai berikut: Bagaimana saya harus memilih jenis penyimpanan data untuk proyek game?

Dan saya akan tertarik pada kriteria berikut ketika memilih:

• Ukuran proyek.
• Platform ditargetkan oleh game, serta platform pengembangan yang digunakan.
• Kompleksitas struktur data.
• Menambahkan Portabilitas data di antara banyak proyek.
• Ditambahkan2 penggunaan data secara siluman antara proyek yang berbeda. (yaitu data Pengguna)
• Menambahkan Seberapa sering data harus diakses
• Menambahkan beberapa tipe data untuk aplikasi yang sama
• Konfigurasi Ditambahkan2 dengan beberapa penyimpanan data.
• Hal lain yang menurut Anda menarik ketika memutuskan apa yang akan digunakan.

EDIT Saya tahu tentang Apakah lebih baik menggunakan XML / JSON / Teks atau database untuk menyimpan konten game? , tapi saya pikir itu tidak menjelaskan maksud saya. Sekarang jika saya salah, saya dengan senang hati akan ditampilkan kesalahan dengan cara saya.

EDIT2 Menambahkan beberapa poin lagi yang saya anggap relevan. Selanjutnya, saya akan tertarik untuk mendengar opsi apa yang tersedia, selain penyimpanan file flat dan basis data relasional. Bagaimana dengan database non-relasional, misalnya? Kapan relevan menggunakan basis data seperti itu di atas opsi lain yang disebutkan sebelumnya?

Pertanyaan Anda sangat luas karena banyaknya genre di luar sana, tapi inilah perspektif pengembang perangkat lunak profesional.

Anda memberikan daftar kriteria yang ingin Anda gunakan untuk menentukan mekanisme persistensi data mana yang Anda gunakan. Mereka adalah:

• Ukuran proyek.
• Platform ditargetkan oleh game.
• Kompleksitas struktur data.
• Portabilitas data di antara banyak proyek.
• Seberapa sering data harus diakses
• Beberapa tipe data untuk aplikasi yang sama
• Hal lain yang menurut Anda menarik ketika memutuskan apa yang akan digunakan.

Pertama kita perlu menetapkan opsi mana yang tersedia untuk kita. Karena Anda tidak menentukan bahasa atau teknologi, sulit untuk mengatakan dengan tepat, tetapi Anda mungkin mencoba untuk memutuskan antara XML dan penyimpanan basis data relasional .

Perbedaan penting untuk dibuat adalah bahwa XML sebenarnya bukan mekanisme penyimpanan seperti teknik serialisasi. Ini adalah cara untuk mewakili struktur dalam memori untuk gim Anda. Karena itu, Anda benar-benar berbicara tentang penyimpanan flat file vs. penyimpanan basis data relasional . Ini bukan satu-satunya pilihan, tapi itu yang paling umum, jadi saya akan menggunakannya.

Untuk file datar:

• XML
• JSON
• YAML
• XAML
• Teks Biasa

Untuk basis data:

• SQL Server
• MySQL
• DB2
• Peramal
• Masih banyak lagi

EDIT: Anda bertanya tentang jenis mekanisme lain selain dari file dan database relasional. Satu-satunya jenis database terkenal yang telah saya lihat digunakan secara teratur adalah database "Berkeley-style", yang pada dasarnya berbasis nilai kunci. Ini cenderung menggunakan B-tree untuk menyusun data sehingga pencarian cepat. Ini bagus untuk konfigurasi / pengaturan pencarian di mana Anda tahu persis apa yang Anda inginkan (misalnya, berikan saya semua data telemetri untuk "Level 1").

Sekarang kita sudah memiliki semua dasar-dasarnya, mari kita sentuh beberapa kriteria Anda.

Ukuran proyek.

Beberapa mungkin tidak setuju, tetapi ukuran proyek Anda tidak serta-merta berdampak besar pada mekanisme kegigihan data Anda. Anda ingin membangun pustaka fungsi yang dapat digunakan kembali yang menyimpan / memuat data dari mekanisme apa pun yang Anda inginkan. Saya bahkan menyarankan menerapkan lapisan abstraksi (lihat pola Adaptor ) sehingga Anda dapat dengan mudah mengubah mekanisme kegigihan Anda jika perlu.

Karena itu, untuk proyek-proyek kecil, menggunakan XML pada sistem file berpotensi bekerja dengan baik, tetapi Anda ingin mengatasi beberapa masalah keamanan Anda (yaitu, enkripsi) sehingga pemain tidak dapat mengubah data sesuka hati.

Platform ditargetkan oleh game.

Platform juga tidak akan menjadi masalah besar. Anda harus lebih peduli tentang platform pengembangan Anda daripada platform target. Alasan untuk ini adalah bahwa beberapa bahasa menangani jenis markup atau database tertentu lebih baik daripada yang lain di luar kotak. Itu bukan untuk mengatakan bahwa Anda tidak dapat menggunakan salah satu di atas dalam hampir semua bahasa, tetapi kadang-kadang lebih baik menggunakan alat yang didukung yang tersedia untuk Anda. Platform apa pun akan mendukung file datar dan parsing XML, tetapi pada platform seluler Anda mungkin ingin mempertimbangkan serialisasi biner jika memungkinkan, atau setidaknya mengoptimalkan XML Anda untuk penyimpanan.

Kompleksitas struktur data.

Ini agak sulit. Database relasional sangat bagus untuk itu ... menyimpan entitas dan hubungan mereka. Anda memiliki kemampuan yang lebih baik untuk menegakkan struktur menggunakan repositori penyimpanan relasional daripada yang Anda lakukan dengan file pada sistem file. Pertimbangkan jenis hubungan antara entitas Anda dan juga seberapa sering Anda mengubahnya atau menemukan entitas terkait. Untuk struktur yang sangat kompleks, saya akan menyarankan pergi dengan rute database.

Portabilitas data di antara banyak proyek.

Ketika datang ke portabilitas, Anda harus mempertimbangkan fakta bahwa database secara alami lebih berat daripada file. Ada instalasi dan konfigurasi overhead, database yang berbeda akan tersedia untuk platform yang berbeda, dll. SQLite adalah cara yang cukup bagus untuk ini. Namun, ketika datang ke portabilitas, Anda kemungkinan akan lebih mudah dengan solusi berbasis file seperti XML.

EDIT: Ada beberapa kekhawatiran lain yang Anda sebutkan tentang portabilitas di salah satu komentar Anda. Pada akhirnya Anda tidak ingin data Anda digabungkan terlalu erat dengan produk atau tipe file apa pun. Yang terbaik adalah jika Anda dapat menyimpan data stok (level, musuh, dll.) Dalam beberapa jenis format abstrak (file dibatasi tab, XML, dll.) Sehingga Anda dapat dengan mudah mem-parsing dan menyimpannya dalam database / sistem file saat kompilasi atau memuat waktu. Ini berarti bahwa Anda dapat menukar mekanisme penyimpanan Anda dengan iseng dan hanya menulis ulang bagian parsing.

Seberapa sering data harus diakses

Banyak akses data berarti banyak I / O kecuali Anda memiliki semacam mekanisme caching. Database menyimpan struktur dalam memori dan bagus untuk manipulasi dan pengambilan data. Jika Anda benar-benar terus-menerus menyimpan data, Anda mungkin ingin tetap menggunakan database.

Beberapa tipe data untuk aplikasi yang sama

Volume tentu saja menjadi pertimbangan, tetapi kecuali Anda berbicara tentang ribuan atau jutaan objek yang ada, sistem file masih dapat diterima sebagai solusi.

Tipe permainan

Jenis gim yang Anda bangun dapat memiliki pengaruh besar pada platform yang Anda pilih. Ya, untuk sebagian besar permainan pemain tunggal hanya klien, Anda akan baik-baik saja menggunakan solusi berbasis sistem file terkompresi atau terenkripsi. Jika Anda berbicara tentang game dengan komponen online, itu akan gila. Buka rute basis data dan simpan diri Anda dari sakit kepala. Biarkan server mengelola semua data Anda menggunakan kluster back-end.

Semoga beberapa umpan balik ini membantu. Ini sama sekali tidak sepenuhnya komprehensif, dan membuat keputusan pada akhirnya terserah Anda, tetapi komentar saya harus memberi Anda beberapa hal untuk dipikirkan.

EDIT: Ada beberapa saat di mana mengambil pendekatan hybdrid sangat masuk akal. Misalnya, katakanlah Anda sedang mengembangkan MMORPG. Di sisi klien, Anda dapat menyimpan data cache tentang pemain lain di basis data non-relasional (seperti yang disebutkan di atas). Di sisi server, Anda menyimpan semua data game dalam basis data relasional untuk bertahan. Dan sekali lagi di sisi klien Anda mungkin menyimpan data log, data konfigurasi, dll dalam file XML / flat untuk aksesibilitas yang lebih mudah.

Poster lain juga menyebutkan bahwa kadang-kadang itu bagus, bahkan jika Anda menyimpan data untuk produksi dalam database, untuk memiliki cara yang Anda dapat menggunakan file flat untuk pengembangan sebagai gantinya ... itu bisa lebih mudah untuk menghapus produk lain dari campuran .

Akhir-akhir ini saya menemukan diri saya terkendala oleh kekakuan / kesulitan menambahkan ke basis data relasional. Saya ingin menjelajahi basis data berbasis dokumen (misalnya couchdb), karena tampaknya sangat cocok untuk permainan, keadaan, dan fleksibilitas. Tetapi sebenarnya tidak praktis untuk mengatur beberapa tipe basis data untuk proyek kecil. Sebagai hasilnya, saya telah menyiapkan peretasan yang mirip dengan hanya menggunakan bidang gumpalan biner di bidang tertentu dari basis data.

Apa yang saya lakukan adalah menggunakan data yang dikodekan json dalam database dan pembungkus yang mengubah data menjadi json dan mundur kapan pun diperlukan. Jadi profil karakter dasar mungkin terlihat seperti ini di database:

{"char_id":24,"char_name":"tchalvak","level":43,"profile":"Some profile here."}

Json masih dapat dibaca dengan baik di dalam basis data sehingga jika Anda bekerja dengan logam dengan sql dan kadang-kadang mengakses database secara langsung juga, itu dapat dimodifikasi secara manual jika Anda mau.

Sekarang, semua itu adalah retasan, dan saya tidak menyarankan untuk menyalinnya, tapi inilah intinya secara keseluruhan: Jangan hanya mengandalkan satu sistem. Gunakan database relasional dan fudge sistem. Atau gunakan dua jenis sistem penyimpanan data yang berbeda (misalnya file datar dan basis data relasional?), Sehingga Anda dapat memperoleh manfaat paling banyak dari keduanya. Tidak peduli apa yang orang sarankan, atau sistem apa yang Anda gunakan, Anda akan menemukan situasi di mana pendekatan lain akan bekerja lebih baik, jadi bersiaplah untuk menambahkan alternatif dan melihat ke mana Anda akan pergi.

Dalam gen RTS, data game telah disimpan dalam file.

Unit dan atribut telah disimpan dalam file INI atau XML atau format berbasis teks lainnya, dan modelnya merupakan gabungan dari format berbasis biner atau bahkan berbasis teks, serta tekstur dan suara serta media lain dalam format mainstream. Kadang-kadang itu berada dalam wadah yang memiliki enkripsi kasar - format campuran Westwood muncul di pikiran. Tapi ini sebagian besar kebingungan - jika Anda melihat di dalamnya, mereka hanya file biasa dalam format yang mudah ditangani.

Dengan munculnya permainan online, data permainan menjadi semakin umum untuk disediakan pasca-pemasangan melalui internet, meskipun seringkali ini masih disimpan di sistem file.

Mengapa menggunakan satu metode penyimpanan data?

Dalam sebagian besar kasus, game yang Anda rilis ke dunia tidak membutuhkan fungsionalitas penyimpanan data yang sama dengan yang dibutuhkan game selama pengembangan.

Berikut perbandingan beberapa persyaratan rilis / pengembangan: -

Requirement      |  Release  |  Development  |  QA
==================================================
Multi user       |    No     |      Yes      |  No
Writable         |    No     |      Yes      |  No
Revision Control |    No     |      Yes      | Yes (but only reading)
Compact          |   Yes     |       No      |  No
Fast             |   Yes     |       No      |  No

Idealnya, Anda akan mendefinisikan antarmuka ke modul pemuatan data Anda dan kemudian membuat beberapa versi, masing-masing dirancang untuk kebutuhan spesifik.

Pada satu proyek yang saya kerjakan bertahun-tahun yang lalu, memuat data tingkat dari CD terlalu lama (dari HD juga tidak bagus). Jadi saya datang dengan yang berikut ini. Saya punya tiga metode untuk memuat data level: -

1. Pemuatan normal - untuk waktu pengembangan saat aset berubah
2. Pra-rilis - secara efektif metode untuk mengubah data normal menjadi data pemuatan cepat
3. Rilis - hanya data cepat (tidak dapat diedit)

Ini mengurangi waktu pemuatan dari menit ke detik.