Введение


Несмотря на то, что функция сохранения (save) и загрузки (load) игрового состояния (game state) относится скорее к системному функционалу, в определённых случаях их можно рассматривать и в разрезе игрового дизайна, как влияющие на механику игрового процесса.

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

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

Сохранение и загрузка как фактор сложности


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

Первой попыткой форсировать отказ от F5/F9 (прим. авт.: часто используемое сокращение для быстрой записи и быстрого восстановления игрового состояния) на моей памяти была Diablo II (Blizzard, 2000, PC/MAC), но там использовалось автоматическое сохранение состояния каждые 5 минут, то есть контрольные точки были расставлены по времени. Cохранение в меню оставили только в виде «Сохранить и выйти».

Контрольные точки, расставленные по уровням реализованы, например в таких играх как BioShock(2K Boston/2K Australia, 2007, PC/XBOX/PS3), F.E.A.R. (Monolith Prod./Sierra Ent., 2005, PC/XBOX/PS3) и Far Cry (Crytek/Ubisoft, 2004, PC). При достижении определённого участка уровня происходит автоматическое сохранение. Такого рода управление игровыми состояниями увеличивают сложность ещё и за счёт того, что непосредственно перед принудительным сохранением можно совершить ошибочные действия (потратить все патроны или здоровье), которые возможно будет исправить только за счёт прохождения следующего участка уровня. Это нужно помнить игровому дизайнеру, чтобы такой способ сохранения не привёл к необходимости начать игру заново.

В игре Trine (Frozenbyte, 2009, PC/MAC/Linux/PSN) реализован механизм восстановления с контрольных точек, в случае смерти главных героев. Любой оставшийся в живых герой воскрешает остальных. В таком случае применяется специальный штраф — минимальный уровень здоровья воскрешённых персонажей. Контрольные точки являются магическими объектами, и в целом вселенная игры наполнена магией, так что неудивительно, что персонажи могут воскресать.

Сохранение и загрузка как фактор эффективности


Количество сохранений и загрузок (скорее первого, чем последнего) иногда учитывается при оценке эффективности прохождения игры, при подсчёте очков рекорда (top score). Каждое сохранение является штрафом при подсчёте и, в результате, уменьшает количество очков. Загрузка игры влияет в меньшей степени или не влияет совсем. Такой подход применён в «Космических рейнджерах»(Elemental Games/1C, 2002, PC) для таблицы рекордов.

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

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

Многопользовательские игровые сессии


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

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

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

Ограничение использования сохранения и восстановления


В некоторых случаях возможно имеет смысл ограничивать сохранение и восстановление по времени (не чаще чем в N минут), количеству (не более 3-х раз за уровень) или участкам уровней (например, сохраняться только вне боя). Однако такие ограничения, впрочем, как и любые другие должны быть семь раз отмерены, прежде чем отрезать.

Контрольные точки могут быть также ограничены в использовании и сохранять/восстанавливать только в пределах игровой сессии. При выходе из игры уровень придётся проходить заново.

Это интересно


В старой доброй System Shock 2(Irrational Games/Looking Glass Studios/EA, 1999, PC) применялся способ записи и восстановления непосредственно интегрированный в игровой процесс, и я бы даже сказал, в игровую атмосферу и вселенную. На уровнях стояли контрольные точки в виде специальных кабин ДНК репликации (DNA replication chambers), которые воскрешали героя в случае смерти. Хотя в целом система управления игровыми состояниями там была, мягко говоря, странной.

В инди—игре Braid(Jonathan Blow/Microsoft Game Studios/Number None, 2008, XBLA/PS3/MAC/PC/Linux) система восстановления состояния была решена наиболее оригинально (на мой взгляд) на нынешний день — там просто происходил реверс времени и игрок сам мог выбирать ту точку отсчёта, с которой он мог продолжить. Правда, это не было особенностью системы управления игровыми состояниями, а скорее побочным эффектом игровой механики. Однако с успехом выполняло роль F5/F9.

В Jagged Alliance 2(SirTech Software, 1999, PC) режим невозможности сохранения во время боя даже вынесен в отдельный уровень сложности «Железная воля». Подобные приёмы позволяют увеличить «спортивный» интерес, но несут в себе другую опасность — прохождение особо трудных мест с большим количеством попыток способно отбить у игрока желание играть дальше. Как правило, включение таких режимов сохраняется вместе с игровым состоянием и отключить его можно будет только начав игру заново.


Об авторе:
Играми как игрок интересуюсь с 1993 года, как разработчик — с 2002. Разрабатываю в качестве игрового дизайнера (общий игровой дизайн, UX-дизайн, дизайн уровней, консультирование).
В последнее время работал над следующими проектами:
  • (iOS) Finger Physics (2009), физический пазл, как игровой дизайнер;
  • (iOS) Finger Physics: Thumbwars (2010), физический пазл, как игровой дизайнер;
  • (iOS) Viking Tales (2011), аркада-приключение, как игровой дизайнер;
  • (iOS) Cut the Rope (2011), аркадный пазл, как левел-дизайнер и бета-тестер;

В данный момент работаю игровым дизайнером в одном из рекламных агентств, делаю игры и пишу ТЗ для приложений для iPhone/Android. Помимо игрового дизайна интересуюсь проектированием пользовательского взаимодействия, в свободное время рисую прототипы приложений, которые хотелось бы видеть.

О публикации:
Статья претендует на роль справочного материала и задумывалась когда-то как часть некоего цикла под общим условным названием “Игровая механика. Справочник игрового дизайнера”. Здесь намеренно пропущены части, касающиеся пользовательского взаимодействия, а также техническая часть, посвящённая тому, что и как сохранять. Для этого предполагается отдельная часть.