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

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