Як я можу впоратися із змінами версій під час збереження активів?

Я працюю над RPG зараз деякий час, і я використовую дві різні методи серіалізації.

• Вороги, зброя, елементи зберігаються як XML.
• Карти та події зберігаються як "керовані двійкові" (кожен клас отримує метод збереження / завантаження і вони вирішують, що хочуть зберегти / завантажити).

Але я почав ставити під сумнів свій вибір для карт та подій. Мої проблеми:

• Я створив редактор карт, але мені все одно не вистачає можливості змінити дрібниці, просто відкривши файл.
• Зміни безлад так сильно. Скажіть, що я хочу додати змінну до класу, якщо я знову не завантажую / зберігаю кожну карту, вона згодом зламається.

Перше занепокоєння важко обійти, не змінюючи свою техніку. Я думав про перехід на JSON, але це дуже багато роботи. Я також думаю, що це виглядає досить некрасиво з атрибутами [DataContract] та [DataMember] скрізь.

Це залишає мене своєю другою турботою, і мені цікаво, як я можу з цим боротися? Чи створюєте ви невелику програму, яка прокручує всі карти та відновлює їх за допомогою нової змінної? Тому що я починаю отримувати пару карт зараз, і все ще роблю це вручну. Це змушує мене думати двічі кожен раз, коли я хочу зробити якісь зміни, оскільки це створює багато зайвої роботи.

Існує маса способів вирішити проблему з версією; ви можете зробити це, маючи одну функцію завантаження в кожній версії, ви можете спробувати автоматизувати процес, описуючи (за допомогою атрибутів зазвичай) трансформацію структури активів у часі, ви можете робити перевірку, що залежить від версії всередині функцій завантаження / збереження, тощо. .

Мені подобається підхід "описати зміни", але я вважаю, що намагатися зробити це за допомогою атрибутів стає незручно швидко . Я б замість цього використовував функції; реалізуйте функцію, яка перетворює дані у версії Nдо даних у версії N + 1для всієї відповідної версії. Під час завантаження перевіряйте версію на останню версію, а якщо її немає, запустіть дані через усі відповідні функції версії. Завжди зберігайте останню версію.

Це найкраще спрацьовує, якщо ви перетворитесь, коли дані все ще знаходяться у формі ключ-значення часу виконання. Це означає, що ви, мабуть, захочете запровадити подання для своїх даних, що є підходом до "пакету ресурсів виконання", оскільки ви не можете використовувати базову форму JSON або XML, що має базове значення, якщо у вас є власний бінарний формат. Якщо ви цього не зробите, вам також може знадобитися зберегти старі визначення класу, що стає некрасивим. Можливість мати свої активи в поганому форматі властивості також надзвичайно корисна для розробки редакторів ігор.

Під час розробки, коли ви повторюєте свої дані, вони, природно, перетворюються на останню версію, і ви можете згодом видалити старі функції версій. Це більш-менш той самий підхід на високому рівні, який ми використовували для версії художніх активів (наприклад, карти) в Guild Wars 2.

Тепер, все, що сказано, я думаю, що корисно підтримувати як текстову, так і двійкову серіалізацію для активів. Під час розробки зберігайте всі свої дані у читаному для людини форматі на основі XML або JSON. Це може значно збільшити вашу здатність до ітерації, оскільки не потрібно створювати такі складні інструменти для редагування даних. Ви можете повернутися до можливості робити прості швидкі налаштування вручну.

По-друге, якщо ви навіть все ще хочете двійкового формату для доставки гри (що може поліпшити розмір файлу або час вводу файлу, тому це дійсне бажання), розробіть свої API для серіалізації та десеріалізації для обробки версій. Версія все ще корисна в контексті доставки, тому що, можливо, ви хочете відправити оновлення або виправлення помилок. Існує декілька документів, що описують можливості версії серіалізації .NET та серіалізації Boost, які можуть вам бути цікавими. Якщо будуть йти на підтримку як текст , так і бінарні формати, переконайтеся , що ви перевірити їх час від часу (або будують автоматизовані тести , щоб зробити це, навіть краще).

Використовуйте мову розмітки з парами атрибутів-значень, такими як XML або JSON.

Аналізатор може просто ігнорувати будь-які атрибути, які він не розуміє, або використовувати типові параметри для будь-яких, які не знаходить, що робить сумісність назад і вперед досить просто. Також формат читається людиною, тому ви можете легко редагувати його за допомогою текстового редактора.

Коли ви користуєтесь такою усталеною мовою, як XML або JSON, ви також помітите, що багато мов скриптів підтримують її, тому коли вам все-таки потрібно написати сценарій для редагування великої кількості файлів, вам це стане набагато простіше.

Недолік більшості цих мов полягає в тому, що вони досить багатослівні. Це означає, що отримані файли набагато більше, ніж вони повинні мати оптимізований бінарний формат. На сьогоднішній день розмір файлів у більшості ситуацій не має великого значення. Але в тих випадках, коли це має значення, розмір файлів часто може бути значно зменшений, стискаючи файл за допомогою алгоритму запасів, як zip.

Мови розмітки часто не дозволяють отримати випадковий доступ, якщо весь документ не зчитується з жорсткого диска та аналізується. Але на практиці це не так важливо, тому що жорсткі диски найшвидші з послідовним зчитуванням. Довільно шукати кілька разів до різних частин одного файлу часто може бути набагато повільніше, ніж просто читати файл за один раз, навіть коли це означає, що ви читаєте більше даних, ніж потрібно.

можна використовувати протобуф. https://code.google.com/p/protobuf/ Він надає вам переваги json / xml, що ви можете легко розширити його, будучи сумісним назад, плюс перевагу бути двійковим. Робочий процес полягає в тому, що ви створюєте опис формату даних мовою протобуфа, а потім генеруєте вихідний код для серіалізації та десеріалізації. Джерело можна генерувати для кількох мов. Також великою перевагою є те, що ви маєте чітку специфікацію своїх серіалізованих даних, на відміну від json, де специфікація робиться неявно під час читання / запису.