50 принципов, важных для создания хорошей игровой камеры

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

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

Джон Нески, один из ведущих разработчиков Journey, выделил 50 основных принципов для создания хорошей камеры от третьего лица. Этот массивный список — ниже по тексту.

Джон Нески

Работал в Thatgamecompany в качестве «инженера чувств». Он, в частности, отвечал за поведение камеры в Journey и работал над Sky: Children of Light от той же студии. Сегодня Нески работает инженером ПО в Google.

Камеры — это сложно

Главная проблема нефиксированных игровых камер — отсутствие контроля со стороны дизайнера. Игрок сам выполняет роль оператора и решает, куда направить игровой объектив. Поэтому заранее выстроить идеальный кадр с учётом основных правил хорошей съёмки не получится. В результате разработчикам приходится придумывать алгоритмы, которые подстраиваются под действия игрока.

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

Нески считает, что все камеры в играх можно поделить на три категории:

• фиксированная камера от третьего лица,
• динамическая камера от третьего лица,
• камера от первого лица.

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

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

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

Фундаментальные ошибки

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

Скажем, компания Nintendo во многих своих играх, наоборот, отходила от динамической камеры к фиксированной. Например, в Super Mario 64 — свободная камера, что было новаторским и уникальным решением для своего времени, но это вовсе не привело к тому, что компания полностью отказалась от двухмерных игр. Она и по сей день выпускает платформеры с фиксированной камерой, которые играются столь же интересно, как и игры от третьего лица.

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

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

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

С самого начала разработки нужно учесть технические нюансы. Например, для определения положения камеры Нески рекомендует отказаться от использования глобальных координат⁽³⁾. Они позволяют указать на точку в пространстве относительно её начала по трём основным ординатам — X, Y и Z. Это может быть удобно в некоторых ситуациях, но совершенно бесполезно для камеры, ведь она, как правило, привязана к аватару. В результате в движке будет два объекта (аватар и камера) с очень похожими, но разными глобальными координатами. Куда проще вместо этого привязать камеру к персонажу и управлять её положением при помощи других показателей — например, дистанции от аватара.

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

Удивительно, но иногда из-за таких ошибок страдают не только дизайнеры, но и игроки. Например, в недавних частях Call of Duty для индикации отдачи оружия (раздел Recoil Control на изображении выше) используются именно кватернионы. Глядя на эти метрики, игрок вряд ли поймёт, насколько точно пушка стреляет. В худшем же случае он и вовсе спутает их с более привычными градусами и получит неправильное представление об отдаче.

Препятствия и камера

Настраивать расстояние между аватаром и камерой нужно с умом⁽⁴⁾. Если выбрать слишком большое значение, появится риск, что герой будет периодически перекрываться внешними препятствиями. Чем больше дистанция между объектами, тем выше шанс, что между ними что-то будет. Поэтому лучше ставить камеру поближе — особенно если в игре много вертикальных препятствий.

Впрочем, это не искоренит проблему полностью. Почти во всех играх есть высокие объёмные стены, которые перекроют камере вид на персонажа⁽⁵⁾. Чтобы этого не происходило, камера должна чувствовать преграды и аккуратно отталкиваться от них. С этим помогут рейкасты, которые покадрово анализируют пространство вокруг камеры. Если луч заметил преграду, камеру можно ненавязчиво оттолкнуть в противоположную от этой преграды сторону.

Впрочем, у этого правила есть исключение. Если препятствие не очень объёмное, то камере необязательно на него реагировать⁽⁶⁾, ведь игрок и так не потеряет персонажа из виду. Такие безопасные препятствия можно заранее пометить в движке, чтобы алгоритмы их игнорировали. Однако важно не переусердствовать: если закодить тонкие препятствия так, чтобы камера совсем их не замечала, то она может оказываться внутри такой безопасной геометрии⁽⁷⁾. Избежать этого поможет дополнительная сфера коллизии у камеры.

Когда алгоритм влияет на положение камеры, возникает риск конфликта между желанием игрока и кода игры⁽⁸⁾. В подобных случаях нужно всегда ставить на первое место пользователя. Если игрок настойчиво поворачивается в сторону препятствия, нужно дать ему эту возможность. Алгоритм, тем временем, должен переключиться на новую задачу — не дать камере застрять внутри препятствия⁽⁹⁾. Как правило, для этого достаточно сдвинуть её ближе к аватару.

Когда подобных алгоритмов в игре накопится достаточно, они могут начать бороться не только с игроком, но и друг с другом. Если не учитывать этого, то в определённый момент камера начнёт вести себя хаотично⁽¹⁰⁾. Например, если один алгоритм толкает её в одну сторону, а другой — в противоположную, то камера, вероятно, просто останется на месте. Чтобы избежать этого, стоит выстроить иерархию, где наиболее важные принципы учитываются в первую очередь. Другими же придётся пренебречь.

Важно учитывать характер препятствий при написании алгоритмов для камеры. На уровне могут встречаться не только колонны, но и всяческие возвышенности — холмы и лестницы. Не стоит облетать их горизонтально⁽¹¹⁾ — лучше приподнять камеру. То же самое касается ситуаций, когда преграда появляется позади персонажа⁽¹²⁾. Если камера в таких ситуациях будет уходить в сторону, это дезориентирует. Вместо этого лучше приблизить её.

Впрочем, располагать камеру слишком близко к аватару тоже не нужно, ведь персонаж перекроет собой всё окружение⁽¹³⁾. У камеры должен быть отдельный триггер-бокс для определения близости к аватару. В отдельных случаях героя можно сделать полупрозрачным.

Правильная композиция

Расстояние между камерой и аватаром не должно быть одинаковым для всех углов просмотра⁽¹⁴⁾. В каких-то ситуациях это напрашивается само собой — при взгляде снизу вверх камера упирается в землю, поэтому неизбежно будет ближе к игроку. Если же камера смотрит на персонажа с высоты, Нески рекомендует, наоборот, отдалить её. В ином случае игрок увидит лишь своего аватара и пол — это создаст неприятное чувство клаустрофобии.

При взгляде снизу вверх можно не только приблизить камеру, но и увеличить FOV, то есть угол обзора⁽¹⁵⁾. Этот трюк позволит сымитировать периферийное зрение персонажа. Когда человек смотрит на небо, то видит сразу десятки километров пространства. Привычный угол обзора в 90 градусов плохо передаёт это чувство.

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

Иногда аватар может потеряться из виду, если пройдёт через непрозрачное, но нетвёрдое препятствие. Это может быть водопад или штора. В таких случаях приходится прибегать к не самому элегантному решению — прямой склейке⁽¹⁷⁾. Здесь возникает риск наделать неприятных ошибок. Так, новый кадр не должен сильно смещать ось движения героя⁽¹⁸⁾, ведь тогда аватар начнёт неожиданно идти не туда, куда планировал игрок. Если же новый ракурс необходим, то на стыке между склейками стоит добавить кат-сцену. Либо же удостовериться, что переход происходит в безопасной для игрока ситуации.

Ещё одна неочевидная проблема прямых склеек — нарушение чувства направления игрока⁽¹⁹⁾. Джон Нески отмечает, что люди, как правило, ориентируются при помощи заметных статичных объектов и навигационного счисления. Так называют технику, когда мы рассчитываем положение относительно самих себя. Например, если человек шёл в одну сторону, а затем повернулся на 180 градусов, то он продолжит идти ровно в противоположном направлении. Учитывайте эти особенности пространственного мышления при создании склеек. Если в новом кадре пропадёт ориентир, который был заметен ранее, игрок может заплутать.

Также важно не забывать о знаменитом правиле 180 градусов⁽²⁰⁾, согласно которому во время диалогов камера не должна пересекать линию, которую образуют собеседники. Конечно, это актуально в первую очередь для кат-сцен, а не свободной динамической камеры. Однако при переходе от заставки к геймплею стоит держать в голове этот принцип.

Помните о важных объектах окружения⁽²¹⁾. Не фокусируйтесь только на аватаре: игрок должен видеть, куда идти, какие преграды ждут впереди, и обращать внимание на окружение. Камера должна фокусироваться в том числе и на этих важных элементах. Если же что-то важное находится прямо перед аватаром, приподнимите камеру, чтобы игрок это увидел⁽²²⁾.

В замкнутых помещениях бывает сложно управлять как камерой, так и аватаром⁽²³⁾. Например, в доме может быть много витиеватых коридоров, вынуждающих постоянно поворачивать камеру на 90 градусов. В таких ситуациях желательно корректировать ракурс, чтобы камера смещалась к спине персонажа.

Как правило, когда персонаж бежит вперёд, камера выравнивается для показа препятствий вдали. Это хорошая техника, но иногда её стоит избегать⁽²⁴⁾. Например, когда аватар устремляется к стене-тупику, камеру можно слегка отклонить в сторону, чтобы элегантно указать игроку, куда двигаться дальше. То же самое касается обрывов: не нужно устремлять камеру вперёд, если там ждёт пропасть⁽²⁵⁾. Приподнимите камеру, чтобы предостеречь или подготовить игрока.

В некоторых платформерах периодически возникают ситуации, когда сложно подобрать точное направление для движения. Допустим, игроку нужно пройти по тонкой балке наискосок, но непонятно, насколько далеко. Это происходит из-за отсутствия глубины при неправильно выставленной камере⁽²⁶⁾.

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

С некоторыми правилами кинематографа и фотографии стоит быть аккуратнее⁽²⁸⁾. Знаменитое правило третей помогает добиться более гармоничного кадра с грамотно расставленными акцентами. Это пригодится при создании кат-сцен, но может навредить геймплею, если сместить героя вбок по правилу третей. Игроки обычно используют центр экрана как опорную точку при повороте камеры, поэтому в динамичных ситуациях их может сбить с толку, когда камера начнёт поворачиваться относительно персонажа в углу.

Если в игре есть механика полёта, то камеру для неё предстоит настраивать отдельно⁽²⁹⁾. Алгоритмы для наземного перемещения, как правило, не сработают, ведь в воздухе у персонажа совсем другие приоритеты. Например, игрок зачастую должен видеть, что находится внизу, чтобы приземлиться в подходящем месте.

Все правила выше очень важны, но не стоит опираться только на них⁽³⁰⁾. Получившаяся в результате написания алгоритмов камера хорошо справится с определением препятствий и удержанием аватара в центре композиции, но иногда дизайнерская задумка важнее этого. Правила можно и нужно игнорировать, если того требует отдельная сцена. При проектировании камеры убедитесь, что у вас будет возможность прописывать уникальные скрипты для подобных случаев.

Помощь игроку

В играх с открытым миром или просторными локациями игрок может заплутать⁽³¹⁾. Разработчики нередко решают эту проблему в лоб и добавляют в игру мини-карту или навигационные стрелки. Это эффективно, но грубо. Если хочется сохранить иммерсивность, можно использовать камеру. Когда алгоритм «чувствует», что игрок потерялся и начал бесцельно бродить из угла в угол, стоит аккуратно сместить ракурс в сторону ближайшей цели.

Когда камера должна показать не только персонажа, но и другую цель, будь то враг или сюжетный ориентир, действуйте с умом и учитывайте геймплейный контекст. Так, в драйвовом битемапе с большим количеством противников есть смысл отодвинуть камеру подальше⁽³³⁾. В противном случае ракурс будет постоянно скакать от одной цели к другой. А вот если объект интереса находится вдалеке, то лучше, наоборот, не отдалять камеру, а повернуть её⁽³⁴⁾.

Впрочем, и здесь стоит учитывать контекст. Если игрок хочет что-то рассмотреть или залезть в конкретное место, не нужно перетягивать внимание при помощи смещения камеры⁽³⁵⁾. Исключение составляют разве что очень важные события, которые ни в коем случае нельзя пропустить. Например, важные обучающие секции. Но даже в этих ситуациях желательно давать игроку возможность перехватывать управление над камерой⁽³⁶⁾. Например, в Bulletstorm (на видео выше) разработчики нетривиально акцентируют внимание игрока на объектах. Пользователю предлагают удерживать кнопку, чтобы рассмотреть что-то важное. За это дают дополнительные очки, но при большом желании игрок может и проигнорировать рекомендацию.

Удобство управления

Не ленитесь добавлять в игру как можно больше альтернативных настроек, таких как инвертированное управление или возможность поменять действия отдельных кнопок⁽³⁷⁾. Само же управление порой нужно корректировать так, чтобы избежать случайных нажатий. Например, если у вас есть опции управления камерой через гироскоп, то старайтесь калибровать его как можно чаще, ведь положение рук пользователя может постепенно меняться⁽³⁸⁾.

Если игра создаётся в том числе для геймпадов, следует делать кривую чувствительности при смещении стика⁽³⁹⁾. Дело в том, что многие игроки отклоняют стик сразу на максимальное значение, поэтому движения камеры получаются резкими. Используйте S-образную кривую, чтобы при смещении стика на половину радиуса камера двигалась незначительно. Это позволит точнее регулировать положение камеры.

Комфорт для всех игроков

Когда игрок перемещает персонажа в игре, камера в идеале должна реагировать с небольшой задержкой и инерцией. Это сделает игру плавнее, а движение — естественнее. Но есть нюанс: не забудьте настроить максимальный уровень отклонения аватара от центра экрана⁽⁴⁰⁾. В ином случае некоторые особо активные игроки сумеют вытолкнуть персонажа за пределы камеры.

Также Нески рекомендует с осторожностью экспериментировать с разными значениями FOV. При слишком низком показателе объекты будут двигаться очень быстро относительно аватара⁽⁴¹⁾. Это может вызвать симптомы морской болезни.

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

Нески отдельно отмечает не очень популярный эффект, который можно встретить в Gears of War, где камера покачивается в такт движениям персонажа⁽⁴⁴⁾. Это может выглядеть эффектно, но у многих вызовет дискомфорт. Будьте аккуратнее с такими радикальными решениями. Это же касается и строгой привязки камеры к аватару во время прыжка⁽⁴⁵⁾: это породит два последовательных неприятных скачка изображения — на подъёме и на спуске. Изменяйте положение плавно.

Ещё один неочевидный способ спровоцировать морскую болезнь — слишком быстро изменить положение камеры⁽⁴⁶⁾. Это часто встречается в играх с фиксированными ракурсами во время диалогов. Многие дизайнеры отказываются от склеек — вместо этого забирают камеру у игрока и перемещают её в нужное место. Джон Нески считает, что в таких ситуациях лучше всё-таки использовать склейку.

Наконец, если в игровой сцене есть элементы, ограничивающие движение, — допустим, максимальная высота, — постарайтесь избежать резкой остановки камеры⁽⁴⁷⁾. Если она врежется в невидимый барьер, это тоже создаст неприятное ощущение. Замедляйте камеру плавно.

Дополнительные советы

Джон Нески в полушутливой манере считает ошибкой делать игры для VR⁽⁴⁸⁾. Они нередко вызывают у людей морскую болезнь, и дизайнер не уверен, что эту проблему когда-либо можно будет искоренить полностью.

Во время плейтестов старайтесь при возможности привлечь как можно больше людей из разных демографических групп⁽⁴⁹⁾. Не ограничивайтесь только молодыми опытными игроками. Чем больше пользователей опробует вашу игру, тем больше неочевидных проблем вы сможете выявить.

* * *

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

Любая ошибка при создании камеры обратит на себя внимание и испортит ощущение. А самое главное, что все игры уникальны, поэтому опираться лишь на заготовленный набор алгоритмов не получится. Поэтому Джон Нески отмечает, что все его тезисы — лишь фундамент, который можно изменять, если того требует дизайнерская задумка⁽⁵⁰⁾.