Как создавалась игра Half-Life 2 (крайне длинный пост!)
Команда игры Half-Life 2 рассказала изданию Gamasutra о процессе создания тайтла и о том, как была организована его разработка. В компании применили принцип «децентрализованного дизайна» - сотрудников разбили на несколько команд, каждая из которых отвечала за отдельную область (например, звуковой или сюжетный дизайн).
В процессе создания первой части Half-life, выпущенной в ноябре 1998 года, Valve разработала новый метод децентрализованного дизайна, названный «Заговором» (подробно он описан в материале издания Gamasutra). Согласно нему группа людей из разных областей разработки собирается вместе, чтобы построить основу дизайна игры
Стоит ли говорить, что когда началась работа над Half-Life 2, нам захотелось использовать те же принципы в её разработке. Однако слишком серьёзный размах сиквела создавал некоторые трудности для применения того же метода, поэтому нам пришлось вносить в него коррективы, пока он не заработал вновь. В этой статье рассматривается новый и улучшенный Заговор, созданный специально для разработки Half-Life 2.
Крупный проект
Half-life 2 была невероятно амбициозным проектом. Ради работы над ним нам пришлось утроить размер команды и развиться в технологическом плане по всем фронтам. Актёрская игра, физика, ИИ, звук, рендер и сетевой код были перестроены с самого начала. Расширенный состав «заговорщиков» собирался месяцами, чтобы создать законченный дизайн-документ, похожий на тот, что мы создали для первой части игры.
Ранние стадии разработки продвигались очень медленно, так как было сложно предсказать, какие возможности откроют для нас новые технологии. Что ещё хуже, дизайн опирался на множество игровых элементов, которые пока что существовали только в теории. К тому моменту, как технологии движка Source, наконец, повзрослели, мы оказались в ситуации, которая с одной стороны очень напоминала «Заговор» времён разработки Half-Life, но, тем не менее, имела свои отличительные черты.
С точки зрения дизайна мы подготовились намного лучше. У нас уже была продумана основная канва сюжета, конкретные сцены и характеры героев, готовы локации и концепт-арты, и мы уже знали, какие технологии хотим видеть в игре. Но с точки зрения геймплея у нас было не так много всего: несколько оружий, идеи для крутых монстров (и не особо крутых монстров) и задумки для интересных уровней.Тем не менее, как и с первой частью, на этих этапах разработки мы старались не слишком опираться на технологии. Игру нельзя было пройти от начала до конца, уровни не были связаны в единое целое.
Но как только мы узнали, на что способен новый движок и накопили достаточно сырого материала, способного двигать разработку, «Заговор» начал работать так же эффективно, как он работал во времена создания Half-Life.
Снова в седле
В каждой группе было всего четыре или пять человек - половина level-дизайнеров, половина программистов. Во время разработки Half-Life такой размер казался нам идеальным. Команды большего размера создавали слишком пресный дизайн, а меньшего - страдали от нехватки идей. Мы объединяли в одну команду разработчиков и дизайнеров потому, что большинство изменений в дизайне требовали работы над ИИ, кодом и уровнями. Также в каждой группе «заговорщиков» работал один программист по движку, который мог бы разрабатывать новые технологии для дизайнеров.
Ради увеличения общей продуктивности мы хотели, чтобы у каждого члена команды был собственный «покупатель» в той же группе, который бы являлся прямым потребителем работы этого человека. Level-дизайнеры были такими покупателями для программистов, потому что использовали элементы геймплея и ИИ, созданные ими. А программисты, в свою очередь, были покупателями работы дизайнеров, потому что им нужны были готовые уровни, чтобы обкатывать свой код.
У каждой группы был собственный офис, в котором они все вместе работали. Таким образом им было проще общаться между собой и, как мы выяснили позже, расставлять приоритеты в разработке. Люди намного реже отвлекаются на неважные аспекты игры, когда рядом с ними сидит член команды, способный мгновенно напомнить о том, что действительно важно.
В «заговорщической» группе, создававшей первый Half-Life, были художники и писатель, тогда как в новой структуре с несколькими группами нам пришлось относиться к ним как самостоятельным ресурсам. Мы создали художественную команду, сюжетную команду и команду, ответственную за звук (в неё, по сути, входил один-единственный дизайнер по звуку).
Художественная команда сотрудничала с дизайн-командами в деле разработки внешнего вида локаций, монстров и персонажей на ранних этапах и в конце, когда геймплей стабилизировался и возникла потребность в качественной проработке уровней. Ответственная за звук команда работала вместе с группами дизайнеров в вопросах создания звукового сопровождения для первых игровых прототипов и позднее, когда дизайн стал более стабильным. Сюжетная команда работала с дизайн-командами, наполняя уровни разнообразными миссиями, целями и сюжетными ходами, и создавая анимации, требующиеся в конкретной локации. Сюжетная команда также работала над наполненными событиями локациями, вроде Лаборатории Кляйнера, Восточной Чёрной Мезы и Логова Брина, как полноценная четвёртая дизайн-команда.
Несмотря на серьёзные структурные изменения в «заговорщическом» методе, он унаследовал множество аспектов оригинала (описанных в прошлой статье), и они остались неизменны. В основном каждая команда работала, как и прежде. Мы оставались верны принципу «Те, кто работают над дизайном, реализуют его самостоятельно», потому что считали, что лучший дизайн рождается, опираясь на реалии разработки. Те, кто знают, на какие компромиссы приходится идти, чтобы достигнуть чего-то, способны принимать наилучшие решения в дизайне. Мы не позволяли возникать чувству единоличного властвования над какой-то частью игры, так как считали, что большое количество людей, ответственных за некий элемент, помогает создавать продукт более высокого качества.
Наши методы тестирования не изменились, и мы по-прежнему использовали их как способ разрешения споров. Как и с первым Half-Life, каждая группа несла полную ответственность за то, чтобы их уровни дотягивали до общих стандартов качества.
В результате у нас получилось шесть команд, и работа каждой из них: модели, материалы, звуки, анимации, освещение, история и геймдизайн, - должны были соединиться, создавая игровые уровни. Как можно догадаться, управлять эти процессом было нелегко, но без этого мы бы не смогли достигнуть успеха.
Появилось несколько вполне очевидных проблем. Как управляться с взаимосвязями между работой отдельных команд и сокращать их количество? Как сделать так, чтобы каждая команда могла вносить свои собственные ограничения в общий дизайн? Как можно создать единый дизайн и достигнуть одинакового качества уровней, когда над ними работает три независимые команды? Каждая из этих проблем решалась отдельно.
История о ключевых эпизодах
Half-Life 2 содержит более трёх часов катсцен, и запись диалогов доставила нам достаточно проблем. Нам часто приходилось летать в Лос-Анджелес и просить актёров выкроить немного времени в своём занятом расписании. После нескольких заранее оплаченных сеансов звукозаписи мы оставались сами по себе. В идеальной вселенной мы бы продумали всё заранее и делали бы всё по порядку в более традиционном стиле, но мы просто не знали, в какие дебри заведёт нас дизайн. И мы не могли оставить запись голосов напоследок, потому что тогда много времени было бы потрачено впустую. Геймплей и история должны были развиваться параллельно.
Они были неразрывно связаны друг с другом, и перед нами встал новый вопрос: как нам сделать так, чтобы группы, ответственные за геймплей, чья работа всегда текла в непредсказуемых направлениях, имели достаточно свободы, и при этом сюжетной группе было на что опереться при продумывании истории? В конечном итоге мы решили, что будут определены ключевые эпизоды, служащие рамками, за которые геймплей не мог бы выходить.
Например, при создании глав «Через каналы» и «Опасная вода», мы решили, что игрок начнёт побег из Сити 17, стартуя от Лаборатории Кляйнера и заканчивая свой путь в Восточной Чёрной Мезе, вдалеке от города. Элементы истории, оказавшиеся между этими ключевыми эпизодами, специально оставались размытыми и нечёткими, чтобы позволить геймплею идти тем путём, каким ему захочется. Дизайн-команды были свободны направлять его в любую сторону, которая только покажется им интересной и многообещающей, если они не выходили за заданные рамки.
Как только работа над геймплеем эпизода подходила к концу, соответствующая дизайн-группа и сюжетная группа собирались вместе и создавали список мест в эпизоде, куда стоило бы добавить сюжетные элементы. Каких-то требовал геймплей - например, выдача игроку промежуточных миссий или объяснения некой игровой механики. Другие были важны для сюжета или мотивации игрока на определённые действия (как, например, напоминание о том, что в эпизоде «Через каналы» игрок должен добраться до лаборатории Илая). Наконец, были и сюжетные стимулы, созданные ради обогащения игрового опыта.
Но даже со всем этим история должна была оставаться достаточно гибкой, чтобы удовлетворять неожиданным геймплейным требованиям. Например, изначально игрок должен был посетить Рейвенхольм до попадания в Восточную Чёрную Мезу, а не после неё. Однако его пришлось передвинуть, когда стало ясно, насколько огромным потенциалом для улучшения эпизода про Рейвенхольм обладает грави-пушка.
Художественная часть
С точки зрения работы художников Half-Life 2 была намного тяжелее первой части. В Half-Life 2 использовалось 3 500 моделей, 10 000 материалов, и отдельных карт на 20 МБ (для сравнения, в Half-Life было использовано 300 моделей, 4 000 материалов и 3 МБ карт). Мы сильно вложились в визуальную составляющую. Чтобы создать такое количество материала с помощью небольшой команды художников, нам пришлось оптимизировать производственный процесс и максимально оградить его от возможных изменений в геймплее.
Создание художественной части для эпизода начиналось с простых зарисовок на самых ранних стадиях процесса сразу, как появлялось представление об общем внешнем виде локации. Более того, иногда концепты появлялись даже раньше, когда сама идея ещё даже не была чётко прописана, для того, чтобы вдохновлять дизайн-команду.
После того, как геймплей и концепты становились более или менее совместимыми, концепты перерабатывались в шаблоны - пустые карты без геймплея, служившие шаблонами для создания итоговых локаций. Шаблоны влияли на геймплей, и геймплей, над которым велась работа в то же время, влиял на изменения в шаблонах. Например, характеристики управляемости Внедорожника влияли на масштабирование карты побережья, и наоборот.
Мистер Оранжевый
Работа над главой начиналась на оранжевых картах. Оранжевые карты использовали текстуру оранжевой сетки для стен и серой - для пола и потолка, и этот метод помогал решать множество возникающих то тут, то там проблем на ранних этапах.
Во-первых, благодаря этому художникам не приходилось работать над тем, что могло не попасть в игру после тестирования. Использование этой тактики позволило значительно снизить затраты на каждой стадии, а также избежать лишней работы над внешним видом локации. Кроме того, нам удалось избежать преждевременной критики художественной части тогда, когда в первую очередь было нужно критиковать геймплей. Это дало художественной команде огромную возможность экспериментировать с различными визуальными стилями, ведь они могли работать независимо от того, какие изменения происходили с геймплеем.
Успешные игровые прототипы и шаблоны использовались в качестве фундамента для создания итоговых уровней. Как только уровень успешно преодолевал тестирование, его отдавали художественной команде. На этом этапе команда заменяла все временные модели на уровне на итоговые. Освещение подправлялось или создавалось с самого начала, добавлялись материалы и вспомогательные элементы вроде огня, тумана, неба и прочего.
В это время работающие уровни становились всё более похожими на изначальные концепты, и это никак не влияло на геймплей. И всё-таки иногда геймплей совершенно случайно ломался в неожиданных местах. Например, однажды тестировщик не смог пройти по длинному подвесному мосту, когда базовую, более короткую модель заменили на реалистичную и качественно оформленную. Из-за подобных зависимостей между визуальным дизайном и игровой механикой художественные команды проводили собственные тесты каждый раз после работы над уровнем, чтобы удостовериться, что геймплей ощущается так же, как и раньше.
Символические ссылки
Чтобы каждая команда могла работать над одним и тем же уровнем одновременно, не вызывая простоев, нам приходилось как можно более чётко структурировать инструментарий в каждом отдельном файле. Файлы были связаны с помощью символических ссылок. Символическая ссылка - это легко читаемая человеком сноска, используемая и с точки зрения кода, и с точки зрения контента, которая обращалась к другому куску кода или контента.
Например, внутри игровых локаций мы заменили прямые ссылки на звуковые файлы ссылками на записи в файлах сценария. Каждая запись в файле сценария определяла такие переменные, как высота, громкость звука и случайную выборку файлов для звука. В результате звуковые дизайнеры могли заменять и изменять звуки, не мешая дизайнерам уровней. До введения символических ссылок level-дизайнерам приходилось каждый раз передавать локацию дизайнерам по звуку и не трогать её до завершения работы над звуком. Также, благодаря тому, что каждый звуковой файл имел имя, определяющее, к какой локации он относился, дизайнер по звуку мог работать с файлами на одной карте, не вмешиваясь звуковое сопровождение других локаций.
В катсценах были символические ссылки, указывающие на то, куда актёр пойдёт и куда посмотрит. Один человек мог работать над лицевыми анимациями, последовательностями анимаций и порядком событий в сцене, пока кто-то другой работал над геометрией мира. Эта же технология была использована для работы над диалогами горожан, что позволяло сценаристу проводить множество итераций.
Это всего лишь пара примеров, но мы использовались символические ссылки чуть ли не везде, где было возможно. Центральной стратегией было увеличение количества итераций на каждого специалиста при снижении затрат на каждую итерацию, потому что мы верили, что большее число итераций благотворно влияло на качество продукта. Меньшие затраты на каждую итерацию также снижали плату за экспериментирование. Мы могли вносить изменения в игру даже тогда, когда она приближалась к релизу, потому что различные элементы жили независимо друг от друга.
Общее постоянство
Мы создавали дизайн каждой главы, основываясь на нескольких основных принципах: одни были унаследованы от первой части Half-life, другие были придуманы для новой игры. Нам хотелось развить эти принципы, не потеряв то хорошее, что уже в них было. Нашей основной целью было создание увлекательной игры от первого лица, поэтому мы определили несколько конкретных принципов, от которых нам бы не хотелось отклоняться.
Несмотря на то, что каждая дизайн-команда следовала одним и тем же мета-принципам, непостоянство в общем дизайне было очевидным последствием нашей мультикомандной структуры. Стиль каждой группы отражал слабые и сильные стороны отдельных членов группы, поэтому каждая команда создавала различные механики и принимала собственные решения, например, об общем уровне сложности, плотности событий, соотношении сражений и загадок.
Наш инструментарий был настолько широк, что каждой команде приходилось выбирать из него то, с чем им было удобнее работать. В одной команде был специалист по рендеру, в другой - по ИИ. Одни level-дизайнеры хорошо прорабатывали сражения, другие были невероятно хороши в оптимизации графической составляющей. Кто-то лучше работал с местностью, кто-то - с отдельными объектами. Итак, как же нам удалось удержать игру в общей колее, когда между командами было столько различий?
Во-первых, мы старались сделать дизайн более экономным. Мы призывали команды чаще задавать себе вопрос: «Как может этот новый элемент повлиять на всю остальную игру?». Этот вопрос служил опорой для оценки конкретных решений. Игра ощущалась куда более связанной, ведь каждый элемент использовался не только в одном эпизоде, а во всей игре.
Мы собирали команды вместе во время тестирования, дабы представить новую механику, созданную одной командой, другим. Так команды делились друг с другом идеями, что помогало механикам распространяться по всей игре. Например, команда Рейвенхольма сделала так, чтобы грави-пушка взаимодействовала с определёнными объектами (например, циркулярными пилами). Это вдохновило команду Цитадели на создание суперграви-пушки. Энергетические шары, которыми она могла управлять, затем были использованы для открытия врат Нексуса. Позже энергетические шары были добавлены в качестве альтернативных зарядов для штурмовой винтовки Патруля.
Общекомандные тесты помогали также выявить непостоянства в других областях, таких как качество графики, боёв, загадок, и так далее. Когда одна команда замечала, что у другой что-то получается лучше, они собирались вместе, чтобы поделиться техниками и идеями.
Некоторые элементы дизайна переходили границы в работах команд (например, враги и оружия), и поэтому было очень непросто внести в них изменения, не влияя на зоны влияния других отделов. Мы решили эту проблему, создав оружейную команду, в которую вошли представители трёх дизайн-команд. Там были и опытные игроки в шутеры от первого лица, и менее серьёзные игроки. Так мы учли потребности обоих типов.
Оружейная команда разработала целую палитру разнообразных оружий со своей уникальной функциональностью, и при этом ни одна пушка не была очевидно лучше других (по крайней мере, тогда, когда нам этого не хотелось). Нужно было сделать так, чтобы оружия выдавались игроку постепенно и последовательно, не вываливая на него слишком много нового за короткий промежуток времени, и не задерживая обновления в арсенале. И новой команде это удалось. Оружейная команда также работала над тем, чтобы каждое оружие было представлено соответствующим образом, и чтобы у игрока было достаточно времени и стимула научиться им пользоваться после получения.
Ради сохранения общего постоянства мы также приняли несколько решений с точки зрения менеджмента. Геймплей-команды каждую неделю собирались на совещание с руководством, художниками и аниматорами, чтобы распространить и обсудить их личные дизайн-решения. Эти обзоры помогали командам оставаться в общем потоке с точки зрения масштабирования, графиков работы, результатов и методов.
Чтобы анализировать вклад каждой команды, мы использовали сравнительные метрики там, где это было возможно. Например, мы оценивали, сколько карт один level-дизайнер делает за неделю. Код выставлялся на всеобщее обозрение, и пока одна команда использовала его, другие могли за этим наблюдать, чтобы чему-нибудь научиться. Мы старались сделать так, чтобы команды достигали конкретных результатов, не отставая друг от друга, это повышало эффективность тестирования и оценки одними командами деятельности других. Команды решали похожие проблемы параллельно, что создавало полезное соперничество между ними. Ни одна команда не желала отставать от других, или делать менее качественные уровни, которые им бы пришлось показывать на сеансах тестирования.
Второй прогон
Ещё до начала разработки мы знали, что хотим лишний раз осмотреть всю игру как единое целое, как только она доберётся до стадии альфа-тестирования. Так мы могли оценить все принятые решения в контексте готового продукта. Сразу стало понятно, что нам пригодится этот прогон, чтобы решить накопившиеся проблемы с непостоянством, часть из которых так и осталась нерешённой со времён первых тестов. Мы потратили примерно четыре месяца, и за это время игра стала куда более качественной.
В самом начале альфы качество игры и общий темп были очень непостоянны. Переходы между главами выглядели глупо и бессмысленно, так как одна команда не могла предсказать, как другая покажет переход в начале эпизода, идущего после их собственного. Также от эпизода к эпизоду очень отличались уровни сложности. От некоторых несоответствий было легко избавиться. Скажем, переходы между главами можно было смазать. Сложнее всего было решить проблему недостаточно высокого качества на протяжении всей игры.
Чтобы дать оценку игре как целому, в начале альфа-тестирования вся команда устроила себе отдых от работы над игрой, чтобы пройти и прочувствовать её, а также обсудить свои ощущения с другими. Нужно было собрать и обработать полученную обратную связь и вынести общие решения. Поэтому мы создали команду, которую назвали «Заговор внутри заговора». В неё входило по одному сотруднику из каждой команды и несколько других человек. Каждый день, каждую неделю, они собирались вместе и прогоняли игру, осматривая и критикуя её, эпизод за эпизодом.
Целью новой команды было рассказать о своих ощущениях дизайн-командам, чтобы они знали, где необходимо подтянуть качество. Последнее слово оставалось за командами. Они сами решали, что делать с отзывами, и в какую сторону направлять ресурсы, чтобы достигнуть наилучших результатов.
«Заговор внутри заговора» фокусировал своё внимание на наиболее и наименее качественных чертах каждой главы. Качественные черты нужно было отполировать и распространить, потому что не было более простого способа повысить качество игры. Мы использовали это перекрёстное опыление, чтобы распространить наиболее популярные игровые моменты и механики, что, помимо всего прочего, помогло нам сделать дизайн более экономным и постоянным.
Некачественные черты представляли собой наиболее непонятные, раздражающие, пустынные или попросту грубо сделанные секции игры. Те эпизоды, в которых было слишком много длинных и тяжёлых боёв, разбавлялись паззлами или короткими моментами отдыха, а слишком пустые моменты заливались дополнительным контентом.
Иногда мы не могли ничего поделать, и нам приходилось вырезать из игры целые куски из-за того, что на доведение их до ума потребовалось бы слишком много времени. Эти операции были для нас ещё более болезненными, чем удаление контента на ранних стадиях, а ведь даже это давалось нам с трудом. Сколько труда пропало зря! Мы узнали, насколько полезно вовремя избавляться от лишнего груза. Мы говорили себе, что привязались к контенту сильнее, чем к нему могли бы привязаться игроки, которые увидят только итоговый результат. Нас успокаивала мысль о том, что удаление чего-то одного помогало игре в достижении более высокой планки качества.
Чем больше итераций, тем лучше
Многих удивило, как сильно игра изменилась в лучшую сторону после окончания работы над ошибками, обнаруженными на альфа-тесте. Мы потратили на это совсем немного времени. Теперь мы знаем, что ключом к успеху Half-Life 2 было большое число итераций. С тех пор мы решили использовать подобные методы во всех будущих проектах. Мы научились принимать более качественные решения.
Во время разработки первой и второй части мы узнали, что решения, принятые позже, всегда были лучше тех, что были приняты раньше. Некоторые были лучше просто потому, что мы уже увидели, что есть в игре, и чего ей не хватает, и могли решить, как с этим поступить. Работа становилась эффективнее.
Например, работа над эпизодом Цитадели началась за шесть недель до старта альфа-тестирования, и, в отличие от работы над другими эпизодами, у нас даже не было идей о том, какие элементы геймплея мы бы хотели использовать. Продумывание всех игровых элементов для главы заняло один день, а первый готовый прототип был закончен за три недели. Мы создали суперграви-пушку потому, что к тому моменту уже знали, насколько успешным элементом была грави-пушка. Разработка была невероятно эффективна потому, что разработчики уже познакомились с движком и знали, какие механики они смогли бы реализовать быстрее всего.
Конечно, принятие определённых решений под конец разработки создаёт хаос и портит график, отодвигая релиз. Мы выбрали время в качестве ограничителя. Каждый элемент игры блокировался для изменений по наступлении определённого момента.
Для примера, на стадии прототипирования дизайн-команды могли работать над новыми технологиями или изменять поведение ИИ, видоизменялись целые локации, порядок уровней и так далее. После того, как художественный отдел привёл игру в удобоваримый вид, запрещалась работа с геометрией мира и общими схемами освещения.
По окончанию альфа-тестирования основные игровые механики, внешний вид уровней, их порядок, персонажи и большинство диалогов фиксировались в том состоянии, на котором они остановились. Какие-то изменения можно было вносить только тогда, когда они не влияли на прочие аспекты игры, или влияли незначительно. Символические ссылки полностью оправдали вложенные в них старания именно на этой стадии работы. Мы могли производить достаточно крупные изменения при малых затратах.
Плоды трудов
Создание Half-Life 2 послужило бесценным опытом каждому, кто работал над игрой. Если закрыть глаза на коммерческий успех, одним из самых главных наших достижений стало то, что каждый член команды был горд за созданный продукт. Мы хотели вновь опробовать работу в таком режиме. Мы многое поняли и, хочется верить, что извлечённые при создании Half-Life 2 уроки могут быть полезны и для тех, кто будет работать над другими проектами. Вот список, как нам кажется, наиболее важных уроков:
via ЯПлакал