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

Четыре месяца я разрабатываю пошаговый футбольный менеджер Kickoff Island. Игра строится вокруг уникальных игроков, команд и тактик. Кстати, уникальность игроков больше всего добавляет мне и трудностей, так как прорисовка их всех, а еще и покадровая анимация в Aseprite, тот еще геморрой. В какой‑то момент передо мной встал, казалось бы, простой, но важный вопрос: как хранить всех этих футболистов, их характеристики, таланты и состояния?

Казалось бы, выбор огромен: MySQL, SQLite,.tres‑файлы, JSON... Я перебрал несколько вариантов, и сейчас расскажу, почему остановился на JSON — и почему это оказалось не компромиссом, а лучшим решением для инди‑разработки.

Почему не MySQL и не SQLite

Реляционные базы данных я отбросил почти сразу. Да, они хороши для сложных запросов и связей между таблицами, но в моей игре:

• Всего несколько десятков игроков и столько же команд.

• Нет сложных JOIN‑запросов (мне не нужно агрегировать данные по десяти таблицам).

• База не растет, и не будет расти, до миллионов записей.

Все вышеперечисленное, кстати, не является издержками игры, а сознательный выбор в пользу её сюжетности и механик, отличающихся от классического футбольного менеджера. В принципе, игра вполне могла бы стать RPG, но один я бы это точно не потянул.

Итак, держать полноценный SQL‑сервер или даже SQLite‑файл для 30–50 игроков — это как стрелять из пушки по воробьям: усложняет код, добавляет лишние зависимости и требует дополнительных библиотек.

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

Почему не.tres (ресурсы Godot)

Следующим кандидатом были.tres‑файлы — родные ресурсы моего любимого движка Godot. Да, у них есть плюсы: встроенная валидация типов, быстрая загрузка, интеграция с редактором.

Но меня они не устроили по нескольким причинам:

Почему я выбрал 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.