Привет, Хабр!
Четыре месяца я разрабатываю пошаговый футбольный менеджер Kickoff Island. Игра строится вокруг уникальных игроков, команд и тактик. Кстати, уникальность игроков больше всего добавляет мне трудностей, так как прорисовка их всех, а еще и покадровая анимация в Aseprite, тот еще геморрой. В какой-то момент передо мной встал, казалось бы, простой, но важный вопрос: как хранить всех этих футболистов, их характеристики, таланты и состояния?
Казалось бы, выбор огромен: MySQL, SQLite, .tres-файлы, JSON… Я перебрал несколько вариантов, и сейчас расскажу, почему остановился на JSON — и почему это оказалось не компромиссом, а лучшим решением для инди-разработки под руководством меня одного.
Почему не MySQL и не SQLite
Я сразу отбросил реляционные базы данных. Да, они хороши для сложных запросов и связей между таблицами. Но в моей игре:
-
Всего несколько десятков игроков и столько же команд.
-
Нет сложных JOIN-запросов (мне не нужно агрегировать данные по десяти таблицам).
-
База не растет, и не будет расти, до миллионов записей.
Все вышеперечисленное, кстати, не является издержками игры, а сознательный выбор в пользу её сюжетности механик, отличающихся от классического футбольного менеджера. Как я уже рассказывал раньше, копировать то, что уже создано, мне не хотелось.
Итак, держать полноценный SQL-сервер или даже SQLite-файл для 30–50 игроков — это как стрелять из пушки по воробьям. Это усложняет код, добавляет лишние зависимости и требует дополнительных библиотек.
К тому же, с JSON я могу открыть файл в блокноте, найти нужного игрока и быстро исправить ему характеристику, не запуская редактор баз данных. Удобно.
Почему не .tres (ресурсы Godot)
Следующим кандидатом были .tres-файлы — родные ресурсы моего любимого движка Godot. У них есть плюсы: встроенная валидация типов, быстрая загрузка, интеграция с редактором.
Но меня они не устроили по нескольким причинам:
|
Проблема |
Почему это важно |
|---|---|
|
Бинарный формат |
Я не могу открыть .tres в обычном текстовом редакторе и быстро поправить ошибку. Приходится лезть в редактор Godot. |
|
Привязка к движку |
Если я захочу сделать веб-админку для управления составом команды — я не смогу прочитать .tres-файл без Godot. |
|
Миграции |
При изменении структуры класса игрока (например, я добавил новое поле «скорость») мне пришлось бы переписывать все ресурсы вручную. |
|
Гибкость |
В моей игре игроки генерируются динамически. Создавать новый .tres-ресурс для каждого новичка — слишком тяжеловесно. |
Почему я выбрал JSON
JSON стал победителем. И вот почему.
1. Человекочитаемость
Я открываю players.json в любом текстовом редакторе и вижу четкую структуру:
{"id": 1,"general": {"first_name": "Тест","last_name": "Автозагрузка","age": 16,"team": "1"},"stats": {"pass": 50,"tackle": 50,"shot": 50},"talent_id": 1,"talent_level": 0}
Это не просто данные — это документ, который я могу понять без документации.
2. Простота интеграции с Godot
В Godot есть встроенный класс JSON. Парсинг происходит в пару строк:
var json = JSON.new()var error = json.parse(file.get_as_text())var data = json.get_data()
3. Универсальность
Я могу использовать JSON на сервере, в веб-интерфейсе, в мобильном приложении. Это не привязывает меня к Godot.
4. Простота миграции
Когда я добавил новое поле «is_injured», я просто написал скрипт, который прошелся по всем игрокам и добавил это поле. С .tres-файлами это было бы огромной головной болью.
Как это работает в Kickoff Island
В моей игре данные хранятся в двух основных JSON-файлах (но есть и другие, например, переписка с родственниками и игроками команды по телефону):
-
players.json— список всех игроков с их характеристиками, талантами, состоянием и командами. -
teams.json— список команд с названиями, статистикой.
Есть также файл — formation.json, который хранит расстановку игроков на поле. Это позволяет мне гибко менять тактику, не затрагивая основные данные.
Все данные загружаются через синглтон DatabaseManager.gd, который работает с JSON-файлами, обеспечивая чтение, запись и синхронизацию данных.
Что я понял за эти четыре месяца
Выбор формата хранения — это не вопрос «а что круче». Это вопрос «а что проще и удобнее для моей задачи». В целом я придерживался такого правила и при выборе пиксельной графики. Но тут, правда, история вопроса несколько шире, и я о ней уже рассказывал.
Для моего проекта (небольшое количество данных, частые правки вручную, активная разработка с миграциями) JSON оказался идеальным выбором. Он не требует установки дополнительных библиотек, не привязывает меня к движку и позволяет быстро вносить изменения.
Если вам интересно, как я делаю пошаговый футбольный менеджер с пиксельной графикой и тактическими матчами, заглядывайте в сообщество VK:
👉 https://vk.com/plus3s_club
ссылка на оригинал статьи https://habr.com/ru/articles/1075498/