Нужна ли игре база данных: файлы или сервер

Почти любой инди-игре база данных не нужна. Одиночной игре до самого релиза хватает файла сохранения, файла настроек и облачной синхронизации стора. Даже серверы Minecraft держат состояние огромных сообществ на обычных сжатых файлах, без базы в любом виде. Серверная база оправдана при трёх условиях: в одни и те же данные пишут одновременно с разных сторон; запросы идут сквозь игроков; за одно живое состояние отвечают несколько процессов. Если ни одно из этих условий про вашу игру не выполняется, вам нужны файлы, а не база.

У вопроса есть родословная, и она заслуживает уважения. В сентябре на r/gamedev разработчик спросил, почему некоторые игры используют базы данных, и для примера привёл Tibia. Тред с того дня так и висит с нулём ответов. Мы следим за сообществами ради этого блога. Вопрос без единого ответа — готовая заявка на материал: большинство читателей сайта живёт как раз там, где бэкенда нет и не планируется. Сам вопрос хороший, просто задан чуть мимо. И поправка к нему полезнее прямого ответа. За словом «база данных» стоят три разных инструмента, а выбор между ними — дизайнерское решение на один вечер.

Короткий ответ#

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

Что люди называют базой данных#

Вопрос из треда буксует, потому что одно слово накрывает три разных инструмента.

Формат хранения на диске. Файлы сохранений, файлы уровней, конфиги. Это данные, но JSON-файл никто не называет базой — до тех пор, пока у него не вырастут индексы и транзакции. А в этот момент он действительно ею становится.

Встраиваемый движок. Канонический пример — SQLite. По документации создателей, это самодостаточный SQL-движок, который целиком работает внутри процесса: без сервера, без настройки, с транзакциями. Вся база — один кроссплатформенный файл. Создатели относят его к самым распространённым программным модулям вообще, его часто называют самым установленным движком баз данных в мире. А Adobe сделала его нативным форматом файлов Photoshop Lightroom. Это настоящая база с настоящим SQL, и всё же запускать сервер не нужно.

Клиент-серверная база. PostgreSQL, MySQL и их родственники. Они существуют ради одной цели: согласовывать много записей с разных машин через единый авторитет в сети. Всё, что такие системы берут сложностью, они отдают одновременными записями, порядком блокировок и защитой от падений между процессами.

Над третьей полкой пристраивается четвёртая: управляемые бэкенд-сервисы вроде Firestore, Supabase, LootLocker и PlayFab — база, обёрнутая в авторизацию, клиентские SDK и ежемесячный счёт. Когда разработчик игры говорит «наверное, мне нужна база данных», он почти всегда имеет в виду именно эту полку. Честный ответ начинается уровнем ниже.

Когда файлов хватает#

Одиночная игра создаёт ровно один поток записей на игрока, и файлы справляются с ним без напряжения. Доказательство — не аргумент, а крупнейшая песочница в истории игр. Java-сервер Minecraft хранит состояние каждого игрока сжатым NBT-файлом в playerdata/<UUID>.dat, настройки мира — в level.dat, рельеф — в регионных файлах. Базы нет нигде, и на этой архитектуре работают серверы с таким числом игроков, какое большинство инди-мультиплеерных проектов встретит только в мечтах.

У файлов есть обязанности, и выполнять их дёшево. Версия формата в каждом сохранении: старые файлы должны переживать патчи. Атомарная запись: сначала пишем во временный файл, потом переименовываем. Тогда падение посреди сохранения не убьёт часы прогресса. Наконец, структура, которую можно отладить глазами. Именно это — главный аргумент за JSON и другие открытые форматы; мы разбирали их в статье про JSON в разработке игр.

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

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

Три признака, что нужна серверная база#

Решение здесь не про гигабайты. Оно про то, кто пишет и кто спрашивает.

1. В общее состояние пишут одновременно. Мир, где двое открывают один сундук. Асинхронный мультиплеер, где сессия живёт, пока второй игрок офлайн. Эти записи должен упорядочивать один авторитет — сервер с базой за спиной.
2. Запросы идут сквозь игроков. Топ-100, пулы матчмейкинга, аудит экономики, «у кого из игроков есть этот предмет». Как только вы ранжируете или соединяете данные разных игроков, файлы перестают быть инструментом. Именно здесь гайд по лидербордам без бэкенда проводит границу между таблицей очков и соревновательной механикой.
3. Живых процессов больше одного. В день, когда вы поднимаете второй процесс игрового сервера ради ёмкости или регионов, общему состоянию нужен дом, не принадлежащий ни одному из них. Такой дом — клиент-серверная база или сервис поверх неё.

Есть и четвёртый, мягкий сигнал: кроссплатформенная личность игрока. Когда сохранение должно следовать за человеком из Steam в мобильные устройства, синхронизации сторов перестают понимать друг друга. Нужен кто-то нейтральный над обоими сторами, кто держит состояние. Об этом у нас есть отдельный разбор — как синхронизировать сохранения между Steam и мобильными. Заметьте, что это за «кто-то»: обычно небольшая запись на игрока в готовом хранилище, а не схема из сорока таблиц.

Вопрос про Tibia — напрямую#

Tibia заслужила упоминание в том вопросе честно. Игра онлайн с января 1997 года, её построили четыре студента из Регенсбурга, и по цифрам CipSoft к двадцатилетию набралось около 30 миллионов аккаунтов. Доклад GDC об инфраструктуре игры описывал примерно 300 000 активных игроков, круглосуточно, без выходных. В середине 2000-х операторы Tibia сравнили свою живую нагрузку на трёх системах: PostgreSQL 7 против Oracle RAC и IBM DB2. Вот результат, смиряющий любую самодельную архитектурную диаграмму: PostgreSQL оказался чуть быстрее и радикально дешевле.

На таком масштабе «игры вроде Tibia» и обходятся обычной реляционной базой. База никогда не была там сложной частью. Сложная часть — дисциплина вокруг неё: серверный код, который держит мир согласованным, авторитетным и скопированным на бэкапы. Сцена частных серверов говорит то же самое на масштабе хобби: OpenTibia держит аккаунты, персонажей, дома и их содержимое в отдельной SQL-базе — MySQL у хостинг-серверов, один файл SQLite для локального запуска.

Поэтому ответ на «почему некоторые игры используют базы данных» звучит так: их миры общие и одновременные в той степени, которую файлы рассудить не могут. Tibia выбрала базу не ради солидности. Мир, куда одновременно пишут две тысячи персонажей, — ровно та нагрузка, ради которой придумали транзакции.

Сколько каждый вариант стоит на самом деле#

Бесплатные тарифы управляемых сервисов щедрее своей репутации, причём в формах, которые важны. Тариф Firestore Spark без денег даёт 50 000 чтений, 20 000 записей и 20 000 удалений в день, 1 ГиБ хранилища и 10 ГиБ исходящего трафика в месяц. Когда дневная квота кончается, Firestore просто останавливает операции до сброса, а не выставляет счёт. Бесплатный план Supabase — это база PostgreSQL на 500 МБ, 50 000 активных в месяц для авторизации и неограниченные API-запросы. LootLocker, сделанный под игровые аккаунты и прогресс, даёт триал до 1 000 игроков, а некоммерческим играм — бесплатную лицензию. На стороне самостоятельного хостинга Nakama — открытый игровой сервер под Apache-2.0, хранилище в комплекте. Обычному PostgreSQL хватает VPS ценой в чашку кофе.

Настоящая граница проходит не по цене, а по форме платежа. Завсегдатай r/gamedev гонял PHP-бэкенд небольшой игры почти десять лет за €10–50 в месяц. Всю тему он сжал в правило, которое просится в рамку: не плати за вызов того, что можно батчить. Оплата за вызов — налог на болтливую архитектуру. Клиент, который сохраняется после каждой подобранной монеты, превращает бесплатный тариф в падение в полдень и счёт в полночь. Собирайте записи в пачки, ставьте в очередь, сбрасывайте по интервалу и при выходе — и тарифы, и VPS ужмутся до нужного размера. Одна ловушка, о которой лучше узнать заранее: Supabase ставит бесплатный проект на паузу после недели неактивности, так что игра с трафиком по выходным встречает субботнее утро холодным запуском.

Как решить за один вечер#

1. Разложите данные. Локальное у игрока: сохранения, настройки, разблокировки. Общее: очки, миры, матчмейкинг. Проведите линию на бумаге — большинство ощущений «нам нужен бэкенд» умирает прямо на ней.
2. Посчитайте, кто пишет. Один источник записи на данные, сейчас и всегда, — файлы или SQLite. Два и больше на одни и те же данные — сервер и база за ним.
3. Выпишите запросы. Пока каждый вопрос звучит как «дай вещи этого игрока», файлы справляются сами. Первый же вопрос, называющий двух игроков сразу — «кто впереди», «у кого это есть», — сигнал к переезду.
4. Выберите самое дешёвое, что выдержит эти ответы, и напишите кнопку экспорта раньше первой схемы базы. Данные, способные уйти одним файлом, переживут любую ошибку, которую вы вот-вот совершите; контроль версий и резервные копии распространяют тот же урок на весь проект.
5. Подключите метрики и дальше пусть спорят цифры. Аналитика — обычно первые по-настоящему общие данные, которые создаёт инди-игра. Гайд по аналитике инди-игр разбирает, что стоит собирать до решения, где этим данным жить.

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

Бэкенд под мультиплеер «когда-нибудь потом». Критерии выше либо срабатывают, либо нет. Одиночная игра с прицепленной базой тащит чужой продукт со всеми его способами сломаться — ради функции, которой у неё нет.

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

«Лидерборд», живущий в клиенте. Если клиент сам сообщает счёт и сам его хранит, это предложение, а не результат. Соревновательная механика либо признаёт авторитет сервера, либо остаётся украшением.

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

Нет выхода. Файлы это или Firestore, вопрос первого дня один: «как всё это оттуда вынимается». Экспорт — самая дешёвая страховка во всей статье и единственная, которая переживает закрытие вендора, смену тарифов и ваши собственные переделки.

Как вписывается Egmatic#

Egmatic — no-code-редактор 2D-игр, которому принадлежит этот блог, — строится вокруг простой ставки: проход решения выше не должен быть обрядом посвящения для каждого разработчика. Хранение игровых данных стоит на слое публикации, в одном ряду с публикацией и аналитикой, и подбирается по размеру игры. Пока дизайн одиночный, хватает файлов и синхронизации стора; когда стал общим, подключаются сервисы. И там и там это настройка, а не строительство с нуля. ИИ внутри редактора играет ту же роль, что и везде в Egmatic: усилитель ремесла под вашим руководством. Вы решаете, что значат данные вашей игры и какие записи общие, он набрасывает техническую обвязку, и каждый файл остаётся вашим. Про этап скажем прямо: Egmatic сейчас в pre-alpha, мы не называем дат, которые не сможем удержать. Лист ожидания на egmatic.com — место, где можно рассказать, что ваша игра хранила бы первым: именно запросы, пришедшие в pre-alpha, задают, что слой возьмёт в работу.

Итог#

Файлы — не компромисс. Для одного источника записи и одного процесса это правильный инструмент, а файловые серверы Minecraft доказывают это на любом масштабе, который вам встретится. SQLite выводит один процесс на настоящие запросы, не меняя способа развёртывания. Серверная база зарабатывается одновременным общим состоянием и вопросами сквозь игроков — и в этот момент обычного PostgreSQL достаточно, что люди, держащие одну из старейших MMORPG, доказали собственными замерами. Выбирайте по тому, кто пишет и кто спрашивает, держите экспорт подо всем, что строите, и батчите то, что иначе посчитают по вызовам. Это вся дисциплина, и она помещается на обороте конверта.

Источники#

• SQLite: About и Most Widely Deployed — документация SQLite
• player.dat format и Java Edition level format — вики Minecraft
• Inside Tibia: The Technical Infrastructure of an MMORPG — запись доклада, GDC Vault
• Tibia Turns Twenty — CipSoft, к двадцатилетию игры
• Tibia (video game) — Википедия
• Setting up your first server — документация Otland
• Firestore usage and limits — документация Firebase
• Pricing — тарифы Supabase
• Why do some games use databases? — тред на r/gamedev