Bagaimana saya bisa menangani perubahan versi ketika menyimpan aset?

Saya telah mengerjakan RPG sekarang untuk sementara dan saya menggunakan dua teknik serialisasi yang berbeda.

• Musuh, Senjata, item disimpan seperti XML.
• Peta dan acara disimpan sebagai "biner terkontrol" (setiap kelas mendapatkan metode simpan / muat dan mereka memutuskan apa yang ingin disimpan / dimuat).

Tapi saya sudah mulai mempertanyakan pilihan saya untuk peta dan acara. Kekhawatiran saya:

• Saya telah membuat editor peta tetapi saya masih rindu untuk dapat mengubah hal-hal kecil dengan hanya membuka file.
• Perubahan sangat kacau. Katakan bahwa saya ingin menambahkan variabel ke kelas, jika saya tidak memuat / menyimpan setiap peta lagi, ia akan rusak nanti.

Kekhawatiran pertama adalah sulit untuk berkeliling tanpa mengubah teknik saya. Saya berpikir untuk berganti ke JSON, tapi ini banyak pekerjaan. Saya juga berpikir itu terlihat sangat jelek dengan atribut [DataContract] dan [DataMember] di mana-mana.

Itu meninggalkan saya dengan keprihatinan kedua saya dan saya bertanya-tanya bagaimana saya bisa menghadapinya? Apakah Anda membuat program kecil yang mengulang semua peta dan menyimpannya kembali dengan variabel baru? Karena saya mulai mendapatkan beberapa peta sekarang dan saya masih melakukannya secara manual. Itu membuat saya berpikir dua kali setiap kali saya ingin melakukan beberapa perubahan karena itu membuat banyak pekerjaan tambahan.

Ada banyak cara untuk menangani masalah versi; Anda dapat melakukannya dengan memiliki satu fungsi pemuatan per versi, Anda dapat mencoba mengotomatiskan proses dengan menggambarkan (melalui atribut biasanya) transformasi struktur aset dari waktu ke waktu, Anda dapat melakukan pemeriksaan khusus versi di dalam fungsi pemuatan / penyimpanan, dan lain-lain .

Saya suka pendekatan "jelaskan perubahan" tetapi menemukan bahwa mencoba melakukannya melalui atribut menjadi canggung dengan cepat . Saya akan menggunakan fungsi sebagai gantinya; mengimplementasikan fungsi yang mengubah data dalam versi Nke data dalam versi N + 1untuk semua versi yang sesuai. Saat memuat, periksa versi terhadap yang terbaru dan jika tidak, jalankan data melalui semua fungsi versi yang sesuai. Selalu simpan versi terbaru.

Ini bekerja paling baik jika Anda melakukan transformasi ketika data masih dalam bentuk nilai kunci runtime. Ini berarti Anda mungkin ingin menerapkan representasi untuk data Anda yang merupakan pendekatan "runtime bag of properties", karena Anda tidak dapat menggunakan bentuk nilai kunci yang mendasari JSON atau XML jika Anda memiliki format biner sendiri. Jika Anda tidak melakukan ini, Anda juga mungkin perlu menjaga definisi kelas lama, yang menjadi jelek. Mampu memiliki aset Anda dalam format buruk properti ini juga sangat berguna untuk pengembangan editor game.

Selama pengembangan saat Anda mengulangi data Anda, itu akan secara alami melembung ke versi terbaru dan Anda akhirnya dapat menghapus fungsi versi lama. Ini kurang lebih pendekatan tingkat tinggi yang sama yang kami gunakan untuk menilai aset seni (seperti peta) di Guild Wars 2.

Sekarang, semua yang dikatakan, saya pikir itu berguna untuk mendukung serialisasi teks dan biner untuk aset. Selama pengembangan, simpan semua data Anda dalam format yang dapat dibaca manusia berdasarkan XML atau JSON. Ini dapat meningkatkan kemampuan iterasi Anda banyak karena Anda tidak perlu membuat alat yang rumit seperti saat mengedit data. Anda dapat kembali untuk membuat tweak cepat sederhana dengan tangan.

Kedua, dengan asumsi Anda bahkan masih menginginkan format biner untuk mengirimkan game (yang dapat meningkatkan ukuran file atau waktu IO file, jadi itu keinginan yang sah), rancang API serialisasi dan deserialisasi Anda untuk menangani versi. Versi ini masih berguna dalam konteks pengiriman, karena sebagai titik tertentu Anda mungkin ingin update kapal atau perbaikan bug. Ada beberapa dokumen yang menjelaskan kemampuan versi serialisasi .NET dan serialisasi Boost yang mungkin menarik. Jika Anda sedang akan mendukung kedua teks dan format biner, pastikan Anda menguji mereka kadang-kadang (atau otomatis membangun tes untuk melakukannya, bahkan lebih baik).

Gunakan bahasa markup dengan pasangan nilai atribut seperti XML atau JSON.

Parser dapat mengabaikan atribut apa pun yang tidak dimengerti atau menggunakan default untuk yang tidak ditemukannya, yang membuat kompatibilitas mundur dan maju cukup mudah. Juga, formatnya dapat dibaca oleh manusia sehingga Anda dapat dengan mudah mengeditnya dengan editor teks.

Saat Anda menggunakan bahasa mapan seperti XML atau JSON, Anda juga akan melihat bahwa banyak bahasa skrip mendukungnya, jadi ketika Anda masih perlu menulis skrip untuk mengedit sejumlah besar file, Anda akan merasa jauh lebih mudah untuk melakukannya.

Kelemahan dari sebagian besar bahasa ini adalah bahwa mereka cukup bertele-tele. Itu berarti file yang dihasilkan jauh lebih besar daripada yang diperlukan dengan format biner yang dioptimalkan. Saat ini, ukuran file tidak terlalu penting di sebagian besar situasi. Tetapi pada mereka yang penting, ukuran file sering dapat dikurangi secara signifikan dengan mengompresi file dengan algoritma stok seperti zip.

Bahasa markup sering tidak memungkinkan akses acak kecuali seluruh dokumen dibaca dari hard drive dan diuraikan. Namun dalam praktiknya ini tidak terlalu menjadi masalah, karena hard drive paling cepat dengan pembacaan berurutan. Secara acak mencari beberapa kali ke berbagai bagian file yang sama seringkali jauh lebih lambat daripada hanya membaca file dalam sekali jalan, bahkan ketika itu berarti Anda membaca lebih banyak data daripada yang Anda perlukan.

Anda dapat menggunakan protobuf. https://code.google.com/p/protobuf/ Ini memberi Anda keuntungan dari json / xml, bahwa Anda dapat dengan mudah memperpanjangnya sambil menjadi kompatibel ke belakang, ditambah keuntungan menjadi biner. Alur kerjanya adalah, bahwa Anda membuat deskripsi format data dalam bahasa protobuf dan kemudian menghasilkan kode sumber untuk serialisasi dan deserialisasi. Sumber dapat dihasilkan untuk beberapa bahasa. Juga merupakan keuntungan besar bahwa Anda memiliki spesifikasi yang jelas dari data serial Anda, berbeda dengan json di mana spesifikasi dilakukan secara implisit dalam membaca / menulis.