mercury13_kiev (mercury13_kiev) wrote,
mercury13_kiev
mercury13_kiev

Categories:

Джон Нески. 50 основных ошибок в видеоигровых камерах [реферат]

Полное видео: 50 common game camera mistakes — and how to fix them

Перевод на Хабрахабре (не слишком качественный)

Задача видеоигровой камеры — обратить внимание на что бы то ни было, кроме самóй камеры. Потому камеры становятся заметны, когда они не срабатывают. Так что обратим внимание на ошибки. Отсебятина: в первую очередь это касается приставочных игр с управлением двумя миниджойстиками (я не люблю такие), тем не менее…

Постановка игровой камеры несколько отличается от кинематографической: не разработчик ставит камеру, а программа. Так что надо обобщить опыт кинематографа и вшить его в программу — автор это называет «гейматограф».

Есть три основных игровых камеры: фиксированная от 3-го лица (проходит сквозь «четвёртую стену», чтобы показывать персонажа в одном и том же ракурсе, распространена в 2D и DotA-подобных играх), динамическая от 3-го лица (четвёртую стену оставляем, камера, если надо, приближается-удаляется-поворачивается), и от 1-го лица (между глаз персонажа, и не надо заботиться, чтобы камера не потеряла персонажа, ведь она и есть персонаж).

1. Использовать динамическую (самую сложную) камеру, когда сработает и другой подход. Трёхмерные версии Mario некоторое время использовали динамическую камеру, но потом вернулись к фиксированной. Для студенческих проектов и игроджемов также динамическая камера не нужна.

2. Логика уровня и поведение камеры не соответствуют друг другу. Камера должна давать информацию, важную для игрока, и покрывать основные игровые ситуации. Здесь контрпример — 1-й уровень Super Mario, запрограммированный на GMod.

3. Управлять камерой в координатах мира или кватернионах. Игрок думает курсом, креном (обычно он 0) и тангажом — ими и надо управлять, только не забывайте о складывании рамок. Ну и также нужны сдвиг вверх-вниз, сдвиг влево-вправо (чтобы подобрать подходящие рамки), расстояние до игрока и угол зрения. Камера должна крутиться вокруг персонажа. A X/Y/Z камеры можно получить из этих параметров.

4. По умолчанию использовать такое расстояние от камеры до персонажа, что персонаж теряется из виду.

5. Препятствия закрывают боковой обзор. Автор предлагает пускать несколько зондирующих лучей («усов», по аналогии с усами кошки), и если препятствие слишком близко, приблизить камеру. Если это кинематографическая склейка (камера телепортируется), это нарушает правило 30 градусов — склейка должна менять ракурс камеры как минимум на 30°. Поэтому надо заранее обнаруживать такие препятствия и плавно подгонять ракурс.

6. Идти вразрез с намерениями пользователя: если всё-таки пользователь лепит камеру к препятствию, дайте ему это сделать.

7. Посадить камеру внутрь препятствия. Если уж так случается — подведите её поближе.

8. Допустить, чтобы независимые силы конкурировали за управление камерой. Если два правила тянут камеру в разных направлениях, мы не удовлетворим ни одно. У нас 7 осей камеры, пусть одна сила управляет одной осью, вторая — другой.

9. Делать, чтобы узкие колонны ни в коем случае не проходили между камерой и персонажем. Подобные объекты надо отмечать и не проверять «усами». А если камера обходит каждый прутик, это вообще плохо.

10. Посадить камеру внутрь такой колонны. Надо наладить несложную модель проверки столкновений.

11. Считать склон стеной, которую надо облетать стороной. В Journey, например, камера не отходит от склона, а поднимается выше. Можно также проверять угол между «усом» и поверхностью.

12. Сдвигать камеру в сторону, если мешающий предмет приходит сзади. Игровая физика защищает камеру от ударов спереди, усы — от ударов сбоку. Если ни то, ни другое не сработало, подвинуть камеру вперёд.

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

14. Камера выдерживает одинаковое расстояние до персонажа независимо от угла. Если надо посмотреть сверху, камеру лучше отодвинуть, чтобы было больше видно. А если снизу — камеру лучше не «бить в пол», а двигать по плавной кривой.

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

16. Независимо изменять тангаж, расстояние и поле зрения. Расстояние и поле зрения должны моментально выводиться по известному тангажу, делая экранный размер персонажа (грубо) постоянным. Конечно, могут быть и дополнительные правила наподобие 15.

17. Не делать «склейку», если персонаж прошёл через что-то непрозрачное. Как было сказано, проверка столкновений персонажем не даёт камере удариться во что-то передом. Правда бывают непрозрачные проходимые объекты, тогда всё, что остаётся,— склейка.

18. Изменить при «склейке» привязку управления к направлениям. Палец не может телепортироваться на рычажке, поэтому если такое вдруг случилось — менять привязку плавно. Ну или сделать видеовставку.

19. Изменить «склейкой» ориентацию игрока. Склейки — обычное дело в кино. Изменить привязку — временное неудобство, но есть проблема и более долгосрочная — игрок теряет ориентацию. Ориентируются люди по узнаваемым объектам и по счислению пути, и склейка ломает второе. Если уж склеивать, то не нужно менять направление более чем на 90°, и обязательно держать ориентиры в поле видимости.

20. Нарушать правило 180 градусов. Ещё одно правило, взятое из кино, звучит: при склейке не пересекать камерой линию между двумя важными предметами. В самóй игре склеек мало, потому что они опасны, а вот видеовставок это более чем касается! Если это склейка между видеовставкой и игрой, можно плавно провести камеру.

21. Фокусироваться только на персонаже. Задача камеры — показать, куда он идёт, и соответственно менять ракурс.

22. Полагаться на ручное управление камерой. Это как чесать голову и тереть живот одновременно. Надо всё-таки придумывать, как сделать, чтобы камера автоматически смотрела куда надо.

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

24. Мешать игроку оценивать расстояния. Игра трёхмерная, экран двухмерный. Виды сбоку хороши для вертикальной навигации, виды сверху — для горизонтальной.

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

26. Смотреть горизонтально, когда игрок бежит вверх-вниз по склону. Только важно: склон бывает неровным, и надо смотреть на среднюю крутизну (например, теми же «усами»). И ещё не надо, чтобы эта система выдавала небольшие стены за склоны.

27. Ошибки с «правилом третей». Показать бегущего персонажа не по центру — это классно. Только не качайте для этого камерой, взамен сдвигайте её. Правда, центр экрана служит «прицелом» для микроджойстика, так что надо быть осторожнее с этим. В Journey правило третей используется, когда персонаж стоит. А в Shadow of the Colossus у коня нет микроджойстика, есть руль и «газ».

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

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

30. Оставлять игрока в растерянности. Если игрок ушёл далеко от цели, надо мягко намекнуть (например, поворотом камеры), что делать. Но не жёстко: это лишает его чувства открытия. Многие используют компас или радар, но это не для Journey.

31. Поворачивать камеру, чтобы посмотреть на близкую цель. Например, в Batman: Arkham Asylum камера вечно бешено крутится, это не нужно. Надо сдвигать её назад или вбок.

32. И наоборот, сдвигать, чтобы посмотреть на дальние цели. Это приведёт к слишком большому сдвигу. Единственный способ посмотреть на солнце — повернуть камеру :)

33. Делать, чтобы сам персонаж загораживал какие-то цели. Лучший вариант — смотреть немного сверху. Можно также сместить камеру вбок.

34. Давать игроку управление камерой, а затем отнимать его. Подсказки и «рельсы» дают ракурсы по умолчанию, но игрок должен смотреть куда угодно. Если уж отнимаете — игрок должен видеть то, что он должен видеть!

35. Применить программную «подсказку» по камере сразу после того, как игрок посмотрел куда-то. Если игрок посмотрел, значит, он хочет осмотреть его получше, дайте ему это сделать. Если там ничего интересного, поверните на место через некоторое время, или когда игрок сдвинется.

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

37. Не давать инверсию управления камерой по обеим осям. Разработчики FPS знакомы с этим, но и в типичных приставочных бегалках это нужно. Переучиваться тяжело. Это, кстати, единственная настройка управления, которая есть в Journey [эксклюзив для PlayStation]

38. Реагировать на случайный ввод. Особенно это касается наклонов PS-джойстика; его нужно постоянно перекалибровывать. Но, как автор сказал, всё же надо было добавить опцию отключения наклона.

39. Использовать линейную кривую отклика. Рычажок не настолько точен, надо использовать S-образную кривую: центральные положения рычажка должны крутить камеру очень медленно.

40. Допускать, чтобы камера «убегала» слишком далеко. Резкие движения персонажа можно смягчить поперечным движением камеры — игрок не в центре. Но игрок не должен выходить из виду; если это намечается, нужно побыстрее вернуть камеру.

41. Видно слишком мало. Чем ближе камера, тем «быстрее» всё движется. На слайдах упоминается укачивание, которое особенно высоко в приставочных FPS, но, по-моему, причина ещё одна: нужно видеть, что делать и чего ожидать.

42. Быстро изменять угол зрения камеры. Известная проблема FPS с режимом прицеливания. Гонки изменяют зум, когда включаешь нитроускоритель. Изменение зума напоминает движение взад-вперёд и тоже может укачать.

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

44. Трясти камеру с каждым шагом игрока. Это также укачивает, нужна опция.

45. Сдвигать камеру, когда персонаж прыгает. После каждого прыжка вверх будет падение вниз. Отсебятина: в «Штирлице» камера сдвигалась. В более новых играх на том же движке, где были движущиеся платформы, я уже, как консультант по движку, настоял уточнить поведение камеры: не видно, куда прыгаешь.

46. Быстро сдвигать камеру в новое положение. Это правило «не склеивать без нужды», доведённое до абсурда. Это ничем не отличается от «склейки» и к тому же укачивает. Если управление на время теряется, можно и склеить.

47. Сохранять скорость тангажа, пока не «ударишься» в предел. ±90° — это складывание рамок, так что предел несколько ниже. Но, опять-таки, резкая смена скорости укачивает. Замедляйте камеру, когда она очень высоко, чтобы она плавно остановилась.

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

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

50. Писать для камеры общий «решатель с ограничениями». Лучше наладить несколько правил, которые предсказуемо взаимодействуют друг с другом. А то, что сразу не получилось как надо — обычная ошибка при разработке, которую можно и нужно исправить.

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

Q: Можно ли несколько опций, связанных с укачиванием, объединить в одну?
A: Думаю, разных людей укачивает по-разному.

Q: А ваши знакомые, подверженные укачиванию, знают, что именно их укачивает?
A: Это хороший вопрос. Но без большого количества опций и не поймёшь, что именно укачивает.

Q: Расширение поля зрения помогает справиться с укачиванием. Но в соревновательной игре часто ставят широкое поле зрения, чтобы больше видеть. Где баланс между этими двумя?
A: Я читал, что в Quake намеренно расширяют поле зрения, чтобы получить преимущество. Широкое поле зрения — это преимущество, так что почему бы и нет?

Tags: геймдев, переводы
Subscribe

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments