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

Пост опубликован в блогах iXBT.com, его автор не имеет отношения к редакции iXBT.com (подробнее »)
| Рассуждения | Компьютерные и мобильные игры

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

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

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

  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 лет. Из игры вырезали кучу всего, что уже было реализовано:

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

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

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

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

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

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

12 комментариев

possum
По-моему, автор статьи ломится в открытую дверь — только самый недалекий человек в багах Киберпанка обвиняет конечных исполнителей — кодеров. Ясно и ежу, что основные проблемы начинались и накапливались исключительно на верхнем звене — начиная от топ-менеджеров, дававших завышенные обязательства инвесторам и выступавшим на шоу с обещаниями «всем сестрам по серьгам», и до руководителей среднего звена, которые не умели распределять нагрузку и определять конкретные и реализуемые игровые механики. Хотя бывали случаи и обратного — как с тем же сталкером, анализ кода которого заставлял всех людей, способных «отличать инкремент от дециметра» хвататься за голову и застывать в фейспалме.
104643247200207459116@google
Возьму фразочку на вооружение))
101361947633714094603@google
Советую зайти в комментарии ютуба, таких недалёких людей море)
Я привел киберпанк как пример отсутствие прямой связи между менеджментом и разрабами и горы багов из-за переделывания игры. В случае киберпанка это наиболее явно)
104643247200207459116@google
Подписываюсь под каждым словом. Сам работаю программистом и играя в киберпанк аж чувствую фантомное жжение в пятой точке. Обидно что этот ад продолжается. Ведь фиксами багов, они умудряются порождать новые. Так, например квест Новый поворот в версии 1.04 работает нормально. В версии 1.05 в квест сломались триггеры и квест становится не проходим. В версии 1.06 они забыли проверять текущие состояния этого квеста, и соответственно не сбросили его для уже начавших. Результат: баг появившийся после фикса был вновь пофикшено, но так и не был провалидирован нормально, после чего квест все ещё нельзя пройти.
104643247200207459116@google
Если прямо коротко то в проблеме Нового поворота забавно то что, понадобился фикс для фикса и… уже фиксу фикса снова нужен фикс, т.к. работа недоделана
SanctusSusanin
Если прописан дизайн-документ, исполнители правильно сделают свою работу, а игра выйдет вовремя и без багов.

Серьёзно? Вот бы нам на работе такой волшебный некрономикон.
В реальности, конечно, написание такого дизайн-документа заняло бы всю жизнь.
В случае многострадальной Cyberpunk 2077 — игру делали 9 лет.

… и не девять, а восемь. И не выиграл, а проиграл...
Так аккумулируются слухи. Разработке игры — от силы 5 лет. 9 лет назад даже не было звука такого.
Первая громкая премьера миру состоялась наверное на ютубе, или меня поправят в комментариях.
Cyberpunk 2077 Teaser Trailer 23,786,748 views •10 Jan 2013
116058771575537146661@google
Написано было ещё что игры вырезали кучу всяких РЕАЛИЗОВАННЫХ фишек(думаю вы понимаете какие), если уж они были реализованы зачем их вырезать? Или их не было, или они даже не работали нормально. И правда: почему люди думают, что над игрой пыхтели с 2012 года во все тяжки, хотя там третий ведьмак и его дополнения были?
101361947633714094603@google
«30 мая 2012 года компанией CD Projekt было объявлено о разработке новой игры под названием Cyberpunk 2077. В анонсе было заявлено, что игра находилась в разработке уже год»
Игру фактически разрабатывали на движке 4-5 лет. Но остальные 3-4 года шла стадия подготовки, писался этот самый некрономикон, разрабатывалось виденье игры.
Написать дизайн документ вполне реально, и некоторые разработчики его пишут)
На его написание выделяется время: в случае киберпанка на это было 4 года, за это время:
-Сценаристы должны написать сценарий, диалоги, ветвление, схематичные раскадровки.
-Художники должны обрисовать персонажей, накидать стилистику. На бумаге подстроить карту города под сценарий игры
-Геймдизайнер должен прописать боевую систему, характеристики оружия, персонажей, и возможности персонажа.
Это необходимый минимум. Дизайн документ делает не один человек, а команда. Это более чем реально.
Но CDPR любит делать все на ходу)
SanctusSusanin
Хотелось обойтись малой кровью, но придётся поиграть в капитана очевидность:

Ответ 101361947633714094603@google на комментарий
Написать дизайн документ вполне реально, и некоторые разработчики его пишут)


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

Ответ 101361947633714094603@google на комментарий

-Сценаристы должны
-Художники должны
-Геймдизайнер должен


А дизайн документ пишет ровно один ответственный человек, будь то старший гейм-дизайнер или человек с другой специальной должностью (i.e, Creative Lead, называют все как хотят).

Ответ 101361947633714094603@google на комментарий
Дизайн документ делает не один человек, а команда.


Фактически писать (т.е. добавлять контент) его может сколько угодно человек, хоть вся студия, но как в Agile/Scrum ведёт (то есть отвечает головой и репутацией за полноту, структуру и непротиворечивость) его ровно один ответственный человек, см выше.
Дизайн-документ — это библия проекта, в которой описана вся игра (примерно как режиссерский сценарий для фильма). В этом документе должны быть описаны каждый диалог, задание, любая активность, характеристики, боевая система, рост и внешний вид персонажей, ролевая система и даже длина прыжка. Все должно быть описано максимально подробно, чтобы не оставалось никаких вопросов. Стадия подготовки игры в правильном проекте может занимать больше времени, чем непосредственно разработка.

Мой комментарий относился к этой части сообщения в том числе. То что вы здесь перечисляете — это типичный Waterwfall, и он не работает. Не слушайте меня, поищите в интернтах, сейчас только ленивый не высказался на эту тему.

Ответ SanctusSusanin на комментарий
Серьёзно? Вот бы нам на работе такой волшебный некрономикон.


И вот наконец, зачем вся эта предыстория — как видите, диздок никакая не защита от провала, и не гарантия успеха, как вы утверждаете.
Вам в пример Kingdom Come: Deliverance, автор которой даже в соц сетях где-то публиковал «сценарий» игры распечатанный и упакованный в коробки из под обуви. Да, это не диздок, но если вы думаете, что Вавра закончил на сценарии и умыл ручки, то конечно удачи.
К вашему удивлению это никак не повлияло на забагованность игры. Потому что диздок не исключает баги.
Ну и в общем я могу написать целую отдельную статью чисто отвечая на вот этот ваш параграф, процитированный выше.
101361947633714094603@google
Диздок пишет команда, но утверждает его один человек;
Игра это не сайт или приложение в котором можно использовать Agile. Потому что конечный результат должен быть ожидаемым, должны быть сроки разработки. Я считаю что большой творческий проект в Agile сделать просто невозможно, все скатится в производственный ад.
Возможно должна использоваться некоторая комбинация: каскады использовать только для строго неизменной структуры/скелета игры, а я всякие не меняющие скелет фишки добавлять уже по Agile: к примеру в ГТА5 город/сценарий/действующие персонажи/боевая механика Waterwfall, а дополнительные квесты/активности Agile
Для меня процесс создания игры похож на создание кинопродукции: где любые методологии разрешены только на стадии написания режиссёрского сценария, на съёмках только Waterwfall (возможны некоторые импровизации, но не влияющие на сюжет)
SanctusSusanin

Ответ 101361947633714094603@google на комментарий
Диздок пишет команда, но утверждает его один человек;


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

Ответ 101361947633714094603@google на комментарий
Игра это не сайт или приложение в котором можно использовать Agile.


Удивлю, но аджайл сейчас почти везде. В том числе он используется в производстве (софта) автомобилей. Да-да, там где за 5 лет планируют выпуск новой модели, включая цепи поставки комплектующих. А операционку и инфотэймент пишут в режиме Скрам и как-то успевают в срок ¯\_(ツ)_/¯.

Ответ 101361947633714094603@google на комментарий
должны быть сроки разработки.


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

Ответ 101361947633714094603@google на комментарий
Возможно должна использоваться некоторая комбинация: каскады использовать только для строго неизменной структуры/скелета игры, а я всякие не меняющие скелет фишки добавлять уже по Agile:


Это дико, любой процесс с вкраплениями водопада превращается в водопад, ваш кэп. По аджайлу работает команда, а не делаются фичи.
Я не понимаю, как можно в современном мире, когда с момента задумки игры, до момента реализации индустрия и мода меняется настолько сильно, что можно просто не попасть в струю; как можно топить за водопад? Аджайл помогает правильно реагировать на изменяющиеся условия, намекает на вовлечение всей команды в процесс проектирования того, что они потом будут делать.
101361947633714094603@google

Ответ SanctusSusanin на комментарий
То, что вы называете «команда» — это узкий круг широких лиц, максимум главы отделов + старший гейм-дизайнер, несколько человек, в то время как вся команда включает десятки людей. Ваш любимый водопад не любит такие вещи доверять толпе.


То что я описываю это именно команда. Утверждает один человек, работают многие
Для меня Agile это именно поэтапность и гибкость разработки. Проект может меняться во время всего процесса разработки.
Но в игровой индустрии есть нюансы:
-Нанимаются актеры озвучки которых нельзя будет выдернуть в любой момент времени переозвучить пару фраз в диалоге. Во многих проектах актеры участвуют еще и в записи моушен анимации. Что тоже накладывает ограничение на гибкость.
— Моделеры/художники начинают работать параллельно с прогерами. Прогер будет разрабатывать механики в серых коробках, моделеры просто клепать модельки, левел дизайнер собирать модельки в композицию на движке без скриптов.
Т.е вполне реально что за два года разработки у тебя в принципе не может быть на руках готового продукта. И такая разработка слабо вяжется с Agile
Я вообще не верю в методологии. То что я описываю это скорее водопад с вкраплением Agile
Идеальный проект по Agile это сталкер, с его вечной разработкой)

Добавить комментарий