Гордон Фримен

Half-Life Inside: всё о вселенной Half-Life

Кабальный совет дизайнеров: «Глобальная слаженность»

Глобальная слаженность

В основу дизайна каждой главы HL2 был заложен ряд принципов. Многие из них перекочевали из HL, но были и новые. Команда хотела пойти дальше по пути Half‑Life, не забывая, однако, пройденного — того, что сделало проект популярным. Задачей-максимум было создать захватывающую игру от первого лица, поэтому мы взяли на вооружение вышеперечисленные принципы (см. правую колонку «Принципы Half‑Life»).

Несмотря на то, что каждая cabal-группа руководствовалась этими постулатами, нестыковки в дизайне были естественным следствием многокомандной структуры. Дизайн каждой группы отражал сильные и слабые места её членов — потому каждая команда создавала свои игровые механизмы и принимала собственные решения: по части сложности, по насыщенности игрового процесса, по взаимным пропорциям перестрелок и пазлов. Наш набор средств разработки был таким огромным, что девелоперы предпочитали создавать тот дизайн, для которого использовались знакомые им инструменты. В одной команде был специалист по рендерингу, в другой — по искуственному интеллекту. Кто-то превосходно проектировал боевые действия, а кто-то — оптимизировал производительность. Конёк некоторых — создание ландшафтов, прочих — моделирование предметов, а третьи обладают тонким художественным чутьём. Как же нам удалось в итоге создать связный дизайн при таком обилии несоответствий?

Мы стремились к экономному дизайну. Каждую команду мы побуждали задаться вопросом: хорошо ли дополнит этот элемент дизайна все прочие элементы? — и руководствоваться ответом в своём выборе. Это естественным образом вело к большей слаженности конечного продукта, поскольку одни и те же элементы использовались в игре повсюду.

Мы привлекали к игровому тестированию всю команду, чтобы плоды трудов одной cabal-группы увидели другие и могли применить удачные решения у себя. Например, группа создателей «Рейвенхолма» изобрела особенности взаимодействия гравитационной пушки с некоторыми объектами (вроде циркулярных лезвий). Это вдохновило творцов «Цитадели» на изобретение сверхгравитационной пушки. Энергетические шары, родившиеся из этой идеи, использовала впоследствии cabal-группа «За Фрименом!» для открытия ворот Нексуса. А ещё позднее их применили в качестве альтернативного режима огня у винтовок Альянса.

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

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

Вообще, многие наши менеджерские решения были продиктованы соображениями глобальной связности. Cabal-группы еженедельно пересматривали готовый материал совместно со смежными группами художников, аниматоров и менеджеров. Целью этих встреч было помочь командам работать со схожими масштабами, с одинаковыми планами, целями и методами. Где это было возможно, мы использовали сравнительные подсчёты («Какое количество карт за одну дизайнеро-неделю вы стремитесь сделать?») для оценки производительности групп. Код постоянно публиковался — раз одна команда с ним работала, он должен был быть доступен всем — и использовался как ещё одно средство популяризации решений. Мы всеми силами старались синхронизировать цели групп, что повысило эффективность наших игровых тестов и прочих межгрупповых механизмов взаимодействия. Таким образом, группы должны были одновременно решать схожие задачи, что привносило соревновательный элемент в их работу. К очередному игровому тесту каждая команда старалась подготовить уровень получше и не ударить в грязь лицом.

Второй проход

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

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

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

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

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

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

Итераций больше — результат лучше

Мы сами были немало удивлены, насколько возросло качество игры за сравнительно короткий период между сборкой альфы и концом второго этапа глобального тестирования. Мы склонны видеть причину успеха Half‑Life 2 в «мультипроходности» каждого этапа разработки и собираемся использовать этот механизм в дальнейшем, поскольку именно благодаря этому мы смогли значительно улучшить результат.

Во время разработки Half‑Life и Half‑Life 2 мы пришли к выводу, что решения, найденные на поздних этапах разработки, всегда превосходили те, которые были приняты вначале. Нередко это происходило в силу того, что за время работы мы попросту набирались опыта. Например, к созданию Цитадели мы приступили всего за шесть недель до альфы и, в отличие от готовых глав, ещё не решили, какой ключевой элемент геймплея положим здесь в основу. Тем не менее ключевые особенности всех уровней Цитадели были созданы за один день, а на первый этап работ ушло всего три недели. И сверхгравитационная пушка обязана своим появлением тому, что к этому моменту мы твёрдо знали, это оружие — очень удачный элемент геймплея. Разработка шла исключительно продуктивно, поскольку мы уже как следует изучили движок и знали, какие механизмы сумеем оперативно реализовать.

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

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

Плоды труда

Из разработки Half‑Life 2 вся команда почерпнула колоссальный опыт. Если не брать в расчёт коммерческий успех, самым верным знаком того, что мы сделали хороший продукт была гордость своим детищем и жажда продолжать работу. Надеемся, что многие уроки, которые мы извлекли из работы над HL2, пригодятся нам в будущем.

Вот наиболее важное из того, чему мы научились:

  • Децентрализовать разработку;
  • Принимать примерные, но основополагающие решения (по поводу оружия, сюжета, поведения монстров) в самом начале. В процессе работы возникают ограничения. Нужно минимизировать усилия, пока не достигнешь приемлемого качества, и уже затем обрабатывать результат «до блеска»;
  • Не опираться в разработке на теоретические механизмы. Сначала подтверждать дизайн экспериментально. Не нужно в самом начале заботиться о внешнем виде («оранжевые карты» сойдут), можно даже использовать устаревший движок;
  • Если на разработку отведён год, нужно постараться собрать альфу месяцев за восемь и выиграть время, чтобы как следует с ней повозиться. Собственный опыт показал нам, что каждая неделя работы после готовности альфа-версии стоила четырёх недель до неё;
  • Пусть каждый из разработчиков зависит от другого — это значительно повысит эффективность и способность к расстановке приоритетов;
  • В известной дилемме масштаба, качества и времени жертвовать масштабом, чтобы уделить больше внимания качеству;
  • Пытаться сократить простои в работе, тщательно анализируя их причины;
  • Использовать символические связи для сокращения простоев в работе и получения возможности вносить изменения на поздних этапах разработки;
  • Процессы дешёвы и недолговечны. Если процесс больше не позволяет достигать поставленных целей — нужно смело его перестраивать.
Cтраницы: 123