JSON в разработке игр: почему побеждает подход, управляемый данными

JSON в разработке игр — это способ описывать содержимое игры (уровни, предметы, характеристики врагов, баланс, настройки и файлы сохранений) в виде структурированного текста, который движок считывает во время выполнения, а не жёстко прописывает в исходном коде. Это разделение данных и кода называют подходом, управляемым данными (data-driven), и именно оно превращает процесс, доступный только программистам, в такой, где геймдизайнер может перенастроить оружие, добавить уровень или исправить опечатку без пересборки игры инженером. JSON стал самым распространённым форматом для таких данных, потому что это простой текст: его удобно читать, сравнивать в системе контроля версий и разбирать практически на любом языке программирования.

В этом разборе — что такое JSON на самом деле, что такое подход, управляемый данными, что стоит класть в JSON-файл, где он проигрывает (и когда лучше взять бинарный формат), как его используют крупные движки и какую путаницу важно избежать: формат JSON и архитектура, управляемая данными, — не одно и то же. Если нужно сравнение движков по этому признаку, его продолжает сравнение движков, управляемых данными.

Что такое JSON на самом деле#

JSON — JavaScript Object Notation — это текстовый формат для хранения структурированных данных в виде вложенных объектов и массивов. Он был выделен из синтаксиса объектных литералов JavaScript в начале 2000-х и стандартизирован как ECMA-404 и RFC 8259, но к JavaScript во время выполнения отношения не имеет: парсер JSON есть в каждом крупном языке. Запись оружия выглядит так:

{
  "id": "iron_sword",
  "name": "Iron Sword",
  "damage": 50,
  "weight": 3.5,
  "tags": ["melee", "metal"]
}

Существенны два технических момента — они объясняют, почему команды берут JSON и почему рано или поздно от него уходят.

• Это текст, а не бинарный формат. Каждое значение — читаемые символы. Файл можно открыть, прочитать и поправить вручную. Расплата — размер и скорость: те же данные занимают больше байтов, чем в бинарной кодировке, и разбираются дольше.
• У него нет схемы. JSON задаёт синтаксис (фигурные скобки, квадратные, кавычки), а не смысл. Формат не гарантирует, что damage — число или что у каждого оружия есть name. Эта свобода удобна на старте и опасна позже — тогда и появляются валидация и версионирование.

Идея, которая всё меняет: подход, управляемый данными#

Всё полезное, что даёт JSON в играх, вырастает из одного архитектурного решения: держать данные вне кода.

Без подхода, управляемого данными, конкретика игры живёт в исходниках: жёстко заданный int swordDamage = 50;, уровень, вшитый в исполняемый файл, реплика диалога внутри функции. Чтобы что-то изменить, программист правит код, перекомпилирует и выпускает новую сборку. С подходом, управляемым данными, код становится обобщённым — единственный класс Item, который читает урон, вес и теги из файла, — а конкретика живёт в данных, которые движок считывает во время выполнения. Изменить урон меча теперь — правка одной строки в items.json, без перекомпиляции.

Выгода вполне осязаема.

• Дизайнеры работают без программистов. Баланс, тексты и планировка уровней выходят из очереди задач разработчиков и переходят в файл, который может править человек без навыков программирования.
• Итерации ускоряются. Поправил данные, перезагрузил, увидел результат. В цикле нет шага сборки.
• Одна кодовая база, много контента. Сто уровней — это сто файлов данных, которые читает один загрузчик, а не сто веток кода.
• Открываются моддинг и поддержка игры после релиза. Если содержимое игры — это данные, игроки могут их менять, а вы — настраивать баланс уже после запуска, выпуская новые данные, а не новые бинарные файлы.

Что стоит класть в JSON#

В проекте, управляемом данными, кандидат на перенос в файл — почти всё, что является контентом, а не поведением.

Тип данных	Пример	Почему подходит
Характеристики предметов, врагов и персонажей	Здоровье, урон, шанс выпадения	Постоянно настраиваются; нужны ручные правки
Уровни и карты	Тайловая раскладка, расстановка сущностей	Объёмные, делает геймдизайнер; инструменты вроде LDtk экспортируют их в JSON
Диалоги и локализация	Строки по идентификатору	По файлу на язык; переводят, не трогая код
Настройки и баланс	Кривые сложности, ставки экономики	Числа, которые меняются во время плейтеста
Файлы сохранений	Прогресс игрока, инвентарь	Записываются и читаются во время выполнения; текст помогает при отладке
Манифесты ассетов и данные сборки	Что грузить и в каком порядке	Управляют пайплайном; удобно сравнивать

Далеко не всё стоит выносить сюда. Узкие внутренние циклы — покадровое обновление тысяч частиц — требуют данных, уложенных под кэш процессора, а не разбираемых из текста. Это отдельная задача, о ней ниже.

Почему именно JSON — и где он проигрывает#

JSON занял своё место читаемостью, универсальностью и удобством сравнения версий. Но его слабости реальны, и зрелые движки относят JSON к одному из инструментов, а не к выбору по умолчанию.

Честные минусы:

• Размер. Текст многословен. Число, записанное как "damage": 50, занимает несколько байтов; в бинарном формате это может быть один-два.
• Стоимость разбора. Читать и проверять текст при каждой загрузке медленнее, чем бинарный формат. Для файла настроек, который грузится один раз, это незаметно. Для уровня, подгружаемого прямо во время игры, может оказаться существенным.
• Нет типобезопасности. Поскольку у JSON нет схемы, опечатка в ключе или неверный тип всплывают во время выполнения, а не при компиляции.
• Дрейф схемы. Когда структура данных меняется, старые файлы ломаются, если не ввести версионирование и миграцию.

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

Формат	Что это	В чём силён
JSON	Простой текст, без схемы	Читаемость, инструмент, удобство сравнения версий
MessagePack / CBOR	Бинарный JSON — та же модель, компактные байты	Сжатие без потери гибкости JSON
Protocol Buffers	Бинарный, схема прежде всего (.proto плюс генерация кода)	Самые компактные данные, типобезопасность, сетевые протоколы
FlatBuffers	Бинарный, без копирования (создан в Google для игр)	Доступ к полям без разбора всего буфера; минимум нагрузки на процессор

Распространённый приём — авторить и редактировать в тексте (JSON), а на релиз «собирать» в бинарный формат. Так читаемость JSON остаётся на этапе разработки, а скорость бинарного формата — в руках игрока.

Как JSON применяют крупные движки#

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

Движок	Формат данных	Что управляется данными
GDevelop	Весь проект — один JSON-файл (game.json)	Всё: объекты, события, сцены — это данные
GameMaker	Файл проекта .yyp — JSON; комнаты и объекты — JSON-ресурсы	Сцены и определения объектов
RPG Maker MV/MZ	База данных — отдельные JSON-файлы (Actors.json, Items.json, …)	Вся игра: характеристики, навыки, враги — база данных в JSON
Unity	JsonUtility и ScriptableObject	Вы сами строите конвейер данных
Godot	Читаемые текстовые ресурсы (.tres, .tscn) и класс JSON	Ресурсы и сцены — текст; не JSON, но та же идея
MonoGame	Встроенного нет — вы подключаете библиотеку вроде System.Text.Json	Фреймворк с акцентом на код; модель данных полностью ваша

Два честных уточнения. Godot целиком построен на данных, но его родной формат — собственный текстовый синтаксис, а не JSON; JSON доступен как опция. Construct хранит листы событий и раскладки как XML внутри архива .c3p, так что он управляется данными, но без JSON. Вывод: подход, управляемый данными, — это идея, а JSON, XML и текстовые ресурсы — лишь способы её переносить.

Частые ошибки#

Ошибка	Что идёт не так	Что делать вместо этого
Жёстко прописанные значения, которые часто меняются	Каждая правка баланса требует программиста и перекомпиляции	Вынесите настраиваемые числа в файл данных JSON
Слепое доверие к непроверенному JSON	Неверный тип поля или отсутствующий ключ роняет игру во время выполнения	Проверяйте данные по схеме; на этапе разработки падайте громко
Отсутствие версионирования схемы	Изменение формата незаметно ломает старые сохранения и моды	Версонируйте данные и предусматривайте путь миграции
Разбор JSON в горячем цикле	Повторный разбор текста каждый кадр убивает производительность	Разберите данные один раз в объекты; для массовых данных берите бинарный формат
Путаница между JSON и подходом, управляемым данными	Вы выбираете формат вместо того, чтобы отделить данные от кода	Сначала решите, что данные, а что код; затем выбирайте JSON или бинарный формат

Роль Egmatic#

Egmatic построен вокруг подхода, управляемого данными, на уровне архитектуры. Он чётко разделён на две части: редактор, в котором создают игру, и движок, который её запускает, а единственное, что пересекает эту границу, — контракт на основе версионированного JSON. Редактор порождает игровые данные в JSON; движок их потребляет. Между ними нет общего кода — только данные.

Это подход, управляемый данными, доведённый до конца: игра и есть данные, редактор — инструмент, который их формирует, а движок — интерпретатор, который их запускает. Egmatic работает поверх рантайма MonoGame, который сам по себе — фреймворк с акцентом на код, без встроенной модели данных: именно этот разрыв и заполняет редактор, управляемый данными. О том, как движки соотносятся по этому признаку, рассказывает сравнение движков, управляемых данными, а разбор графа сцены показывает, как описывающие мир данные упорядочиваются после того, как движок их загрузил.

Итог#

JSON в разработке игр — это практика переноса содержимого игры в виде структурированного текста, который движок считывает во время выполнения, то есть конкретное воплощение подхода, управляемого данными: данные держат вне кода, чтобы дизайнеры могли менять игру без пересборки инженером. JSON силён читаемостью, универсальностью и удобством контроля версий — поэтому так много движков и инструментов используют его: файл проекта в GDevelop, база данных в RPG Maker, ресурсы в GameMaker, JsonUtility в Unity и редакторы уровней вроде LDtk. Его минусы — размер, скорость разбора и отсутствие встроенной схемы, поэтому там, где важна производительность, переходят на бинарные форматы: FlatBuffers, Protocol Buffers или MessagePack, часто после авторинга в тексте.

Главное, что стоит запомнить, — это различие: JSON — формат, а подход, управляемый данными, — архитектура. Управляться данными можно и через XML, и через текстовые ресурсы, и через бинарный формат; JSON — просто самый популярный носитель. Сначала отделите данные от кода, а формат выбирайте потом.

---

Источники#

1. Спецификация JSON — лёгкий, не зависящий от языка, читаемый человеком текстовый формат данных — RFC 8259: The JSON Data Interchange Syntax
2. Подход, управляемый данными — отделение содержимого и параметров геймплея от кода, при котором движок интерпретирует данные во время выполнения — Википедия: Data-driven programming
3. GDevelop — весь проект сохраняется одним JSON-файлом — GDevelop wiki: Project manager
4. Формат проекта GameMaker — файл .yyp хранит проект в JSON — GameMaker Manual: Project format
5. База данных RPG Maker MV/MZ — актёры, предметы, враги и навыки хранятся отдельными JSON-файлами в папке data/ — RPG Maker Wiki: Database
6. Unity ScriptableObject и JsonUtility — проектирование данных через ассеты и сериализация в JSON — Unity Manual: JSON Serialization
7. Ресурсы Godot — .tres и .tscn как читаемые человеком текстовые форматы, удобные для контроля версий — Godot docs: TSCN file format
8. LDtk — современный открытый редактор 2D-уровней, сохраняющий уровни в чистом JSON — LDtk JSON documentation
9. FlatBuffers — библиотека бинарной сериализации, созданная для разработки игр и поддерживающая чтение без копирования — FlatBuffers documentation