Тестирование видеоигр, или Легкий способ попасть в геймдев — Александр Торговкин

Building (Строительство)

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

Life Sim (Сим, симулятор жизни)

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

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

4.2. Функциональное тестирование

4.2.1. Тестирование игровых механик

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

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

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

Практически в любой игре есть ключевые и второстепенные механики. Ключевые механики составляют основу геймплея любой игры, ее core gameplay loop – основной игровой цикл. Именно эти механики повторяются раз за разом, и именно они должны вводить игрока в состояние потока. Поэтому их работа тестируется особенно тщательно.

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

Игровой тестировщик должен уметь отличить основные механики от второстепенных. Каждый игровой жанр, как правило, характеризуется определенным набором ключевых механик. Знание и умение выделять эти механики помогут тебе выбрать проверки для включения в smoke-тест[25], определить очередность и важность тестов. Хороший тестировщик понимает, какие базовые тесты необходимо проводить для той или иной игры, даже не видя ее.

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

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

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

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

Были выделены три основных игровых жанра по действиям, которые игроки совершают в игре.

1. Игры общения (действия связаны с получением информации, общением, изучением мира).

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

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

Все игры внутри группы между собой очень похожи, но есть и игры «с отклонениями». Эталоны групп игр находятся на середине (и включают в себя три элемента), а жанры с отклонениями – тем дальше от центра, чем больше таких отклонений (см. «Схема жанров» ниже).

В таблице ниже показано, как распределяются игры по жанрам.

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

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

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

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

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

Каждое из предложений, которое вошло в твое описание, будет Ожидаемым результатом (Expected result) будущих тест-кейсов. Так ты сразу будешь понимать примерный объем работы и процент тестового покрытия. И еще до начала работ по тестированию у тебя уже будет готов некоторый объем тест-кейсов.

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

Например, в ЛЮБОМ однопользовательском FPS (first person shooter), согласно таблице и нашему опыту, пользователь может совершать следующие действия.

Функциональное тестирование (критические функциональные области)

1. Перемещаться по уровню, используя кнопки управления (в случае PC).

Описание. Перемещение персонажа в игре происходит в следующих направлениях и способами: вперед, назад, шаг влево, шаг вправо, стрейф[26] влево, стрейф вправо, прыжок, присед.

2. Подбирать разные виды оружия.

Описание. Подбор оружия, как правило, происходит, когда персонаж проходит «сквозь» него.

3. Подбирать аптечки здоровья.

Описание. Аптечка подбирается, если количество очков здоровья (HP, health points) составляет менее 100. Персонаж подбирает аптечку, проходя «сквозь» нее. При подборе аптечки количество HP в HUD (head-up display) увеличивается на количество HP аптечки, но не более 100 в общем.

4. Подбирать патроны/снаряды/ammo.

Описание. Снаряды подбираются, если их количество для определенного вида оружия составляет меньше, чем определено в игре. Персонаж подбирает снаряды, проходя «сквозь» них. При подборе снарядов количество зарядов в HUD (head-up display) увеличивается на количество зарядов ящика со снарядами, но не более установленного для данного вида оружия в общем.

5. Уничтожать разных мобов или разрушать объекты на уровнях игры.

Описание. Разный урон наносится в зависимости от типа оружия. При этом выстрел из оружия должен сопровождаться: а) анимацией оружия (отдача – recoil, перезарядка – reload), б) спецэффектом (вспышка – muzzle flash), в) звуком, синхронизированным с анимацией.

6. Проходить на другие уровни.

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

7. Получать урон от противников разного уровня, погибать и возрождаться в игре.

Описание. Разные противники наносят разный урон. Урон также зависит от типа защиты, который имеется у персонажа. Возрождение может происходить по-разному: в начальной точке или специальной точке на карте с полным здоровьем или неполным здоровьем, с сохранением добычи и инвентаря, частичным сохранением или без сохранения.

…

Функциональное тестирование (некритические функциональные области)

8. Избегать прямого контакта с неигровыми персонажами (non-player character, NPC), если это обязательно по сюжету игры.

Описание. Финальную цель игры можно/нельзя достигнуть, не вступая в контакт с NPC и мобами.

9. Не накапливать / игнорировать игровую добычу (Loot), если она не необходима для прохождения игры.

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

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

Описание. Финальную цель игры можно/нельзя достигнуть, не выполняя дополнительные задания.

…

Нефункциональное тестирование (критические области)

1. Иметь возможность установить продукт на конкретный PC с определенными системными требованиями.

Описание. Произвести успешную установку на конкретный PC.

2. Иметь возможность использовать игровой продукт на совместимой программно-аппаратной части.

Описание. Использовать игровой продукт на какой-то из игровых платформ (PC, игровая приставка или смартфон и т. д.) со стабильным показателем FPS и т. д.

3. Сохранять и загружать ранее сохраненную игру с сохранением игрового прогресса и достижений.

Описание. Произвести сохранение игры и последующую загрузку игры с сохраненным прогрессом и достижениями.

4. Взаимодействовать с игровым продуктом, включая использование настроек продукта в пользовательском интерфейсе (UI).

Описание. Производить настройки персонажа, игрового окружения графической и звуковой подсистем, подсистемы искусственного интеллекта (ИИ) посредством графического интерфейса пользователя.

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

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

…

Нефункциональное тестирование (некритические области)

6. Иметь возможность продолжить игровой сеанс на другой платформе с использованием единого аккаунта пользователя (кроссплатформенное сохранение).

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

7. Иметь возможность настраивать игру в соответствии с собственными представлениями об удобстве пользования.

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

Представим полученную схему проверки критических функциональных областей FPS (first person shooter) в виде матрицы трассируемости.

В качестве другого примера можно рассмотреть более сложный жанр – RPG.

Функциональное тестирование (критические функциональные области):

1. Игрок управляет одним или несколькими уникальными персонажами.

2. Игрок играет определенную роль своего персонажа.

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

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

5. Игрок находит новые игровые области (исследует мир).

6. Игрок находит предметы и хранит их в инвентаре персонажа(ей).

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

8. Игрок выполняет сюжетные задания.

9. Игрок взаимодействует (общается, сражается совместно или против) с другими персонажами (игроками и компьютером).

…

Функциональное тестирование (некритические функциональные области)

10. Игрок создает дополнительных персонажей.

11. Игрок должен планировать развитие персонажа(ей).

12. Игрок выбирает путь из нескольких вариантов.

13. Игрок воздействует на игровой мир (открывает сундуки, обыскивает убитых врагов и проч.).

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

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

16. Сюжет зависит от решений и выбора игрока. Часть этих выборов имеют последствия для сюжета.

…

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

Можно подвести итог.

1. Игры одного жанра «устроены» примерно одинаково и совпадают в геймплейных элементах (см. схему выше).

2. Определив жанр игры, мы можем определить «ядро» ее геймплейных элементов и механик.

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

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

Задание. Тестирование ключевого функционала игрового персонажа в RPG.

Персонаж и его характеристики

Игровой персонаж (герой) имеет основные характеристики: здоровье (HP), уровень (Level), опыт (Experience), сила (Strength), ловкость (Agility), интеллект (Intelligence), а также другие специфические характеристики (если применимо).

Персонаж может выполнять различные действия в игре: атаковать, использовать заклинания (если доступны), перемещаться по миру игры, взаимодействовать с объектами и NPC и т. д.

Задачи для тестирования

1. Тестирование боевых характеристик

2. Тестирование управления и взаимодействия

3. Тестирование системы прокачки и опыта

4. Тестирование анимаций и звуков

5. Тестирование сохранения и загрузки игры

Укажи, какие области и аспекты ты протестируешь в первую очередь по каждой из задач.

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

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

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

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

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

Я уже говорил о том, что игровое ПО включает в себя подсистемы, которые радикально отличают видеоигры от ПО любого другого вида. К ним относятся: графика (включая игровые уровни), звук, игровые механики, искусственный интеллект, физика, локализация, контроллеры. Можно предположить, что разница в подходах к тестированию видеоигр и прикладного ПО заключается как раз в специфичных проверках этих подсистем. Все, что написано выше, можно отнести к тестированию игровых механик. Теперь поговорим о проверке графической подсистемы.

4.2.2. Тестирование уровней (игровых карт)

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

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

Разработка игровых уровней – задача левел-дизайнера (дизайнера уровней). При разработке уровня выделяется несколько этапов, на каждом из которых могут возникнуть дефекты.

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

«Серый» прототип (Greybox, Blockout). Это недетализированный прототип уровня, часто состоящий из простых геометрических форм (кубов, параллелепипедов, конусов, цилиндров), имитирующих здания и другие объекты, которые дизайнер может передвигать или удалять. На этом этапе опытные дизайнеры уровней используют заранее подготовленные метрики для соблюдения масштаба и пропорций.

Пример greybox

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

Диспропорция укрытий

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

«Белый» прототип (прототип геометрии, Whitebox). На этом этапе из временных моделей собирается прототип геометрии. К работе над ним подключаются художники по окружению, задача которых – проработка визуальной части. Они должны использовать любые средства, чтобы улучшить навигацию по уровню (освещение, контраст и проч.). После проверки геймплея на этом прототипе работа переходит на новый уровень.

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

К дефектам дизайна уровней, помимо упомянутого выше, также относят следующее.

1. Пропасти в карте (Map holes)

2. Невидимые стены (Invisible walls)

3. Застревания (Stuck points)

4. Дефекты измененного ландшафта (Landscape changes defects)

5. Видимые стыки между текстурами (Visible texture seaming)

6. Дефекты разрушаемого окружения (Destructible environment defects)

Пропасти в карте (Map Holes) – это дефекты неправильной геометрии уровней. Они возникают от того, что части модели уровня (стены и пол, части пола и т. д.) неплотно примыкают друг к другу. Персонаж может «провалиться под карту», то есть попасть в область, где для него отсутствует опора, и под действием гравитации бесконечно долго падать в пустоту.

Например, в игре Fortnite: Save the World в одном из подземелий долгое время был «разрыв» на карте, куда персонаж мог провалиться и погибнуть.

Еще один пример map hole – неплотное примыкание скал и поверхности в игре Apex Legends. В эту дыру время от времени проваливались игроки.

Невидимые стены (Invisible Walls) – как правило, результат неправильного моделирования объектов. Часто они появляются, когда видимая модель объекта не совпадает с моделью коллизий, то есть физической моделью объекта, которая придает осязаемость объекту.

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

Кроме того, ранее так регулировали передвижение персонажа игрока и не давали ему уйти дальше нужного. Но показывать игроку, что впереди что-то есть, и при этом использовать невидимые стены для недопуска персонажа в эту зону – признаки плохого левел-дизайна. Сейчас так практически не делают, и невидимые стены часто могут быть следствием реконструкции уровня: к примеру, какую-нибудь модель могли забыть убрать или добавили невидимый элемент в качестве временной «заглушки».

«Застревания». Дефекты, связанные с застреваниями, могут быть вызваны различными причинами. Одной из причин может быть перестройка уровня и нарушение при этом использования навигационной сетки[28] (Navigation Mesh) или ее автоматической генерации. Например, при перестройке уровня были передвинуты модели, но навигационная сетка осталась старой. Как следствие, NPC могут «идти в стену» или любой другой предмет, который они не смогут обойти, и застрянут там (это как раз и есть один из случаев застревания – stuck point).

Последствия измененного при разработке рельефа. Над разработкой локации могут одновременно работать много специалистов. Некоторые добавляют или удаляют объекты; другие изменяют геометрию местности (карты), поднимая или опуская часть поверхности локации. Из-за этого появляются дефекты, когда ранее стоящий на поверхности объект зависает в воздухе.

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

Дефекты разрушаемого окружения. Если окружение в игре не интерактивное, то есть игрок не может с ним взаимодействовать, уровень реалистичности такой игры остается довольно низким, даже если объекты окружения проработаны с безупречной точностью и четкостью. Понятие «разрушаемое окружение» относится к различным объектам: ландшафту (для этого существует специальный термин – деформируемый ландшафт), растительности, интерьеру, зданиям и сооружениям и т. д. Обычно особое внимание созданию разрушаемого окружения уделяется в играх, где это становится важной частью геймплея или даже игровыми механиками. Например, в игре Worms W. M.D., как и в ее предшественнице, разрушаемые уровни позволяют вносить в геймплей дополнительные возможности для игрока, влияя на его стратегию, и добавляют в игру изрядную долю веселья.

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

К дефектам разрушаемого окружения можно отнести следующее.

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

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

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

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

4.2.3. Тестирование моделей и анимации

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

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

1. модели (персонажи, предметы, транспорт и т. д.):

a. коллизии моделей;

b. анимация моделей;

2. визуальные эффекты (VFX);

3. освещение сцены, отражения и тени.

Рассмотрим эти области графической подсистемы подробнее.

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

В процессе создания игровой модели выделяют несколько этапов.

Концепция (Concept). Здесь происходит выбор визуального стиля будущей модели. Именно на этом этапе закладывается фундамент для всей последующей работы.

Моделирование (High-poly). На этом этапе происходит создание 3D-модели в специальном редакторе[29]. Этот процесс может проходить по-разному, но в случае персонажей он похож на создание скульптуры, в котором мастер создает максимально реалистичную модель.

Ретопология (Low-poly). Игровая модель чаще всего состоит из полигонов, то есть многоугольников, угловые точки которых имеют точные координаты в 3D-пространстве и соединены между собой линиями. Чем выше детализация, тем большее количество полигонов должно быть использовано в моделировании (модели high-poly); чем она ниже, тем меньше нужно полигонов (модели low-poly). Этот этап предполагает упрощение геометрии модели и уменьшает количество использованных полигонов при сохранении достаточно высокого качества модели.

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

Пример low-poly, mid-poly и high-poly моделей

Развертка (UV mapping). Сетку полигонов, из которой состоит 3D-модель, необходимо «развернуть» в 2D-пространстве для последующего текстурирования. Другими словами, сопоставить X, Y и Z координатам 3D-модели координаты U и V «развертки» (буквы U и V используются, потому что X и Y уже заняты). UV-развертка похожа на детали выкройки, которые портной вырезает из ткани, чтобы потом сшить пиджак.

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

Текстурирование модели (Skinning), которое происходит на последующих этапах, заключается в наложении заранее подготовленных растровых текстур на 3D-полигональную модель для имитации рельефа, придания цвета и окраски.

На этом этапе могут возникнуть ошибки, связанные с:

• неправильным масштабированием текстуры, из-за чего изображение на поверхности моделируемого объекта искажается;

• выбором некачественных текстур низкого разрешения;

• неверной настройкой прозрачности текстур, параметров отражения и преломления;

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

Создание скелета для анимации (Rigging). Чтобы анимировать модель в дальнейшем, нужно, чтобы эта модель имела некий каркас (риг) внутри, на основе свойств которого и будет происходить анимация. Например, человекоподобные (антропоморфные) модели должны иметь «скелет», и чем сложнее анимация, тем более детализированным должен быть скелет. Создание такого «скелета» называется риггингом. Кости скелета связаны между собой для создания реалистичной анимации: если у персонажа поднимается кисть руки, то остальные связанные с ней кости должны анимироваться соответствующе.

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

Дефекты моделей

Заметные швы между частями тела персонажа

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

Слишком большое количество полигонов

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

Несоответствие историческому (реальному) прототипу

Посмотри на изображение автомата на картинке дальше. Ничего странного не замечаешь?

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

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

То ли дело когда приходится тестировать несуществующее оружие, например какой-нибудь «квази-плазмоган». Ни один, даже самый дотошный игрок не скажет вам, что он выглядит не так, как должен. Хотя и здесь нельзя пренебрегать здравым смыслом.

Дефекты коллизий и хитбоксов

Ты наверняка замечал, что большинство случаев взаимодействия моделей основано на их касании друг друга. Чтобы игрок воспринимал такое взаимодействие как реалистичное, используются так называемые модели коллизий – объекты, невидимые игрокам, но обладающие физическими свойствами. Их называют коллайдерами (colliders). По сути, коллайдер – это невидимая упрощенная форма объекта, привязанная к нему, для расчета результата столкновения с другими объектами. Поэтому большинство объектов виртуального мира игры не проходят друг сквозь друга, а ведут себя естественно, а точнее, как их запрограммировал разработчик: персонажи не проваливаются сквозь землю и не проходят сквозь стены, потому что сами содержат коллайдер с настройками физики.

Часто взаимодействие персонажей происходит агрессивно, то есть с нанесением физического урона. Поэтому модель коллайдера включает в себя так называемый хитбокс (hit-box). Хитбокс – это часть физической модели, при столкновении с которой запрограммированный объект (например, пуля, копье, меч или кулак) «наносит урон», а точнее, если запрограммированный на нанесение урона объект сталкивается с хитбоксом физической модели (коллайдера) другого объекта, из переменной здоровья второго объекта вычитается определенное количество единиц здоровья (health points). На практике это выглядит так: «Персонаж стреляет из лука в кабана, стрела попадает в кабана (но не в голову или сердце), кабан визжит от боли и начинает спасаться бегством. Повторное попадание стрелы в кабана, скорее всего, его убьет».

Коллайдеры есть практически у всех объектов в игре. Для определения области коллизии, например, у здания, обычно достаточно знать только координаты вершин его углов, а вот для игрового персонажа потребуется куда более точная настройка. При работе с коллайдерами объектов игрового уровня на первое место всегда ставится не точное соответствие геометрии объекта, а удобство игрока. Как правило, коллайдеры большинства объектов уровня – примитивы (параллелепипеды, конусы, цилиндры): если бы коллизия рассчитывалась для соприкосновения с каждым камнем или впадиной на уровне, игрок просто не смог бы перемещаться по локации. Однако если речь идет, например, о шутере, то вряд ли игрок будет рад видеть, как пуля проходит сквозь тело оппонента, не нанося ему никакого урона, – или, наоборот, поражала бы, пролетая мимо. Поэтому в этом случае работа с коллайдерами и хитбоксами персонажей становится очень сложным занятием. И, как любое сложное занятие, оно не обходится без ошибок разработчика, которые превращаются в дефекты.

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

Еще одна задача – проверка корректного размещения хитбоксов и урона, наносимого объекту при взаимодействии с ними. Ошибки тут могут вызвать фрустрацию у пользователей. Например, в игре Battlefield 2042 физическая модель с хитбоксами у одной из моделей (Falck) была шире, чем ее видимая модель, что приводило к более частым смертям персонажа.

Дефекты анимации

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

Есть и другие примеры багов анимации.

Дефекты лицевой анимации (Facial Animation)

Лицевая анимация у модели может создаваться разными способами: на основе блендшейпов (Blend Shapes, форм для смешивания), а также мускульной или кластерной (на основе костей) модели. Распространенный способ с помощью блендшейпов подразумевает создание базовой модели лица персонажа с нейтральным выражением лица и производства на основе ее копий «выражений» (эмоций) в необходимом количестве с обязательным сохранением количества вершин полигонов и их нумерации (то есть их нельзя объединять, удалять или добавлять новые). Затем при создании анимации в редакторе указывается базовая модель и целевая модель (Target). После этого можно использовать управляющие элементы для плавного перехода от одной модели к другой (например, от нейтрального выражения до улыбки). Частный случай дефектов лицевой анимации – дефекты синхронизации губ (Lip Sync), когда отсутствуют блендшейпы отдельных фонем, используются неправильные последовательности блендшейпов или анимация отсутствует совсем.

Вибрация камеры (Camera Shake)

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

«Расчлененка» (Dismemberment Gore System, отрывы конечностей, разрыв тела)

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

1. Персонаж должен иметь менее определенного количества очков здоровья (health points).

2. Он должен получить урон из определенного вида оружия.

3. Выстрел из этого оружия должен быть произведен в определенную область персонажа.

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

К дефектам здесь можно отнести неестественный отрыв конечности, оставлением на месте одной или нескольких частей модели при «взрыве» тела, отсутствие спецэффектов.

Переходы между анимациями

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

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

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

Дефекты, связанные с аппаратной частью

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

Разрыв экрана (Screen Tearing) – прямо не относится к проблеме графики, поскольку связан больше с аппаратной частью. Однако этот дефект имеет четкое визуальное воплощение – искажения в изображении сцены. Дело в том, что у каждого монитора есть такой показатель, как частота обновления экрана (характеристика, обозначающая количество возможных изменений изображения в секунду: 60 Гц, 144 Гц, 165 Гц, 240 Гц и т. д.). Если же видеокарта отправляет на монитор больше кадров, чем тот может отобразить, то кадры накладываются друг на друга, и получается «разрыв». В играх используется технология V-Sync, которая искусственно понижает FPS в игре, чтобы частота кадров в игре и частота обновления монитора совпадали.

Неверный уровень детализации (Level of Detail) – на игровой сцене могут одновременно находиться много объектов, находящихся на разном «расстоянии» от камеры (для имитации перспективы). Для снижения нагрузки на аппаратную часть игровой платформы при разработке применяется технология, которая использует модели с разным уровнем детализации. Очевидно, что в играх нет необходимости воспроизводить каждый кирпич на стене удаленного объекта, если глаз все равно не в состоянии его различить. К тому же обработка данных о нескольких сотнях тысяч невидимых полигонов загрузит процессор бесполезной работой.

Поэтому при создании нового игрового объекта создается несколько вариантов моделей с упрощенной геометрией (низкополигональные модели). Так что для отображения одного и того же объекта используются разные модели с разным качеством прорисовки в зависимости от расстояния объекта до камеры. Это, во-первых, помогает «разгрузить» вычислительные мощности платформы, а во-вторых, имитирует человеческое зрение: мы не можем разглядеть много деталей на большом расстоянии. Поэтому на большом расстоянии используется модель для изображения лишь силуэта.

Модели с разным LoD для использования на разном «расстоянии» от камеры

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

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

Пример использования LoD. Half-Life © Valve, 1998

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

Фантомная графика (Ghosting) – это не дефект игры, а явление, при котором на экране отображается несколько смещенных изображений объекта. Это происходит, когда предыдущее изображение продолжает появляться на экране вместе с последним даже при переходе к следующему кадру, что дает размытый, «призрачный» эффект. Причины такой фантомной графики – частота обновления экрана и время отклика. Частота обновления экрана – это скорость, с которой твой монитор обновляет изображение на дисплее, а время отклика – время, которое требуется процессору на вывод на дисплей нового изображения поверх старого. Слишком короткое время отклика не позволяет быстро сменить предыдущее изображение на текущее. Повторим: это не дефект игры, но ты можешь рассматривать его как некоторый дефект аппаратной части, который требует устранения. Особенно это актуально для динамичных игр, в которых нужны быстрая реакция и высокая скорость движения.

Мерцание (Flickering) – часто встречающийся термин при описании бага. Обычно имеется в виду то, что объект (текстура, частицы и др.) мерцает, мигает, пропадает и появляется с определенной периодичностью. Мерцание также может быть связано с настройками времени отклика.

Некоторые графические баги могут быть связаны с проблемами клиппинга, или обрезки. Клиппинг (Clipping) – это метод обработки и оптимизации изображения так, чтобы не рендерить части изображения, находящиеся вне пределов видимости пользователя. Это помогает существенно экономить вычислительные ресурсы видеокарты. Представь себе луч фонаря в темноте. Ты видишь только то, что попадает в зону луча; все остальное остается невидимым. Зона или, вернее, объем видимости обычно имеет вид усеченной четырехугольной пирамиды (фрустум) с виртуальной камерой в вершине, то есть ограничен шестью плоскостями. Плоскости, перпендикулярные камере, называются Near Plane (ближняя плоскость, NP) и Far Plane (FP, дальняя плоскость). Таким образом, объекты, не попадающие в указанный объем, не будут учитываться при рендеринге, и пользователь их не увидит. Точнее, не должен видеть.

Область видимости определяется шестью плоскостями отсечения. Объекты Б и В находятся вне объема видимости и будут отсечены при рендере

Дефектом клиппинга называют ситуацию, когда вместо ожидаемой невидимости объекта (например, когда он не входит в область видимости или блокируется другим непрозрачным дефектом) он становится видимым. Яркий пример такой ситуации – иллюстрация ниже.

Кроме того, для оптимизации вычислительных ресурсов применяются и другие методы, позволяющие отсекать те части сцены, которые пользователь видеть не должен, – например, отсечение (culling). Впрочем, часто эти понятия (clipping и culling) используют как синонимы.

Окклюзивное отсечение (Occlusion Culling) – дефекты, связанные с некорректной работой алгоритмов обрезания невидимых объектов, а точнее, отображения того, что скрыто. Например, если мы видим два непрозрачных объекта, один из которых частично находится позади другого, то часть этого объекта нам не будет видна. В игре эта часть объекта должна быть исключена из процесса рендеринга еще до его начала для оптимизации ресурсов. Однако из-за неправильной работы графического процессора мы начинаем видеть ту часть объекта, которая должна быть скрыта. В жизни такое произойти не может. В компьютерной игре – запросто!

Сшивка (Z-Fighting, Stitching) – дефект рендеринга, при котором два примитива начинают попеременно перекрывать друг друга, вызывая мерцание на экране. Это происходит из-за того, что они оба находятся так «близко» к камере, что графический процессор не понимает, что он должен отобразить в конкретном пикселе на экране и какую информацию необходимо взять из Z-буфера, который отвечает за «глубину»; координаты примитивов очень близки или совпадают. При изменении сцены (например, когда игрок чуть отходит и снова приближается к этому месту) дефект проявляет себя как мерцание, графические шумы, потому что один из двух примитивов попеременно «выигрывает» борьбу, и его данные используются для окрашивания пикселей экрана.

Z-fighting во всей красе

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

Дефекты, связанные с «человеческим фактором»

Отсутствующие текстуры (Missing Textures) – дефект проявляется в том, что на месте отсутствующих текстур появляются «заглушки». То есть в программном коде содержится информация о текстурах и их местонахождении, тогда как самих текстур в этом месте нет или графический процессор не может достаточно быстро подгрузить их из места хранения и вывести на экран. Однако бывают ситуации, когда разработчики просто забыли заменить временные текстуры или не положили их в нужную папку.

Визуальные артефакты и графические «глюки» (Visual Artifacts and Graphical Glitches) – если честно, то это дефекты, которые я не могу отнести в вышеперечисленные группы. Иногда даже бывает сложно понять причину появления таких багов. «Глюки», как правило, связаны непосредственно с нестабильной работой графического процессора, его драйверов и др. К таким дефектам можно отнести «блуждающие пиксели» – артефакты, возникающие вокруг объектов и пропадающие при смене угла зрения.

4.2.4. Тестирование визуальных эффектов (VFX)

Визуальные эффекты традиционно разделяют на:

1. геймплейные эффекты: визуализация магии, эффекты оружия, взрывы, разрушения и т. д.;

2. природные эффекты или эффекты окружений: водопады, туман, дождь, снег и т. д.

Чтобы ориентироваться в теме визуальных эффектов, тестировщику можно воспользоваться знанием принципов их создания.

1. Правило трех форм

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

Примеры визуальных эффектов, которые основаны на использовании трех форм

2. Правило трех цветов

Согласно этому правилу, эффект будет нескучным и произведет на зрителя впечатление, если специалист по спецэффектам будет соблюдать правило 70:30. То есть отношение основного цвета к вторичному и третичному вместе будет 70 к 30, а отношение вторичного к третичному – тоже 70 к 30.

3. Правило трех значений контрастности

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

4. Принципы анимации

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

5. Вторичная и третичная анимация

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

Сравни эти взрывы. Какой тебе кажется эффектнее?

6. Время эффекта

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

7. Физические законы

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

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

Для примера разберем эффект, который называется Muzzle Flash (Вспышка выстрела).

Можно выделить примерные этапы данного эффекта.

• Начальное свечение дула – происходит непосредственно перед тем, как пуля покидает ствол оружия. Создается сильно разогретым газом, выталкивающим пулю из ствола.

• Основная вспышка – происходит в момент вылета пули и смеси разогретых газов из ствола оружия. Вспышка имеет разные цвет, форму и интенсивность.

• Искры – создаются несгоревшей частью пороха, вылетающего из дула, после выстрела.

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

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

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

Пример слишком высокой плотности «тумана»

4.2.5. Тестирование освещения, отражений и теней

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

Свет может быть искусственным и естественным, может иметь направление, отражаться, преломляться и иметь разную интенсивность.

К дефектам освещения традиционно относят баги, связанные с неправильным использованием источников света на сцене, имитацией оптических эффектов и тенями от объектов. Освещение сцен – это довольно трудоемкий процесс, за который отвечает художник по освещению. На сцене могут быть размещены довольно сложные объекты из материалов, по-разному преломляющих и отражающих свет. Создание реалистичного освещения сопряжено с использованием больших вычислительных мощностей графического адаптера. Поэтому задача художника по освещению – использовать методы и подходы, позволяющие снизить нагрузку на аппаратную часть игровой платформы. Например, тени от стационарных объектов на сцене (здания, деревья, стоящие автомобили, конструкции и т. д.) фиксируются на отражающей поверхности («запекаются» на сцене). Но затем источник света может быть передвинут, а тени остаются на прежнем месте. Когда на сцене появляется динамический объект (например, персонаж, параметры тени которого строятся «на лету» в зависимости от источников освещения), мы начинаем замечать, что тени от разных объектов на сцене выглядят по-разному и иногда даже направлены в разные стороны, как будто на сцене используется несколько разных источников света. Наглядно это видно на изображениях ниже.

Реалистичное отражение на разных отражающих поверхностях – довольно сложный процесс. Для его реализации разработчики используют различные технологии: от «зеркальных» уровней и виртуальных камер (planar reflections) в очень старых играх до кубических текстур (cubemaps) и трассировки лучей (ray tracing) в современных проектах. В дальнейшем появятся и другие технологии для решения таких задач.

То, что игрок видит в зеркалах, – «виртуальные камеры» для имитации отражения

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

Кубические текстуры или кубическая карта (Cubemaps) – это методология создания отражений объектов на отражающей поверхности путем отображения координаты текстуры в трехмерном пространстве в тексель[30] (то есть получения изображения пикселя на экране, которое имеет свой цвет и другие характеристики и является отражением какого-то объекта на отражающей поверхности). Для этого используется развертка шести граней куба (подобная UV-развертке, о которой говорилось выше), на каждой из сторон которого заранее «запечена» текстура.

Пример кубической карты

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

Текстурная выборка из кубической карты с вектором направления «зрения» из центра куба

Преимущество такой технологии – существенное снижение нагрузки на аппаратную часть платформы, потому что текстуры на гранях куба рендерятся заранее. Но это преимущество может быть и недостатком. Поскольку cubemaps используют заранее «запеченные» изображения, динамические объекты в них не отражаются. И поэтому возникают проблемы с отрисовкой игрового персонажа: иногда персонаж может подгрузиться с запозданием, а иногда, наоборот, «отраженный» игрок загружается, а окружение – нет.

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

Трассировка лучей (Raytracing) – это техника рендеринга, в основе которой лежит принцип реального физического процесса. Чтобы построить трехмерную модель какого-либо объекта и применить к ней трассировку лучей, системе нужно отследить траекторию виртуального луча к этому объекту от виртуальной камеры. При этом система учитывает материал, из которого сделан объект и свойства его поверхности. Далее свет отслеживается с помощью нескольких лучей, имитирующих отраженный свет. Трассировка лучей учитывает преломления, отражения лучей, а также корректное взаимодействие света с любыми поверхностями, в том числе и зеркальными.

Так устроен процесс построения модели с использованием трассировки лучей

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

К дефектам освещения можно отнести также нарушенную автоэкспозицию (Auto Exposure или Eye Adaptation). Представь себе, что ты выходишь из темного подвала, где провел полдня, на открытое ярко освещенное пространство двора. Ты непроизвольно жмуришься от обилия света до тех пор, пока глаза не адаптируются к освещению. В играх такой прием используется в аналогичных ситуациях, чтобы добавить реалистичности. Иными словами, уровень экспозиции сцены меняется, делая сцену или ее части ярче/темнее и имитируя адаптацию зрения. Это позволяет добавить реалистичности происходящему.

Еще один дефект освещения – неправильное использование или работа бликов (Lens Flare Effect). Блики используются для придания освещению сцены реалистичности и имитации очень ярких источников света.

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

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

• геометрии объектов;

• текстур;

• физических моделей;

• моделей коллизий.

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

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

• форматом графических файлов;

• наличием необходимых графических файлов в соответствующих каталогах;

• целостностью этих файлов;

• соответствием модели требованиям игрового движка с точки зрения ограничений на количество полигонов;

• другими техническими аспектами, например с проверкой дистанций для переключения моделей (LoD).

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

4.2.6. Тестирование звука

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

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

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

1. Сигнал. Определенный звук сигнализирует о нехватке ресурсов, захвате базы врагами, удачном выстреле и т. д.

2. Ориентация в пространстве. Такие звуки помогают игроку понять, находится ли он в закрытом помещении или на открытой местности.

3. Ориентация на местности. Игрок использует звуки для ориентации в пространстве, например, когда передвигается в различных средах: по воде, песку, снегу и т. д.

4. Оповещение. Звуки используются для сообщения о событиях, которые визуально не воплощаются на экране: например, игрок достигает определенного уровня.

5. Атмосфера. Это звуки окружения для усиления погружения в игровой процесс: звуки города, фермы, боевых действий и т. д.

6. Усиление эффекта. Звуки используются для акцента на игровом событии. Например, после взрыва гранаты игрок может слышать писк или приглушенные звуки для имитации контузии и снижения слуха.

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

Одни и те же звуки могут выполнять различные функции. Например, звуки, которые выполняют сигнальную функцию и функцию оповещения, могут использоваться и для создания определенной атмосферы в игре (вспомни «Killing Spree! – Rampage! – Dominating! – Unstoppable! – GODLIKE!» в Unreal Tournament).

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

• Фоновая музыка

• Звуки интерфейса

• Звуки окружения

• Звуки персонажей

• Звуковые эффекты

• Голосовая озвучка персонажей

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

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

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

Звуки персонажей (Foley) – это все звуки, производимые персонажами, за исключением речи. Это могут быть звуки шагов, открывающихся дверей, звон ключей в связке и проч., то есть все те звуки, которые придают игре больше реализма. Эта группа звуков, как и профессия человека, занимающегося их производством (Foley artist), была названа в честь Джека Донована Фоули – одного из первопроходцев в области звуковых эффектов для кинематографа.

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

Голосовая озвучка персонажей (Voiceover) может быть записана для игровых и неигровых персонажей для увеличения звукового разнообразия. При этом у нее есть некоторые особенности.

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

2. Персонажи могут не быть озвучены вовсе, и это не повлияет на атмосферу игры. Например, главный персонаж в Quake или Half-Life не произносит ни единого слова за всю игру, а в The Legend of Zelda: Breath of the Wild не озвучен ни один NPC (non-player character).

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

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

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

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

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

1. Отсутствие звука

2. Проигрывание неправильного звука

3. Неправильное проигрывание звука

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

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

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

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

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

Далее в рамках контентно-аудиального тестирования, самого масштабного этапа тестирования звука, тестировщик проверяет следующее.

1. Наличие звука у конкретного игрового события.

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

• Стоя у водопада, игрок не слышит звука падающей воды.

2. Соответствие созданных звуков объекту, игровой ситуации и сеттингу игры (при условии, если это не гениальная задумка гейм-дизайнера).

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

• Эффекты накладываемых магических заклинаний будут звучать неуместно в игре про Вторую мировую войну.

• При взрыве ручной гранаты игроки слышат звук, напоминающий звук разрывающейся авиабомбы.

• Персонаж передвигается по песку, а звук такой, будто он идет по луже.

3. Отсутствие неуместных звуковых включений и артефактов в звук события.

• К звуку взрывов примешаны голоса людей, которых нет в сцене.

• В звуке отсутствуют посторонние вкрапления: щелчки, стуки и т. д.

4. Отсутствие раздражающих игроков звуков (вроде звука трения пенопласта по стеклу).

5. Громкость созданных аудиофайлов.

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

6. Неправильное позиционирование звука в зависимости от его источника.

• Кузнец кует оружие в кузнице рядом с таверной, непрерывно ударяя молотом по куску металла. Однако игрок слышит этот звук из угла своей комнаты.

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

7. Неправильно настроена зона звукового покрытия.

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

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

8. Соответствие записанных актерами реплик персонажей игровому сеттингу и ожиданиям игроков.

• Голос актера не соответствует полу и возрасту персонажа.

• Голосовые характеристики актера озвучки не соответствуют ожиданиям игроков. Например, персонаж из страны Ближнего Востока говорит с выраженным ирландским акцентом.

9. Соответствие звуков звукам реальных прототипов (историческая достоверность).

• Голос исторического персонажа, известного публике, звучит совершенно не похоже на прототип.

• Звук граммофона звучит как звук современной аудиосистемы.

10. Сочетание всех звуков, включая музыку.

• Фоновая музыка заглушает важные для игрового процесса звуки.

11. Зацикливание, искажение, пропадание, задержки, прерывания.

• Игроки слышат, как звук начинает трещать или шипеть.

• При выстреле из орудия звук воспроизводится дважды.

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

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

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

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

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

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

• В игре можно включать и выключать звуки и/или музыку.

• Можно изменить громкость.

• Все аудиофайлы названы с соблюдением единого формата и распределены по каталогам в проекте.

• На игровой карте правильно расставлены источники звука и звуковые зоны.

• Звуки совместимы на разных аудиосистемах: наушники, колонки, мониторные колонки, 5.1, 7.1, домашний кинотеатр и другие используемые системы и технологии.

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

Критерии оценки звуковой картины, которые должны учитываться тестировщиком:

• созданное звуковое сопровождение не уменьшает количество FPS озвучиваемой сцены;

• созданное звуковое сопровождение не является причиной утечек памяти[32];

• установленные при разработке игры лимиты по звукам соблюдены (например, лимит на количество одновременно проигрываемых звуков);

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

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

4.2.7. Тестирование искусственного интеллекта (ИИ) персонажей

На словах «искусственный интеллект» в голове чаще всего всплывает образ некоего андроида или суперкомпьютера гораздо умнее и быстрее человека. Однако в играх все пока зашло не так далеко. То, что в играх называют искусственным интеллектом, – довольно сложный алгоритм действий, который создан так, чтобы имитировать поведение человека-противника.

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

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

Для сбора информации компьютерные персонажи, как и в реальной жизни, используют органы чувств: зрение, слух, реже обоняние. Конечно, игровой персонаж не может «видеть» в общепринятом смысле, поэтому для имитации «зрения» используются виртуальные рецепторы – зоны видимости, от примитивных конусов до комплексных сенсоров. Часто такие сенсоры позволяют персонажам «почувствовать», что кто-то находится у них за спиной. В еще более сложных алгоритмах может использоваться технология рейкастинга (похоже на рейтрейсинг, о котором я упоминал выше): из «глаз» персонажа исходят лучи и, если они пересекают несколько частей тела главного персонажа, противник поднимает тревогу или совершает иные действия.

Похожим образом устроены другие «органы чувств» – слух и обоняние.

Тело главного персонажа разделено на 8 частей. Если лучи, исходящие из «глаз» противника, пересекают две и более из них, то противник «видит» персонажа даже за укрытием. Tom Clancy’s Splinter Cell: Blacklist © 2013, Ubisoft

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

В старых играх ИИ представлен довольно примитивными алгоритмами, типа предопределенного набора правил (rule-based AI), как в Pac-Man. В более современных продуктах для принятия решений и совершения действий используются более сложные архитектуры и их модификации:

• конечный автомат (Finite State Machine, FSM);

• поведенческое дерево (дерево принятия решений, Behavioral Tree);

• различные миксы этих архитектур (например, иерархические конечные автоматы);

• служебный ИИ (Utility AI).

ИИ в Pac-Man был основан на простейшем алгоритме: один противник всегда поворачивал влево, второй – только вправо, третий – в обе стороны, и только четвертый преследовал игрока. Pac-Man © 1980, Nintendo

Конечный автомат – довольно простая архитектура игрового ИИ. Основной его элемент – состояние, то есть конкретное действие (или набор действий), которое персонаж выполняет в данный момент. Поведение персонажа определяется логикой определения действий и смены (или сохранения) состояния. При этом логика может быть простой или усложняться. На схеме ниже приведен пример логики поведения персонажа-охранника, патрулирующего местность.

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

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

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

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

Архитектура поведенческого дерева с использованием алгоритма Монте-Карло, когда ИИ выбирает наиболее подходящее состояние в текущей ситуации, исследуя разные ветки дерева

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

Когда персонаж, основная задача которого – патрулирование на автомобиле, теряет этот автомобиль (например, его уничтожает игрок) и после потери игрока из вида должен вернуться к патрулированию, он может «зависнуть», не найдя средство передвижения. Дерево поведения позволяет персонажу выбрать свое новое состояние и перейти на пешее патрулирование без всяких проблем. Это дает более плавный и более реалистичный переход между разными состояниями персонажа.

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

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

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

Один из способов динамического принятия тактических решений персонажами – система подсчета очков при оценке выгодности действий. Она позволяет ИИ совершать обдуманные тактические маневры без досконального знания игрового мира, выявляет доступные для ИИ действия и начисляет им очки в зависимости от складывающихся обстоятельств, тем самым выбирая наиболее выгодное. На этих принципах работает архитектура служебного ИИ (Utility AI). Другими словами, ИИ принимает решение о совершении какого-либо действия на основании того, насколько такое действие «выгодно» по сравнению с другими вариантами в текущей ситуации, то есть совершает действие, которое оценено в наибольшее количество очков.

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

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

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

Для обозначения пути, по которому может перемещаться персонаж, используются навигационные сетки (Navigation Meshes, NavMeshes). Это некоторая структура данных, которая описывает поверхности игрового мира так, что позволяет персонажу находить путь из одного места в игровом мире в другое (Pathfinding).

Ошибка с NavMesh приводит к тому, что персонаж не сможет перейти через «разрыв»

Таким образом, можно говорить о двух приоритетных типах дефектов, связанных с ИИ в играх.

1. Неправильное взаимодействие персонажа с ИИ с игровыми объектами и игроком. Как правило, эти баги связаны с неправильными настройками алгоритмов ИИ. Например, ваш помощник перестает помогать вам, враги не нападают на вашего персонажа и т. д.

2. Отсутствие движения персонажа, «застревания» во время движения. Нарушен pathfinding вследствие некорректной навигационной сетки или объектов, блокирующих передвижение персонажа по NavMesh. Персонаж с ИИ не может продолжить движение и застывает на месте или продолжает «идти» в невидимую стену.

На скриншотах ниже представлены примеры таких дефектов.

Задача тестировщика при проверке работы искусственного интеллекта – смоделировать возможные ситуации в виде тест-кейсов для проверки логичности и реалистичности поведения ИИ в них.

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

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

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

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

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

4.2.8. Тестирование игровой физики

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

У игровой физики много задач, но самая главная – сделать игру интуитивно понятной и увлекательной. Когда объекты ведут себя непонятно, пользователь не понимает правила игры.

При этом мы, как тестировщики, должны понимать, что строгое соблюдение физических законов в игре очень часто не требуется, а иногда может убить все веселье. Только представь Need for Speed, в которой реализованы реальные законы физики. Любое столкновение на трассе каждый раз будет приводить к фатальному результату, и в игру невозможно будет играть. Если бы Марио подчинялся реальным физическим законам, то он никогда бы не прошел даже первый уровень, потому что в реальном мире (кроме индийского кино, конечно) не бывает «двойного» прыжка. А если бы в снайперском симуляторе игроку пришлось бы учитывать скорость и направление ветра, скорость движения цели, освещение, угол выстрела и другие факторы, то игра бы усложнилась многократно и нашла гораздо меньше поклонников.

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

1. Дефекты разрушений

2. Дефекты поведения объектов

В играх физика делится на две категории: физика твердого тела и мягкого тела. Физика мягкого тела описывает силы, которые воздействуют на объект и тем изменяют его форму (например, флаг, вода или одежда персонажа; по сути, к этой категории можно отнести все элементы, которые могут деформироваться при воздействии внешних сил).

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

В некоторых случаях, например в реализации «физики женской груди» (breast physics, jiggle physics), по факту являющейся мягким телом, могут использоваться технологии физики твердых тел.

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

Реализация физики груди с помощью дополнительных костей и суставов

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

В других случаях «кости» груди женского персонажа снабжены «пружинами», которые заставляют грудь подпрыгивать, когда движется остальная часть скелета. Установка и прочность этих пружин определяет силу «отскока» груди. Однако именно из-за применения этой технологии во многих видеоиграх движения груди кажутся неестественными или преувеличенными: технология лучше подходит для анимации твердых тел, а не мягких объектов. Но, несмотря на это, такая физика редко определяется как баг. ☺

Пружина, которая может двигаться в разных направлениях (влево-вправо, вверх-вниз), становится «основой» для анимации женской груди

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

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

И все же чаще всего под игровой физикой понимается физика твердого тела (Rigid Body Physics, RBP).

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

• силы тяжести (объект левитирует или взмывает вверх на значительную высоту);

• силы инерции (при резкой остановке быстро двигающийся тяжелый объект мгновенно останавливается);

• силы трения (тяжелый объект долго скользит по нескользкой поверхности);

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

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

Отдельно нужно упомянуть дефекты, возникающие в тех случаях, когда скорость одного объекта настолько высока, что коллизия с другим объектом (особенно небольшим) не успевает регистрироваться системой. Речь идет о различных пулях, снарядах, стрелах и т. д. (Projectile). Таких проблем можно избежать, используя технологии излучения (Raycasting) и сканирования попадания (Hitscan), которые не требуют создания физической модели снаряда. Алгоритм реализации выстрела выглядит следующим образом.

1. Определяется направление, в котором указывает ствол оружия.

2. Из ствола оружия выпускается луч на заданное расстояние.

3. Используется raycasting для определения того, пересекся ли луч с каким-либо объектом.

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

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

Основное достоинство Raycasting в том, что он быстро вычисляется и не требует дополнительной памяти или процессорного времени на создание нового физического объекта (пули).

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

Второй недостаток Hitscan – использование прямых лучей. То есть невозможно учесть погодные условия и нельзя использовать стрельбу «навесом» (например, из лука, пушки или миномета).

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

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

Эта технология заключается в том, что при выстреле из какого-либо оружия на сцене происходит событие, при котором создается новый физический объект с конкретными характеристиками массы и скорости – снаряд (Projectile). Кроме того, контакт с другими объектами ограничен областью в виде параллелепипеда, размещенного на этих объектах, – Hitbox (о них я говорил выше).

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

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

2. Можно использовать гранаты и снаряды с отложенным эффектом попадания/взрыва.

3. Использование дополнительной визуализации полета пули – Bullet time.

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

Большинство существующих игровых движков способно обрабатывать оба типа симуляций пуль – Hitscan и Projectile ballistic. Это позволяет предоставлять игрокам огромный выбор оружия. Например, в том же Halo с Assault Rifle используется Hitscan, а с Needler – баллистика снарядов.

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

Если разбирать выстрел с точки зрения физики Projectile ballistic во время тестирования, то нужно учитывать следующее.

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

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

3. Траектория перемещения снаряда должна соответствовать условиям и среде, в которой находится объект (например, стрелы и пули в воде быстро теряют скорость и поражающую способность).

4. При попадании в объект-цель снаряд обычно уничтожается, а на объекте должны появиться следы от попадания и другие последствия (об этом я говорил выше, см. «Расчлененка» и «Дефекты VFX»).

5. При попадании в определенные поверхности снаряд может изменить траекторию движения, имитируя рикошет (например, при выстреле из пистолета в гранитную плиту, стоящую под наклоном).

6. Снаряд, как любой физический объект, может быть уничтожен другим снарядом (например, попадание одной ракеты или ее осколков в другую).

7. Один снаряд при столкновении с объектом или по прошествии времени может генерировать некоторое количество других снарядов (осколков), также являющихся физическими объектами, и/или волну со свойствами снаряда, распространяющуюся на расстоянии ограниченного радиусом (граната, ядро и т. д.).

8. Снаряды могут состоять из различных материалов, в том числе жидкостей, поэтому на них по-разному влияют фундаментальные силы (например, GES Bio Rifle в Unreal Tournament).

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

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

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

Подводя итоги, можно сказать, что физика в видеоиграх считается одной из самых сложных составляющих проекта. Задача разработчиков – найти золотую середину между приемлемой нагрузкой на аппаратную часть игровой платформы и реализмом. Важно не забывать о том, что проект в первую очередь должен быть интересным для пользователей. Это определяет подход к разработке игровой физики: в каких-то случаях приходится пренебречь реализмом для того, чтобы использовать интересные игровые механики и элементы геймплея.

4.3. Нефункциональное тестирование

Предыдущая Стр. 13 из 26 Следующая