Правило сорока секунд

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

Этот показатель сильно зависит от скорости игрока и размера карты — количество энкаунтеров в открытом мире будет больше или меньше в зависимости от этих факторов.

• Если карта небольшая, а игрок очень быстрый, то количество энкаунтеров будет меньше.

• По мере увеличения скорости игрока и размеров карты, количество энкаунтеров должно увеличиваться.

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

Наслоение энкаунтеров 

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

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

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

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

Конечно, можно заниматься микроменеджментом энкаунтеров, но работа с четвертью сотни энкаунтеров в одной локации размером, скажем, 500x500 метров может оказаться не такой уж и легкой задачей с точки зрения того, сколько времени у вас будет ежедневно для настройки каждого отдельного энкаунтера.

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

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

Эмпирические наблюдения

Энкаунтеры должны быть реиграбельными

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

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

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

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

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

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

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

Плейтестинг

Вам (а также вашим начальникам и лидам) предстоит решить, каким должен быть опыт игровой опыт, к которому вы стремитесь, однако… пожалуйста, примите во внимание тот факт, что ваше “собственное” мнение является лишь одним из многих, и, возможно, лучше всего будет основывать это решение на результатах плейтестинга, где каждый сможет сесть, поиграть в игру и высказать свое мнение о том, как идут дела и как ощущается текущее состояние игры.

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

• Вы не участвуете в плейтесте

• Обычно вы наблюдаете за тем, как другие играют в игру

• Вам следует делать записи

• Вы никоим образом не вмешиваетесь в процесс

• Будьте готовы воспринимать письменные результаты с долей скептицизма

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

Системные взаимодействия

Почему чем меньше, тем лучше

Вам нужно как следует подумать о системном долге и сложности вашего проекта, прежде чем начинать раскрывать этот аспект в своей игре.

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

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

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

• Это имеет смысл только в том случае, если игроки могут ее видеть.

• Нельзя сбивать игрока с толку (игрок должен понимать, что происходит)

Размер карты

Размер карты — тема нетривиальная

Технически вы должны использовать большой размер карты только в том случае, если у вас есть необходимые технологии для его поддержки. Это означает, что движки могут обрабатывать стриминг регионов, LOD’ы, стриминг объектов и т.д.

Также очень важно, чтобы стриминг мог выполняться относительно позиции игрока.

Игры Assassins Creed, Watch Dogs, FarCry позволяют объектам мира появляться и исчезать в зависимости от того, насколько далеко или близко они находятся по отношению к игроку. Обычно это реализовано с помощью серии концентрических кругов разного диаметра (30, 45, 60 м) с центром на игроке - все на карте появляется и исчезает в зависимости от того, насколько далеко или близко они находятся.

Также очень помогает использование окклюдеров, хотя это, как правило, слегка ограничивает творческий потенциал.

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

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

Также не мешает использовать разные технические приемы для повышения производительности.

Компиляция и управление данными

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

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

Если вы можете установить перекрестную зависимость между электронной таблицей и данными в движке, это может способствовать более быстрому обновлению информации в реальном времени в вашей электронной таблице, что очень удобно.

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

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

Диапазон внимания игрока

В игре с открытым миром игрок имеет тенденцию вести игру двумя разными способами:

Направленный

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

Это сужает диапазон внимания игрока.

Ненаправленный

• Ненаправленный. Игрок не получает цели, однако неотъемлемые условия того, где и как происходит спавн, диктуют, что он должен делать.

Это, как правило, требует более широкого диапазона внимания игрока, поскольку оно требуется для выявления наилучших методов использования систем/инструментов.

Примечание

• В конце концов, все переживания стимулируются нами, ничто не оставлено на волю случая, однако, расширяя диапазон внимания игрока, он начинает осознавать сложность окружающих его систем.

• Если игрок может сложить 1+1, чтобы сопоставить одну систему с другой для получения эффекта, тогда можно считать, что семена системного взаимодействия посеяны в мозгу игрока, и вам нужно создать системную прогрессию, которая со временем естественным образом раскрывает системы перед игроком.

Разнообразие и как сделать его незаезженным

Я много говорил об этом в своей статье по Automata. Очень важно, чтобы вещи были простыми и незаезженными.

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

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

Игроку необходимо испытать две вещи:

• Системы, взаимодействующие с другими системами.

• Системы игрока, взаимодействующие с игровыми системами.

Если провести аналогию, то это похоже на то, как вы учите другого человека что-то делать, делая это самостоятельно:

• Дети обычно учатся, наблюдая за своими родителями, затем делая это сами, терпя неудачу и пытаясь снова.

Таким образом, мы могли бы разбить это на несколько этапов:

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

• Тест — Пользователь пытается повлиять на эти системы, используя доступные ему инструменты, в результате чего нужный эффект происходит или не происходит.

• Повторение — пользователь повторяет попытки до тех пор, пока не будет получен удовлетворительный результат.

Если вы представили Марио, пытающегося перепрыгнуть через яму и умирающем снова и снова, вы не ошиблись. Это точно то же самое, но на гораздо большем и более широком уровне.

Системные взаимодействия

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

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

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

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

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

Чтобы сгенерировать эти пресеты, необходимо учитывать:

• Сеттинг игры

• Доступные системы

• Какие истории вы можете рассказать, используя их?

Примеры могут быть разными:

• Мулы, атакующие игроков ради их лута, когда их засекают датчики - Death Stranding

• Бандиты подстерегают в кустах, пока Эйвор путешествует по Шервудскому лесу — Ac Valhalla

• Полицейские арестовывают мирных жителей в Лондоне — Watch Dogs legion

• Дроны осматривают пляж рядом с телекоммуникационным постом — Watch Dogs breach point

• Орлы атакуют сектантов — Far Cry 5

В качестве практического способа визуализации этих вещей подумайте об этих системах как о статических или стационарных:

• Стационарная система всегда будет там — если игрок или искусственный интеллект взаимодействуют с ней, это произведет эффект — пинг датчика груза / территории BT в Death Stranding

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

Заключение

Мне бы хотелось, чтобы эта статья была более полезной с точки зрения фактических руководств “как это сделать”, но реальность такова, что все зависит от множества факторов, и если эти факторы четко не определены, то процесс проектирования заходит в тупик.

Конечно, вы можете попробовать его отложить, но это может привести к провалу, когда станут доступны ответы на ваши вопросы.

Вот краткий обзор:

• Знайте свои системы

• Знайте, как они взаимодействуют друг с другом

• Создавайте системные тропы на основе этих взаимодействий и темы игры, которую вы делаете

• Оценивайте технические ограничения вашей игры

• Организуйте эти тропы в удобной электронной таблице.

• Внедряйте

• Реализуйте плейтестинг

• Итерируйте

Вот и все. Удачи вам во всех начинаниях!

Что нас так привлекает в играх? Что заставляет погружаться в них с головой, забывая про «здесь и сейчас»? Конечно, это яркие эмоции и впечатления. Напряжение, удивление, страх, восторг, ярость и многое другое — то, что разработчики хотят подарить геймерам.

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