[Перевод] 50 типичных ошибок проектирования игровой камеры (часть 2)
Эта статья — вторая часть перевода выступления Джона Нески (John Nesky) с GDC14. Первую часть вы можете найти тут.
#26 Оставлять угол съёмки постоянным в то время, как персонаж бежит по склону
Техника заключается в том, чтобы, как и в предыдущем примере, определять изменение высоты пола перед персонажем. В случае, если высота выше или ниже текущей, можно немного изменить тангаж камеры. Однако если использовать для этих целей анализ наклона поверхности непосредственно под ногами игрока, можно получить неверную информацию, когда поверхность неровная. Поэтому лучше сделать рейкаст на некотором расстоянии впереди персонажа, чтобы получить что-то вроде усреднённого значения изменения высоты. Но и для этого способа характерна ещё одна проблема — рейкаст может легко спутать небольшую стену со склоном холма, поэтому использовать значение нормали в точке пересечения поверхности и рейкаста всё же нужно.
#27 Неправильно использовать правило третей
Правило третей — это ещё одно широко известное правило в кинематографе. В двух словах оно заключается в том, что картинка выглядит привлекательнее, если акцент композиции смещён от центра. Это простой способ изменить качество картинки, выдаваемой вашей камерой, в лучшую сторону.
Но будет неправильным для достижения этого эффекта вращать камеру вокруг своей оси. Если вы возьмёте настоящую камеру и захотите применить это правило, то скорее всего просто немного повернёте камеру в руках. Но напомню ещё раз, что в играх с видом от третьего лица камера не должна поворачиваться вокруг своей оси — центром её вращения всегда должен быть персонаж. Поэтому вместо того, чтобы вращать камеру вокруг самой себя, нужно просто слегка сдвигать камеру вбок.
Есть и другая проблема — игроки используют центр экрана, чтобы координировать управление стиками. И если вы сместите камеру, то игрок может растеряться и не понять, в каком же направлении бежит его персонаж. Поэтому в Journey мы использовали правило третей только тогда, когда игрок стоит на месте. А когда он отклоняет стик, мы плавно смещаем камеру так, чтобы персонаж снова оказался в центре экрана.
В качестве контрпримера можно привести Shadow of Colossus. В этой игре, когда вы скачете на лошади, и камера смещается вбок, не возникает никакой дезориентации, потому что игроку не нужно использовать стик, чтобы бежать вперёд: вместо этого он использует курок геймпада как педаль газа. Стик в этом случае используется только для того, чтобы поворачивать персонаж влево-вправо.
#28 Использовать одинаковую логику при перемещении на земле и в воздухе
Пока что мы рассматривали только перемещение игрока по земле. Но в вашей игре могут существовать и другие способы передвижения. В Journey, например, персонаж может не только бегать, но и летать. Такие разные способы перемещения подразумевают разные траектории движения персонажа, и игроку нужно оценивать эти ситуации по-разному.
Полёт в Journey устроен так, что всё, что полетело вверх, рано или поздно упадёт вниз, и очень важно показывать игроку, куда он приземлится (особенно если у него на исходе энергия, которая тратится на полёт). Поэтому в начале полёта камера смотрит немного вверх, показывая, куда персонаж полетит, но как только запасы энергии иссякают, камера поворачивается вниз, чтобы игроку было проще выбрать, куда приземлиться.
Такие приёмы не нужны для непродолжительных прыжков, поэтому это правило можно постепенно включать, основываясь на высоте, на которой находится персонаж.
#29 Полагаться только на процедурное поведение камеры
Все трюки, которые мы рассмотрели ранее, представляют собой автоматические механизмы, реагирующие на изменение окружения. Но рейкасты могут только определить форму поверхности, но не сказать, что является важным для игрока. Гейм-дизайнерам нужно самим решать, что важно для игрока в данный момент времени, и что он должен видеть.
Поэтому на уровни в вашей игре можно добавить заскриптованные подсказки для камеры, определяющие, что она должна показывать в конкретный момент времени. Такие подсказки ещё более важны в условиях ограниченных пространств. Камеры с динамическим углом съёмки хороши для игр с открытыми пространствами, где нет большого количества препятствий, но в закрытых пространствах есть множество объектов, которых камере нужно избегать. И чем больше мы ей в этом поможем, тем лучше.
Например, в Journey есть высокая башня, на которую взбирается игрок. Башня представляет собой выпуклый многоугольник, и камера направляется в его центр так, что игрок может хорошо видеть, что происходит вокруг.
#30 Позволять игроку заблудиться
Игроки любят исследовать игровой мир, и мы хотим предоставить им такую возможность. Но мы должны быть уверены, что они не заблудятся. Простейшее решение, используемое во многих играх — это стрелка, указывающая на текущую цель, или миникарта. На мой взгляд, это слишком грубое решение, и мы не использовали его в Journey. Я предпочитаю использовать незаметные трюки с камерой, подсказывая игроку, куда ему нужно идти.
Например, если в Journey игрок приближается к краю локации, камера разворачивается в обратную сторону, намекая игроку, куда ему стоит идти. Также можно следить за тем, чтобы игрок не начал слишком удаляться от текущей цели. Как только он отойдёт на значительное расстояние, поворачивайте камеру, указывая верное направление. Однако, не стоит слишком навязчиво вести игрока, так как тем самым вы можете отобрать у него радость исследования игрового мира.
#31 Поворачивать камеру так, чтобы посмотреть на цели, расположенные близко
Если вы решите написать скрипт, задачей которого будет указание, скажем, на персонажа, расположенного рядом с вами, первое, о чём вы можете подумать — это разворот камеры на этого персонажа. Но в этом случае камера будет постоянно вращаться, потому что персонаж находится рядом с игроком, и любое его перемещение (или смена персонажа, на которого мы хотим развернуть камеру) будет приводить к значительным изменениям поворота камеры.
К счастью, есть другой способ достигнуть желаемого поведения. Он заключается в том, чтобы сдвинуть камеру в сторону или назад, помещая интересующую точку в пространстве в область видимости. В этом случае мы меньше дезориентируем игрока.
#32 Перемещать камеру так, чтобы посмотреть на цели, расположенные далеко
Это обратная ситуация. Как мы уже говорили, если вы хотите посмотреть на что-то, расположенное близко к игроку, вы немного смещаете камеру вбок или от игрока. Но если вы хотите посмотреть на что-то удалённое, расположенное, скажем, на горизонте, то никакое смещение камеры не приведёт к изменению позиции интересующего объекта на экране. В этом случае правильным будет просто повернуть камеру.
#33 Позволять персонажу игрока заслонять собой цели, расположенные впереди
Если вы поворачиваете камеру, чтобы указать игроку на что-то, и персонаж игрока расположен в центре экрана, есть риск заслонить интересующую область самим персонажем. В этом случае вы можете сдвинуть камеру в сторону. Это, кстати, отличный шанс использовать ранее упомянутое правило третей. Но иногда простейшим решением будет наклонить камеру так, чтобы она смотрела на персонажа немного сверху, позволяя тем самым игроку заглянуть за него.
#34 Сначала давать игроку контроль над камерой, а затем забирать
Если вы сначала дадите игроку управлять камерой, а затем запретите, то его это может обескуражить. Так что когда вы делаете подсказки для камеры, как минимум дайте игроку возможность по прежнему управлять ей. Но если вы всё же хотите отобрать у игрока эту возможность, сделайте так, чтобы игрок уже видел всё, что нужно, и ему бы даже не захотелось изменять положение камеры.
#35 Применять подсказку сразу же после того, как игрок повернул камеру
Если игрок поворачивает камеру, значит, он хочет куда-то посмотреть. Но как только он отпускает управление, ваши подсказки для камеры сражу же начнут поворачивать её в нужную сторону. Поэтому гораздо лучше, если есть какая-то задержка перед перехватом управления камерой, которая бы позволила игроку смотреть туда, куда он сам повернул камеру. А ещё лучше, если перехват осуществляется после того, как игрок начал движение.
#36 Не давать продвинутым игрокам исследовать мир
Даже если у игрока есть возможность управлять камерой, его может раздражать, что подсказки всё время пытаются заставить его идти не туда, куда он хочет. Это особенно важно, когда игрок проходит игру уже не в первый раз и хочет разведать новые локации. Поэтому как только подсказка сработала и указала игроку на его цель, эту подсказку можно выключить, чтобы позволить игроку самостоятельно составить маршрут до этой цели.
#37 Не предоставлять инвертированную схему управления
Об этой проблеме знают практически все, особенно разработчики шутеров от первого лица. Часть игроков хочет, чтобы движение стика вверх означало движение камеры вниз и, наоборот, другая часть хочет, чтобы «вверх» означало вверх, а «вниз» — вниз. Они могут либо перестать играть в игру, либо постоянно жаловаться, если не смогут поменять управление на то, которое им нравится. Поэтому позаботьтесь о том, чтобы в настройках вашей игры можно было включить инвертированное управление камерой.
#38 Обрабатывать случайные нажатия
В Journey мы решили сделать два способа управления камерой: при помощи стиков и наклонения самого геймпада. Последний способ частично перекочевал из другой нашей игры — Flower. На самом деле, мне кажется, там он пришёлся больше к месту, поскольку там не нужно было делать ничего, кроме как управлять камерой, в то время как в Journey игрок делает много всего в один момент времени. Поэтому игрок может наклонить контроллер случайно, и это приведёт к нежелательному движению камеры. Кроме того, в отличие от стиков, у наклона контроллера нет жестко заданного нейтрального положения. Один из способов избежать нежелательного движения камеры — это постоянная перекалибровка, позволяющая пересчитывать нейтральное положение контроллера в зависимости от того, как игрок его держит.
У нас были причины, чтобы поддерживать такой способ управления, потому что он интуитивно понятнее, особенно для новичков. Но, наверное, стоило хотя бы дать возможность игроку отключить его в настройках.
#39 Использовать линейную зависимость
У аналоговых стиков небольшой радиус передвижения. Зачастую это не имеет особого значения, потому что игроки привыкли передвигать стик до упора. Но я думаю, что лучше иметь возможность передвигать камеру медленно, чтобы игрок мог направить её туда, куда ему нужно. Многие делают это, используя логистическую функцию (так называемая s-кривая) от входных данных контроллера.
#40 Позволять камере отлетать слишком далеко
Чтобы избежать дёрганья на экране, когда игрок двигает своего персонажа из стороны в сторону, зачастую сглаживают движение камеры так, что персонаж может немного смещаться с центра экрана. Но если сделать камеру слишком ленивой, то быстрый персонаж сможет убежать с экрана, а это проблема. Поэтому не забудьте установить какой-то лимит на то, насколько далеко персонаж может сместиться от центра экрана. Кроме того, можно сделать так, чтобы камера двигалась впереди персонажа. Например, в Yoshi«s Island, если игрок бежит в одном направлении какое-то время, то камера сдвигается в направлении движения.
#41 Использовать маленький угол обзора
Угол обзора, как мы уже говорили, это зум. Если зум очень большой, то даже самое незначительное движение становится огромным. Приближение делает величину движения больше, а отдаление — уменьшает.
Возьмём ту же Yoshi«s Island. У многих из вас она вызовет чувство ностальгии, но когда я попытался показать её моим друзьям, они не смогли в неё играть, потому что камера там двигается слишком быстро. Это вызывает чувство сродни морской болезни. Поэтому было бы здорово, если бы угол обзора камеры был больше, и ей не приходилось бы так часто перемещаться, чтобы поспеть за передвижениями игрока.
Эта ошибка касается и шутеров от первого лица. Они чаще всего вызывают у игроков морскую болезнь, и таким людям советуют изменить угол обзора в настройках игры. Поэтому если вы делаете FPS, особенно для платформ с разнообразной конфигурацией, добавьте возможность изменить угол обзора, чтобы не потерять игроков, склонных к укачиванию.
#42 Быстро изменять угол обзора
Эта проблема также зачастую свойственна шутерам. Когда игрок начинает целится в оптический прицел, камера быстро сужает угол обзора. Эта проблема иногда встречается в гонках — когда игрок резко набирает скорость, камера увеличивает угол обзора, чтобы подчеркнуть ускорение. Такие трюки тоже приводят к укачиванию, так что будьте осторожны.
#43 Трясти камеру
Этот эффект очень часто используется во всех жанрах игр, потому что он помогает акцентировать удары, выстрелы и взрывы и помогает игре выглядеть более реалистичной. Некоторые говорят, что это простейший способ придать игре более завершённый вид, и он, без сомнения, очень полезен. Но вам стоит знать, что не все игроки одинаково воспринимают этот эффект. Амплитуда и продолжительность тряски, которая кажется нормальной вам, для другого будет слишком большой. Поэтому неплохо иметь в вашей игре настройки, позволяющие изменять интенсивность тряски.
#44 Трясти камеру во время ходьбы персонажа
Этот приём уже не так распространён и, чаще всего, касается игр с видом из-за плеча персонажа. Он опять же служит для того, чтобы придать игре больше реализма. Но то, что вам кажется реальным, другому может таким не показаться или даже вызвать тошноту. Суть приёма похожа на предыдущий, с той лишь разницей, что скорость, с которой перемещается камера во время тряски, в этом случае гораздо ниже. Но риск вызвать у игрока приступ морской болезни остаётся прежним. Поэтому стоит иметь возможность отключить этот эффект.
#45 Сдвигать или поворачивать камеру вверх-вниз, когда персонаж прыгает
Во многих играх с видом от третьего лица и сайд-скорллерах камера жёстко связана с персонажем. Поэтому, когда он прыгает, камера резко начинает движение, а когда он приземляется — камера резко останавливается. Это тоже может вызвать тошноту у игроков.
Мы снова находимся в ситуации, когда всё, что полетело вверх, упадёт вниз. При этом персонаж вряд ли успеет скрыться за пределами экрана. Поэтому мы можем просто оставить камеру в покое. В некоторых играх (например в Super Mario) камера ждёт, пока персонаж приземлится на поверхность выше или ниже текущего положения, и только тогда уже меняет свои координаты. А в Journey мы просто сглаживаем движения камеры, чтобы избежать частых и резких её передвижений.
#46 Быстро перемещать камеру в новую позицию
Это довольно часто случается в играх, будто некоторые разработчики слишком буквально восприняли правило об отсутствии резких смен кадров. Некоторые игры из серии Zelda особенно хорошо иллюстрируют этот пример. Быстрые перемещения камеры можно расценивать так же, как и резкую смену кадров, плюс ко всему они тоже могут вызвать приступ морской болезни у игрока. Поэтому, если во время такого перемещения вы отбираете у игрока управление, лучше сделать резкую смену кадров.
#47 Поворачивать камеру с постоянной скоростью вплоть до достижения границ поворота
В использовании Эйлеровых углов есть свои недостатки — это и складывание рамок, и другие проблемы, возникающие, когда вы смотрите строго вверх или вниз. Скорее всего, вам и не нужно будет позволять игроку смотреть в этих направлениях, потому что вы зададите границы поворота камеры. Но во многих играх, если вы сдвинете стик, скажем, вверх, камера будет равномерно поворачиваться в нужном направлении, пока резко не упрётся в ограничение. Гораздо лучше заранее это предвидеть и постепенно снижать скорость вращения камеры, пока она не достигнет граничного угла поворота.
#48 Разрабатывать только для Oculus Rift
Это, конечно, не является ошибкой. Но дело в том, что игры постепенно становятся всё реалистичнее и всё лучше передают ощущение движения, и поэтому всё чаще могут вызвать морскую болезнь. Возникает это неприятное ощущение, когда мозг не может сопоставить то, что вы видите, с тем, что ваше тело чувствует. Разработчики Oculus Rift утверждают, что борются с этим явлением, и нет причины им не верить. Но чтобы максимально увеличить вашу аудиторию, лучше не делать игру исключительно для Oculus Rift. Предоставьте игрокам и другой способ поиграть в вашу игру, потому что многие из них вряд ли смогут сделать это в ближайшие несколько лет.
#49 Тестировать на узкой демографической группе
Лучше всего на недостатки умеют указывать дети и начинающие игроки. А чужие люди, лично с вами не знакомые, гораздо охотнее предоставят критику. Но вам стоит активно расспрашивать тестировщиков, потому что многие люди могут, например, почувствовать тошноту, но не сказать об этом, посчитав это своей слабостью. Поэтому вам нужно сделать так, чтобы им было приятно с вами общаться и чтобы они не постеснялись сказать, если заметят какую-то проблему с вашей игрой, потому что вы не хотите, чтобы ваши игроки испытали те же проблемы.
#50 Изобретать универсальный алгоритм
Принимая во внимание обилие ошибок и ограничений, описанных выше, может возникнуть соблазн создать какую-то функцию, которая будет определять, насколько хорошо выполняются наши условия, и выдавать оптимальный угол поворота, отвечающий всем ограничениям. Но почти никогда такой подход не даёт хороших результатов, потому что когда вы позволяете компьютеру сделать всю работу за вас, очень трудно предугадать, что же получится в итоге. А если вы не можете предугадать результаты, то не можете спроектировать правильное поведение. Вам нужно итеративно менять вашу систему, каждый раз имея возможность заранее сказать, к каким последствиям эти изменения приведут. Поэтому, чтобы правильно расставить приоритеты между обилием ограничений, накладываемых на поведение камеры, или найти способ их наилучшего исполнения, нужно чётко понимать взаимосвязь между всеми этими ограничениями.
Дьявол кроется в деталях
Способ, который работает для одной игры, не будет работать для другой. Поэтому весь этот список может помочь вам сэкономить время на изучение вопросов, связанных с игровыми камерами, и послужить вам способом оценки того, насколько хорошо работает ваше решение, но он никогда не заменит тестирования.
