Как я хранил данные в Godot: почему JSON победил .tres и MySQL

от автора

Привет, Хабр!

Четыре месяца я разрабатываю пошаговый футбольный менеджер 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/