Кто виноват в багах? Изучаем, как разрабатываются игры и зачем нужен дизайн-документ

Кто виноват в багах? Изучаем, как разрабатываются игры и зачем нужен дизайн-документ

  • Рубрика записиИгры

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

Стадии разработки игры

Создание любой игры (и не только игры) состоит из двух этапов:

  1. Подготовка. На этой стадии придумывается концепция, делаются прототипы и самое главное — составляется дизайн-документ. Дизайн-документ — это библия проекта, в которой описана вся игра (примерно как режиссерский сценарий для фильма). В этом документе должны быть описаны каждый диалог, задание, любая активность, характеристики, боевая система, рост и внешний вид персонажей, ролевая система и даже длина прыжка. Все должно быть описано максимально подробно, чтобы не оставалось никаких вопросов. Стадия подготовки игры в правильном проекте может занимать больше времени, чем непосредственно разработка.
  2. Реализация. Менеджеры, изучая дизайн-документ, ставят задачи исполнителям: дизайнерам, художникам уровней, аниматорам и программистам. Исполнители параллельно начинают выполнять свои задачи: одни строят локации, другие делают боевую механику. Затем из выполненных задач, как из кирпичиков LEGO, собирается игра. На этой стадии могут проводиться так называемые «вертикальные срезы»: создается один готовый уровень и проверяется, как работает игра, вживую. И если руководитель проекта поймет, что изначально игра недееспособна, то разработчики возвращаются к стадии подготовки. Также могут вноситься небольшие правки в баланс, но никаких кардинальных изменений (удалений или добавлений механик, которых нет в дизайн-документе) производиться не должно. Если прописан дизайн-документ, исполнители правильно сделают свою работу, а игра выйдет вовремя и без багов.

Производственный ад

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

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

Именно на стадии изменения чего-либо появляются баги. К примеру, вспомним игру Darksiders, в которой есть множество платформ и головоломок. Представьте, что на стадии, когда все уровни построены, глава решает сделать прыжок короче и выше. Поменять параметры прыжка — дело десяти минут. Но главный герой теперь не будет допрыгивать до платформ, зато сможет перепрыгивать через вертикальные препятствия. Придется каждую платформу и каждое препятствие двигать вручную. И не стоит забывать про человеческий фактор: внося 1000 маленьких правок на каждом уровне, исполнитель явно что-то пропустит, забудет или поставит препятствие на какой нибудь триггер. Вариантов наделать багов при таком подходе — тысячи.

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

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

Неточно поставленная задача

Рассмотрим два варианта задачи, которую менеджер может поставить исполнителю:

  1. Реализовать прыжок главного героя. Высота и длина прыжка 1 метр. Падение в прыжке может быть управляемым, взлет должен занимать 100 миллисекунд, падение 150 миллисекунд. В верхней точке прыжка должна быть задержка 50 миллисекунд.
  2. Реализовать прыжок.

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

  • Сделай прыжок чуть быстрее и короче
  • Еще чуть быстрее и короче
  • Прыжок недостаточно динамичен
  • Прыжок должен ощущаться живее!!!

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

Гениальность Кодзимы на примере бага с лестницей

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

На практике двум разным программистам поступают отдельные задачи: 

  • Сделать взаимодействие главного героя с лестницей
  • Сделать подъем/спуск NPC по лестнице

Никому из них не поступит задача обработать вариант взаимодействия ГГ и NPС на лестнице. Потому что это не описано в дизайн-документе и не обдумано заранее. Очень повезет, если тестировщик заметит этот баг, и менеджер поставит задачу программисту «NPC блокирует ГГ на лестнице»

Программист, не имея какой либо творческой свободы, напишет условие для NPC:

ЕСЛИ (ГГ на лестнице){<br />   НЕ ТРОГАЙ ЛЕСТНИЦУ!!!<br />}<br />ЕСЛИ  ((ГГ на лестнице ) И (ТЫ на лестнице ) ){<br />   СЛЕЗАЙ С ЛЕСТНИЦЫ И НЕ МЕШАЙ ГГ!!!<br />}

Выглядит ли это нормально? Нет. Это костыль, и только Хидео Кодзима (и команда) обдумывают такие моменты и делают из костылей фишки. Я не знаю, на какой стадии разработки это было решено: возможно, это было обдумано на стадии подготовки, или Кодзима просто внимательно отсматривает багрепорты. Но я на 100% уверен, что программист получил четкую задачу «Если на лестнице NPC натыкается на главного героя, пусть NPC падает и ломает шею». И это очень круто.

Пример: Cyberpunk 2077

В случае многострадальной Cyberpunk 2077 — игру делали 9 лет. Из игры вырезали кучу всего, что уже было реализовано:

  • Бег по стенам
  • Карабкание по стенам 
  • Вид от третьего лица
  • Метро
  • Кастомизация авто
  • Обещали кучу секса и романтики (в котором важна кастомизация тела)
  • По слухам, игра успела сменить движок и полностью поменять концепцию.

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

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

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

Итоги

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

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