Куда исчезает время и нервы во время экрана загрузки «Сохранение…»

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

Создается иллюзия, будто игра просто сбрасывает готовый файл на накопитель. Однако за доли секунды происходит целый комплекс процессов: игровой движок переводит текущее состояние виртуального мира в последовательность байтов, операционная система определяет место записи, SSD-контроллер выбирает свободные физические ячейки, а центральный процессор выполняет миллионы вычислений. Чтобы осознать сложность этого механизма, полезно проследить его эволюцию — от простейших зачатков до современного конвейера, трансформирующего объекты в оперативной памяти в электрический заряд.

Как вы внедряете ИИ?

Поделитесь своим опытом за 7–10 минут. Разыгрываем 5 сертификатов по 1 500 ₽ на маркетплейсе и 10 наборов мерча.

Ответить на вопросы →

Краткая история развития сохранения в играх

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

Здесь кроется важный технический нюанс, о котором часто забывают. Электроника оригинального автомата Space Invaders функционировала на процессоре Intel 8080, оснащенном парой килобайтов статической памяти без резервного питания. Стоило выключить автомат, как таблица рекордов сбрасывалась до стандартных 3 000 очков. Из-за этого владельцы залов оставляли аппараты включенными круглосуточно — рекорд держался ровно до прерывания подачи энергии.

На уровне ассемблера архитектуры 8080 логика была примитивной: под текущий и лучший результаты выделялись фиксированные ячейки памяти (значения кодировались в двоично-десятичном формате для удобства вывода на дисплей), а после гибели аватара специальная подпрограмма сопоставляла показатели и при необходимости перезаписывала рекорд.

В начале 1980-х годов индустрия перешла на энергонезависимые решения — ту же SRAM, но дополненную миниатюрной литиевой батарейкой, поддерживающей напряжение на чипе при отключенном питании. Позже появились комплексные модули вроде Dallas Semiconductor DS1225Y, объединяющие батарею и память в едином корпусе. В них хранили не только рекорды, но и конфигурации аппарата, счетчики монет и прочие служебные данные. Ближе к концу десятилетия часть информации постепенно мигрировала в EEPROM, которой элементы питания вообще не требовались.

Появление сохранений подарило играм фундаментально новое измерение — время. Поскольку прогресс стало возможно зафиксировать, появился смысл проектировать сюжеты, чье прохождение выходит за рамки одного сеанса. Проекты вроде The Legend of Zelda и Zork первыми сделали систему сохранений ключевым элементом геймдизайна. Домашние ПК некоторое время обходились текстовыми паролями — комбинациями символов, которые геймеры записывали на бумагу, но вскоре массово перешли на магнитные кассеты и дискеты. Консольные картриджи обзавелись собственной RAM с батарейным питанием, превратив сохранение в осязаемый физический объект: игроки могли носить картриджи друг к другу, чтобы продолжить прохождение.

В 1990-х годах масштабы и продолжительность проектов резко возросли: средняя игра теперь требовала для прохождения больше семи часов, шутер Duke Nukem 3D — около девяти, а ролевая игра Final Fantasy VII — порядка 60.

Сформировались три основных подхода к сохранению:

1. через меню паузы,

2. автоматически после завершения событий или заданий,

3. через специализированные контрольные точки, которые еще нужно было отыскать. Последний метод оказал наибольшее влияние на игродобычу. Частота расположения чекпоинтов, сложность их обнаружения и связанный с ними менеджмент ресурсов (боеприпасов, здоровья) превратились в самостоятельный инструмент настройки сложности.

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

Серия Pokemon пошла дальше, превратив обмен данными через кабель Game Boy Link Cable в базовую игровую механики: коллекционные монстры и статистика путешествовали между картриджами напрямую, минуя накопители.

С распространением встроенных жестких дисков в Xbox 360, PlayStation 3 и Wii ограничения по объему исчезли окончательно — по расчетам, накопитель PS3 на 60 гигабайт мог вместить около 200 тысяч файлов с сохранениями. Полученный запас пространства позволил разработчикам избавить пользователей от рутины контроля за процессом: так родились фоновые автосохранения, постепенно вытеснившие ручные точки во многих жанрах.

Игровой мир не хранится как единое целое

Стоит сразу отбросить миф о «сохранении всей игры целиком». Единой монолитной структуры виртуального пространства в памяти не существует — вместо этого активны тысячи автономных сущностей. Например:

Player
Enemy #42
Enemy #43
Chest #11
Tree #205
Weather
Quest Manager
NPC Database
Physics
Inventory

Каждый элемент обладает собственным жизненным циклом и набором параметров. В качестве иллюстрации возьмем класс игрока:

class Player
{
   Vector3 position;
   int health;
   int stamina;
   int money;

   Inventory inventory;

   QuestLog quests;
};

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

Современный крупнобюджетный проект задействует от 8 до 20 ГБ оперативной памяти, тогда как вес сохранения редко превышает несколько мегабайт. Причина кроется в том, что львиная доля данных в ОЗУ — это неизменяемые ресурсы, уже присутствующие на диске (аудиодорожки, трехмерные модели, текстуры, шейдеры и геометрия уровней). Дублировать их бессмысленно. Сохранению подлежат лишь те параметры, которые отклонились от первоначального состояния мира.

Условно говоря, игра фиксирует не сам «меч» со всеми его текстурами и анимациями, а короткую запись вроде «у персонажа в руках предмет под номером 271». Фактически это вычисление разницы (diff) между дефолтным состоянием локации и актуальным, а не полный дамп памяти.

Игровой сервер с криперами и порталом в Незер.

Добывайте ресурсы, стройте объекты, исследуйте мир Selectel в Minecraft и получайте призы.

Исследовать →

Сериализация

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

Player {
   Health = 95
   Money = 850
}

На уровне носителя они преобразуются в машинный код:

5F 00 00 00   ; Health = 95  (little-endian, int32)
52 03 00 00   ; Money = 850

Понятия объектов, классов и указателей здесь отсутствуют — остаются лишь упорядоченные числовые значения. Попытка открыть такой документ в обычном текстовом редакторе выведет нечитаемую абракадабру вроде ÏØaƲ╣È, поскольку перед нами бинарный поток. Для анализа структуры применяются специализированные шестнадцатеричные редакторы (вроде HxD или 010 Editor), где отчетливо просматриваются служебные сигнатуры, заголовки и блоки фиксированной длины:

53 41 56 45   ; "SAVE" — сигнатура формата
01 00 00 00   ; версия формата = 1
E8 03 00 00   ; смещение до блока Player
...

Большинство движков предваряют полезную нагрузку небольшим заголовком: уникальной сигнатурой (для проверки подлинности формата), номером ревизии (актуальным при адаптации старых сейвов под новые патчи) и контрольной суммой (например, CRC32 или SHA-1 от содержимого). Последняя используется для верификации целостности файла еще до того, как движок попытается его обработать.

Почему игры почти никогда не перезаписывают файл сохранения напрямую

На завершающем этапе пакет данных поступает в распоряжение накопителя. Операционная система не указывает конкретные физические сектора — она передает SSD команду в духе: «вот массив на 64 КБ, размести его где-нибудь». Дальнейшим управлением занимается контроллер и слой трансляции адресов (FTL): он самостоятельно распределяет нагрузку по физическим блокам, учитывая износ ячеек флеш-памяти (ограниченных по числу циклов перезаписи) и выполняя фоновую сборку мусора. Логические адреса файлов и физическое расположение зарядов никак не связаны напрямую для ОС — эту карту знает исключительно внутреннее ПО накопителя.

На микроуровне запись представляет собой модификацию концентрации электронов в ячейках с плавающим затвором или их современных 3D NAND-эквивалентах. Иными словами, уменьшение шкалы здоровья персонажа со 100 до 95 единиц физически выражается в перераспределении электрического заряда внутри кремниевой структуры.

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

Как это выглядит в конкретных играх

Skyrim

Известная особенность движка Creation Engine заключается в раздувании сейвов до сотен мегабайт за длительное прохождение при неизменном размере игрового мира визуално. Виной тому скриптовая среда Papyrus: каждый активный скрипт, привязанный к персонажу или заданию, перманентно хранит свое состояние внутри файла сохранения.

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

Minecraft

Здесь пространство дробится не на абстрактные объекты, а на сетку чанков размером 16×16×384 блоков, которые объединяются в региональные файлы формата .mca сетками по 32×32 штуки. Каждый чанк сериализуется в NBT-формат (Named Binary Tag — фирменный бинарный стандарт Mojang, идейно близкий к JSON, но оптимизированный по размеру) и сжимается алгоритмом zlib изолированно от соседей. Благодаря этому движок перезаписывает лишь те сегменты карты, в которых действительно произошли изменения, не затрагивая остальной массив region-файла — схожий принцип работы с дельтами, но примененный к ландшафту, а не к персонажам.

Dark Souls

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

Рогалики (Hades, Slay the Spire, FTL)

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

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

Технически смерть в рогалике — это не загрузка предыдущего сохранения, а сброс локальных переменных к дефолтным значениям на фоне сохранения глобального прогресса аккаунта. Подобная концепция полностью исключает явление save-scumming: перезаписывать просто нечего, поскольку прошлые состояния забега не дублируются ни в постоянной памяти, ни в темп-файлах.

Процедурная генерация

Проекты с процедурно формируемыми мирами вроде Minecraft, No Man’s Sky или Terraria решают специфическую задачу: им требуется хранить не готовое пространство, а алгоритм его воссоздания. Фундаментом выступает цифровой сид (seed), на основе которого генератор детерминированно выстраивает рельеф, биомы и распределение ископаемых. Если бы виртуальная среда вычислялась с нуля при каждом запуске, игра не занимала бы места на диске вовсе, но пользователи оставляют следы своего присутствия: разрушенные блоки, возведенные постройки, перемещенные предметы.

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

No Man’s Sky развивает эту идею дальше. Галактика, насчитывающая триллионы планет, физически не поместится ни на один носитель, поэтому персистентными делают только те точки, где игрок оставил материальный след — построил базу или деформировал поверхность. Всё остальное пространство при повторном визите воссоздается из изначального сида и визуально неотличимо от «сохраненного».

Save state в эмуляторах

Отдельную категорию представляют состояния сохранения (save state), востребованные у эмуляторов и спидраннеров. Они кардинально отличаются от штатных игровых механизмов, хотя внешне выполняют ту же функцию.

Обычный сейв — это выборочный срез данных, который игра запрограммировала записать (координаты, инвентарь, квестовые флаги). Функция save state устроена грубее и универсальнее: эмулятор выполняет полный дамп оперативной памяти эмулируемой платформы, регистров процессора, видеопамяти и аудиоконтроллера. Иными словами, фиксируется абсолютно всё, что позволяет спустя миллисекунду продолжить выполнение инструкций ровно с того же такта процессора. Сама игра при этом не подозревает о факте «сохранения». С точки зрения программного кода время просто замерло на момент создания файла.

Подобный подход позволяет создавать сейвы в играх, изначально не поддерживающих такую возможность (в классических аркадных релизах или старых проектах для NES без батареек на картридже). Обратной стороной медали выступает жесткая привязка не только к конкретной игре, но и к версии эмулятора. Обновление эмулятора способно изменить распределение памяти, из-за чего старый дамп станет нечитаемым. Именно поэтому спидраннеры и создатели TAS-роликов строжайшим образом фиксируют сборку эмулятора для каждого прохождения.

Облачные сохранения и проблема двух «сохранений»

С появлением сетевых сервисов (Steam Cloud, Xbox Live, PS Plus, мобильных синхронизаций) возникла специфическая коллизия, незнакомая владельцам картриджей: один и тот же прогресс теперь дублируется на двух физически удаленных носителях, чьи данные могут разойтись.

Базовый алгоритм синхронизации устроен схожим образом на всех платформах. При выходе из приложения или в фоновом режиме клиент сопоставляет локальную копию с серверной (ориентируясь по временным меткам или хешам). Если версия в облаке оказывается свежее, она замещает локальную, и наоборот. Проблемы начинаются, когда обе копии подверглись изменениям независимо друг от друга. Типичный сценарий: игрок запускал проект на ноутбуке без подключения к сети, а затем открыл его на консоли, которая успела подтянуть устаревший облачный файл.

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

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

Заключение

В момент, когда надпись «Saving…» гаснет на дисплее, завершается масштабный производственный цикл: движок агрегирует данные по сотням объектов, сериализатор упаковывает их в бинарный поток, ОС безопасно подменяет старый файл новым, а контроллер SSD распределяет заряды по кристаллам памяти. Каждое звено этой сложной цепи спроектировано с расчетом на внезапное отключение питания — именно поэтому надпись «Файл поврежден» появляется на экранах гораздо реже, чем могла бы.

 

Источник