Геймдизайн. Рецепты успеха лучших компьютерных игр от Super Mario и Doom до Assassin’s Creed и дальше - Тайнан Сильвестр

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

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

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

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

Последствия решений

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

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

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

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

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

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

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

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

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

Низкий уровень нагрузок, связанных с процессом разработки, является одним из самых больших преимуществ небольших команд. В то время, когда я работал один над уровнями Unreal Tournament ради развлечения, четыре часа рабочего времени означали десять минут изучения своих заметок и три часа пятьдесят минут работы в редакторе уровней. Я знал о дизайне все и ни от кого не зависел. Если вы работаете над большими студийными проектами, четыре часа рабочего времени часто означают час написания спецификаций, еще один час обсуждения и два часа на саму работу в редакторе. В первом случае нагрузки, связанные с процессом разработки, занимают 4 % моего времени. Во втором – 50 %.

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