Метрики и визуальный язык: как направлять игрока в локации
Почему важна повторяемость, агентивность игрока и интенциональность окружения.
Старший левелдизайнер в MachineGames Илиу-Космин Ониску опубликовал в своём блоге на платформе Medium текст о создании метрик, которые нужны для правильного построения уровня. Также он затронул вопрос создания единого визуального языка, который нужен для удобства игроков. Мы выбрали из текста главное.
По словам Ониску, есть три требования к тому, какими должны быть уровни: они должны направлять, давать испытания и способствовать погружению. В этом тексте он сосредоточился на первом аспекте — направлении.
Направляя игрока, разработчик показывает особенности среды и даёт информацию об испытаниях, которые таит в себе уровень. Руководствуясь этим принципом левелдизайнер и создаёт локации.
Первый шаг для создания понятного визуального языка — знакомство с играбельным персонажем. Левелдизайнер должен понять, как управлять протагонистом, какие ощущения возникают, когда он участвует в перестрелке или применяет умения. Нужно понять, что персонаж может, и чего не может.
Все основные способности персонажа связаны с набором игровых правил, которые нельзя нарушить. Но их можно деконструировать до набора метрик, на которые нужно ссылаться при создании уровня.
Персонажи в видеоиграх имеют стандартный размер — 1,8 метра в высоту, 1 метр в ширину и 1 метр в длину. Стандартная высота стены — 4 метра: примерно в два раза выше роста главного героя. Но эти пропорции могут меняться от игры к игре.
На основе этого можно создать ряд базовых метрик, которые будут использоваться в качестве эталонов при сборке уровней. Например: одноместное укрытие — это 1x1x1 метр, так как именно такого размера становится герой, когда пригибается.
Когда размеры базовых элементов окружения определены, можно начинать создавать набор других элементов, из которых будет составлен уровень. При этом желательно, чтобы их можно было измерить в базовых единицах, например, при помощи одноместного укрытия. Так, например, получится набор из стен, высота которых равна трём или четырём укрытиям, а ширина варьируется от одного метра до четырёх.
Смысл таких библиотек состоит в том, чтобы облегчить понимание пространства на стадии прототипа, когда на создание уровня ещё не ушло слишком много времени и сил.
Основная задача такой библиотеки — создать единый визуальный язык. По ходу прохождения игрок привыкает к формам и постепенно начинает легко их воспринимать и интерпретировать.
В этом примере используется сразу несколько стандартных элементов:
- маленькое укрытие;
- большое укрытие;
- длинное укрытие;
- блок, на который можно забраться;
- обычная стена;
- стена, на которую можно забраться.
Игрок легко распознаёт предназначение каждого элемента, потому что у них есть знакомая функция, которая становится доступной в соответствующем контексте.
Узнаваемость элементов возникает при помощи нескольких факторов:
- соотношение масштабов главного героя и окружения;
- повторяемость правил: все стены высотой в четыре метра, все маленькие укрытия — один метр, все высокие укрытия — два метра, все боксы, на которых можно подтянуться — три метра в высоту.
Когда игрок сталкивается с определённой задачей на уровне, именно такой визуальный язык позволяет ему быстро найти способы решения.
Люди способны распознавать паттерны в окружающей среде, благодаря чему игрок даже на незнакомой локации легко понимает свои возможности.
Также Ониску дал несколько советов по поводу метрик в разных играх.
При создании уровня важно помнить, что разработчик не должен полностью контролировать пользователя и ограничивать его лишь одним вариантом. У игрока всегда должен оставаться выбор, и задача левелдизайнера состоит в том, чтобы облегчить принятие решения.
Для этого разработчики могут специально привлекать внимание игроков. Например, поставить источник света, чтобы показать, куда идти дальше. Или же разместить заметный ориентир, который будет притягивать к себе пользователя.
Также уровни должны увеличивать агентивность игрока — давать ему возможность свободно строить собственные планы и подходить к решению задачи так, как он считает нужным. Однако усилия левелдизайнера должны быть сосредоточены на том, чтобы пользователь действительно заметил эти возможности и не был ошеломлён их количеством.
Игрок должен увидеть несколько решений для каждой проблемы и выбрать, какое подходит именно ему.
Высокая интенциональность окружения, построенного на понятных и повторяющихся правилах, всегда приводит к хорошим результатам. Причина этого заключается в том, что игроки стремятся постоянно придумывать решения проблем, а затем воплощать их в жизнь. Это способствует дополнительному погружению, потому что пользователи всегда стремятся улучшить свои стратегии и добиться ещё более впечатляющих результатов.
спасибо, я надеялся, что кто-то сделает
Подобные статьи у меня частенько вызывают замешательство своими выводами. Я понимаю что типовые пространства упрощают радикально производственные циклы, упрощают ориентирование игрока, и игроки и разрабы негласно принимают эти условности как и многие другие, но говорить что это работает на погружение... Это же ровно наоборот - когда ты на автомате считываешь бетонные блоки для прилипания во всяких гирзах это же разрушает приостановку неверия, ты знаешь что так объекты квадратно гнездовым методом в жизни не размещаются, а когда объект выполняющий роль укрытия слегка поворачивают чтобы избежать параллельности и перпендикулярности то персонаж ещё например может и не полностью к нему прислониться из-за специфики анимаций, что опять же раздражает глаз. В играх с абстрактным дизайном типа mirror's edge или f.e.a.r. (пример условный, в первой части бесконечные одинаковые офисы мне отдавали гротеском а не экономией производства) это смотрится вполне уместно, спору нет (хотя например в doom eternal его левел дизайн максимально абстрактный этот подход все равно раздражает, когда все считывается как конструктор, без особых попыток даже имитировать живые объекты). Но когда в игре сначала расставляют сортиры для реализьму, а потом глаз бьётся об типовые пропорции сложно назвать это погружением (хоть в поток, хоть в сеттинг).
Это вечное правило насчёт большого объекта направляющего игрока - но ведь постоянно же бывает что ты видишь объект и хочешь пройти к нему напрямую, но напрямую пути нет и приходится искать боковые какие-то проходы и объект тебя только сбивает с толку, особенно когда препятствие к нему максимально абстрактное (например типичная куча строительного мусора которую преодолел бы и ребенок, но не наш герой привыкший двигаться исключительно по типовым пространствам). Набившие оскомину зелёные лампочки комфортнее)
В недавней статье про левел дизайн древних свитков сначала рассказывается про глубокую проработку истории местности и кучу методов итерирования, оптимизации и полишинга левелов, а потом видишь безжизненные в большинстве своем пространства, дома без пресловутых сортиров и т.п.
У меня порой такое ощущение что левел-дизы (и не только они) пытаются приостановить неверие у самих себя и не просто выдают желаемое за действительное (плохой дизайн за хороший) а начинают уверять себя что условности с которыми приходится смириться и игрокам и разрабам (к слову эта самая условность левел дизайна легко прощается если играется уровень весело), не всего навсего простительны и привычны, а аж начинают работать на погружение.
Этот коллективный самообман может навредить имхо новичкам, лучше бы просто рассказывали про типовые задачи и как конкретно итерируются уровни чем про вот это вот погружение
Суть в том, что от условностей в играх не избавиться. Просто потому что игра - это упрощенная модель некоторого аспекта жизни. А раз с условностями приходится мириться, то люди и выдумывают способы, как обыграть эти условности поинтереснее и сделать их менее очевидными. При этом сохранив их функцию. Как запретить игроку идти туда, куда не задумано? Сначала там просто ставили невидимые стены и не парились. Потом кто-то написал статью о том что это портит погружение в игру. Начали наваливать кучи строительного мусора. Уже лучше по моему. Кто-то еще напишет статью что мусор должен выглядеть непреодолимым препятствием и все - одной вашей претензией станет меньше :)
А если бы вместо этого все просто писали "про типовые задачи и как итерируются уровни"... ну даже не знаю. Это как спрашивать шеф повара о чистке картохи и распорядке дня на кухне потому, что эта ваша фуагра - простой паштет и нечего тут выпендриваться. Типовые задачи потому и типовые, что это рутина. Итерации - последовательность действий, которая от проекта к проекту отличается и которая опять же - рутина. Зачем вам знать в каком порядке на определенном проекте принимают работу (итерируют уровни)? На другом проекте той же фирмы 100% будет иначе. В этой же статье человек поделился тем, что посчитал новым и интересным. На каждом уровне знания это "новое" свое. Сначала конечно и картоху чистить в новинку.
Я наверное твой комментарий искала годами. Теперь буду копипастить это везде.
Плюсую. Особенно за последние слова.
На меня все эти одноразмерные ящики, заборы, лестницы и тд нагоняют только уныние. Если таким образом делать все уровни, то я в такое играть не буду.