Як вибрати, як зберігати дані?

Дайте чоловікові рибу, і ви годуєте його на день. Навчіть чоловіка ловити рибу, а ви його годуєте все життя. - Китайське прислів’я

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

Отже, поки я не застосував два способи для зберігання даних про мій неігровий проект: XML-файли та реляційні бази даних. Я знаю, що існує також інший вид бази даних, типу NoSQL . Однак я не знаю, чи є у мене більше вибору, або як вибрати в першу чергу, окрім довільного вибору.

Отже, питання наступне: як я повинен вибрати тип зберігання даних для ігрового проекту?

І мені було б цікаво наступний критерій при виборі:

• Розмір проекту.
• Платформа, на яку спрямована гра, а також використовувана платформа розвитку.
• Складність структури даних.
• Додано портативність даних серед багатьох проектів.
• Додано2 Симутальне використання даних серед різних проектів. (тобто дані користувача)
• Додано Як часто слід отримувати доступ до даних
• Додано кілька типів даних для однієї програми
• Додано2 конфігурацію з кількома сховищами даних.
• Будь-який інший момент, який, на вашу думку, представляє інтерес, коли ви вирішуєте, чим користуватися.

EDIT Я знаю про Чи було б краще використовувати XML / JSON / Text або базу даних для зберігання вмісту гри? , але думав, що це не стосується моєї точки зору. Тепер, якщо я помиляюсь, я б гладко показав помилку в своїх шляхах.

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

Ваше запитання дійсно широке через велику кількість жанрів там, але ось точка зору професійного розробника програмного забезпечення.

Ви надали перелік критеріїв, які ви хочете використовувати, щоб визначити, який механізм збереження даних ви використовуєте. Це були:

• Розмір проекту.
• Платформа, на яку спрямована гра.
• Складність структури даних.
• Переносимість даних серед багатьох проектів.
• Як часто слід отримувати доступ до даних
• Кілька типів даних для однієї програми
• Будь-який інший момент, який, на вашу думку, представляє інтерес, коли ви вирішуєте, чим користуватися.

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

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

Для плоских файлів:

• XML
• JSON
• ЯМЛ
• XAML
• Простий текст

Для баз даних:

• SQL Server
• MySQL
• DB2
• Oracle
• Набагато більше

EDIT: Ви запитали про інші типи механізмів, окрім файлів та реляційних баз даних. Єдиний інший помітний тип баз даних, який я бачив регулярно, - це бази даних "у стилі Берклі", які по суті базуються на ключових значеннях. Вони, як правило, використовують B-дерева для структурування даних, так що пошуки швидко проходять. Вони чудово підходять для пошуку конфігурації / налаштування, де ви точно знаєте, що хочете (наприклад, дайте мені всі телеметричні дані для "Рівень 1").

Тепер, коли у нас всі основи не вдається, давайте торкнемося деяких ваших критеріїв.

Розмір проекту.

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

Сказавши, що для невеликих проектів використання XML у файловій системі потенційно може працювати добре, але ви захочете вирішити деякі проблеми безпеки (тобто шифрування), щоб гравці не змогли змінювати дані за власним бажанням.

Платформа, на яку спрямована гра.

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

Складність структури даних.

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

Переносимість даних серед багатьох проектів.

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

EDIT: Є кілька інших проблем, які ви згадали про переносимість в одному зі своїх коментарів. Зрештою, ви не хочете, щоб ваші дані занадто щільно поєднувалися з будь-яким продуктом чи файлом. Зрештою, найкраще, якщо ви можете зберігати дані про запаси (рівні, вороги тощо) у якомусь абстрактному форматі (файли з обмеженими вкладками, XML тощо), які ви можете легко проаналізувати та зберігати в базі даних / файловій системі при компіляції або завантаженні час. Це означає, що ви можете замінити свій механізм зберігання на примху і просто переписати фрагмент розбору.

Як часто слід отримувати доступ до даних

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

Кілька типів даних для однієї програми

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

Тип гри

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

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

РЕДАКТУВАННЯ: Є деякі випадки, коли застосування гібридного підходу має багато сенсу. Наприклад, скажімо, що ви розробляєте MMORPG. На стороні клієнта ви можете зберігати кешовані дані про інших гравців у нереляційній базі даних (як зазначено вище). На стороні сервера ви зберігаєте всі дані гри у реляційній базі даних, щоб зберегти їх. А потім знову на стороні клієнта ви, ймовірно, зберігаєте дані журналу, конфігураційні дані тощо у файлах XML / flat для легшої доступності.

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

Останнім часом я опинився обмеженим жорсткістю / складністю додавання до реляційних баз даних. Я хотів би вивчити бази даних, засновані на документах (наприклад, couchdb), оскільки вони здаються дуже придатними для ігор, стану та гнучкості. Але налаштовувати кілька типів баз даних для невеликого проекту не реально. Як результат, я встановив хак, подібний просто до використання бінарного поля blob у певних полях бази даних.

Я роблю це використання даних, кодованих json в базі даних, і обгортки, яка перетворює дані в json і повертається назад, коли це потрібно. Отже, базовий профіль символів може виглядати так у базі даних:

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

Json все ще добре читається в базі даних, тому якщо ви працюєте оголеними до металу з sql, а іноді також отримуєте доступ до бази даних безпосередньо, це можливо змінювати вручну, якщо ви хочете.

Тепер усе це хак, і не раджу копіювати, але ось загальний пункт: Не покладайтеся лише на одну систему. Використовуйте реляційну базу даних і розтушовуйте систему. Або використовуйте два різних типи систем зберігання даних (наприклад, плоский файл та реляційну базу даних?), Щоб ви могли отримати максимальну користь від обох. Незалежно від того, що пропонують люди чи з якою системою ви їдете, внизу лінії ви знайдете обставини, коли інший підхід працював би краще, тому будьте готові додати альтернативу та подивіться, куди це вас веде.

У гені RTS дані гри зберігаються у файлах.

Одиниці та атрибути зберігаються у файлах INI або XML чи інших текстових форматах, а моделі - це поєднання бінарних або навіть текстових форматів, а також текстур та звуків та інших носіїв у основних форматах. Іноді це було в контейнері з сирим шифруванням - на думку приходить мікс-формат Вествуда. Але це здебільшого затуманення - якщо ви заглянете всередину них, вони є просто нормальними файлами, які легко обробляють формати.

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

Навіщо використовувати один метод зберігання даних?

У більшості випадків гра, яку ви випускаєте у світ, не потребує тієї ж функції зберігання даних, якої потрібна грі під час розробки.

Ось порівняння деяких вимог до випуску / розробки: -

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

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

В одному проекті, над яким я працював багато років тому, завантаження даних про компакт-диск забиралося занадто довго (відключення HD також не було великим). Тому я придумав таке. У мене було три методи для завантаження даних про рівень:

1. Звичайне завантаження - на час розробки, коли активи змінювалися
2. Попередній випуск - ефективно метод перетворення звичайних даних у швидкі завантаження даних
3. Випуск - лише швидкі дані (не можна редагувати)

Це зменшило час завантаження з хвилин до секунд.