[Baldur’s Gate 2] Анатомия продолжения

Задача

Сделать отличное продолжение не так-то просто, как кажется на первый взгляд. Создавая Baldur's Gate 2, мы понимали, что качество игры оценят гораздо строже. Нас сравнят с другими играми на Infinity Engine, то есть нашей же Baldur’s Gate, Icewind Dale и Planescape (последние две разработаны нашим издателем Black Isle Studios с использованием лицензированного Infinity Engine).

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

В BioWare мы научились анализировать выпущенные игры, выделяя их сильные и слабые стороны. Лучшими методиками разработки продолжений стали оценка и улучшение сильных сторон оригинала. В случае с Baldur’s Gate мы постоянно ощущали давление времени, что выразилось в упрощении игровых областей и проекта в целом. Приступив к Baldur’s Gate II, мы предоставили разработчикам достаточно времени, чтобы полностью раскрыть потенциал игры. Теперь мы умеем анализировать прошлые проекты, учиться на ошибках и применять полученные знания в разработке последующих.

Успех оригинальной Baldur’s Gate поставил высокую планку качества продолжения.

Создание списка особенностей проекта

На этапе проектирования необходимо создать список особенностей проекта. Благодаря лицензии на AD&D, у нас появилась возможность добавить в игру тысячи механик, что превратилось в отдельную задачу — выбрать необходимые для игры. Её решили в два этапа: сначала BioWare совместно с Black Isle/Interplay составили перечень, что возможно и осмысленно реализовать в игровом движке, а затем спросили поклонников, что из этого добавить в продолжение. Полученный список показал ожидания игроков и помог определиться с направлением разработки. Список основных особенностей новой игры выглядел примерно так:

• Увеличение разрешения (800x600 и выше);
• поддержка трёхмерной графики и её ускорителей;
• избавление от панелей в интерфейсе;
• не останавливающие многопользовательскую игру диалоги;
• множество новых специализаций (подклассов) для каждого класса;
• ускоренное передвижение персонажей;
• возможность держать оружие в обеих руках;
• улучшенная (больше деталей и кадров) анимация персонажей;
• наличие в игре всех знаковых монстров AD&D, включая самого знакового — дракона;
• магия вплоть до девятого уровня;
• упрощённый журнал, пометки на карте;
• взаимодействие персонажей не хуже, чем в Final Fantasy;
• романы с персонажами;
• сетевые сражения между игроками;
• добрые и злые варианты подходов к ситуациям, позволяющие отыграть мировоззрение персонажа.

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

Полуорк — одна из новых рас, добавленных уже в процессе разработки.

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

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

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

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

Проектные соображения

Работая над Baldur’s Gate II, мы не собирались повторять ошибок проектирования первой игры. Поскольку среди нас появились новички, а память некоторых членов команды оставляла желать лучшего, мы составили список основных принципов разработки. Каждое подразделение составило свой набор принципов, однако самым большим оказался список правил проектирования уровней — именно в этом направлении нам предстояло работать больше всего. Ниже я приведу сокращённую версию правил, составленных для проектировщиков игры:

Основные правила проектирования

• Игрок всегда должен чувствовать, что именно ЕГО действия привели к успеху. Он должен думать, что его разумные решения и действия помогли решить головоломку или победить в сражении.
• Игрок должен ощущать влияние на игровой мир, его действия должны быть ЗНАЧИМЫМИ и иметь заметные последствия.
• При написании сюжета необходимо учитывать как добрые, так и злые варианты прохождения. Сюжетные линии должны быть размечены с указанием мировоззрения игрока.

Повествование

• У игрока всегда должна быть ясная цель. Игрок — главное действующее лицо и все события происходят вокруг него.
• Важно держать игрока в курсе действий злодея. Это можно реализовать кинематографическими сценами в переходах между игровыми областями или упоминая его/её по ходу основного сюжета.
• В сюжете должен быть по крайней мере один неожиданный поворот (можно больше). Под неожиданным поворотом подразумевается откровение, полностью меняющее взгляд игрока на происходящие события. Все сюжетные повороты происходят с участием игрока.
• Неплохо бы оставить концовку открытой, чтобы заложить фундамент продолжения или нескольких дополнений.

Окружение

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

Концептуальный рисунок храма.

Механики

• Необходимо тщательно продумать систему награждения игрока. Его нужно награждать КАК МОЖНО ЧАЩЕ. В качестве наград предлагать опыт, предметы, заклинания, новых монстров, развитие сюжета и романов, и так далее.
• Крайне важно, чтобы игрок смог изменять своего персонажа, иными словами, чувствовал персонажа своим.
• Очень важно, чтобы игровой мир реагировал на характерные черты персонажа игрока.

Сценарий

• Никаких современных ругательств, хотя некоторые, всё же, допустимы: проклятье, сука, ублюдок и так далее.
• Реплики игровых персонажей в узлах диалога не должны быть длиннее двух строк. Нарушать это правило можно лишь в ИСКЛЮЧИТЕЛЬНЫХ случаях.
• Все ответы главного персонажа должны ограничиваться одной строкой. Нет никаких причин делать их длиннее.
• Старайтесь избегать акцентов в диалогах. В некоторых случаях (Эльминстер, моряки) это допустимо, в остальных случаях от использования акцентов следует воздержаться.
• Если персонаж обращается к главному герою напрямую, это стоит выделить отдельно в целях облегчения дальнейшего программирования.
• Случайных диалогов следует избегать или, по крайней мере, не использовать их без веской причины. Обычные персонажи должны иметь несколько строк диалога, но чтобы их увидеть, необходимо поговорить с несколькими персонажами.

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

Среди ограничений можно назвать максимальный размер звукового файла или размер (область и количество кадров анимации) эффектов заклинаний.

Оглядываясь назад, я понимаю, что было бы замечательно установить эти правила с самого начала разработки, а не ближе к концу. Множество решений на ранних этапах разработки не соответствовало указанным принципам и изменить это впоследствии было нельзя. Самым заметным примером стала вторая глава. Порция основного сюжета примерно соответствовала другим главам, однако именно в ней игрок получал доступ ко всем дополнительным классовым заданиям. Это привело к тому, что вторая глава казалась значительно больше остальных, ведь на выполнение всех дополнительных заданий могло уйти около 60 часов. Мы разместили дополнительные задания так, чтобы удовлетворить каждого, но в результате начало игры оказалось излишне затянутым. Разумеется, потом это было уже не исправить и нам пришлось работать с тем, что есть.

Другой заметной проблемой оказалось соблюдение программных ограничений. Отделам проектирования и художественного оформления озвучили некоторые ограничения, которые они не должны были переступать. Среди таких ограничений: максимальный размер звукового файла, размер (область и количество кадров анимации) эффектов заклинаний, допустимый размер игровой области составлял 6х6 экранов в разрешении 640х480, количество персонажей в одной области также было ограничено. Несоблюдение этих правил в некоторых случаях привело к падению производительности, а это — к экстренной оптимизации ближе к концу производственного цикла, когда найти и исправить причину просадок уже невозможно.

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

Улучшение процесса разработки

Один из важнейших этапов проектирования любой игры — разработка визуальной части и игрового наполнения. Он представляет совокупность средств и методов, которыми пользуются художники и дизайнеры для наполнения игры. По сути, во второй части Baldur's Gate всё это организовано как и в первой. В начале разработки первой Baldur’s Gate процесс был довольно туманным и неясным, но к концу разработки стал проработаннее и точнее. Работая над дополнением Tales of the Sword Coast мы потратили ещё четыре месяца на отработку процесса наполнения игры.

Концептуальный рисунок для Baldur’s Gate II.

Процесс наполнения Baldur’s Gate II

1. Проектировщики составляют подробное описание игровой области;
2. концептуальные художники создают изометрический рисунок уровня;
3. разрабатываются модели;
4. модели размещают на карте и обтягивают текстурами;
5. улучшается детализация карт посредством размещения на ней небольших объектов (стульев, бочек и тому подобного), расставляются источники света, делаются последние штрихи;
6. материал передаётся дизайнерам, которые вырезают лишнее, настраивают освещение и высоту расположения камеры, создают карту поиска пути;
7. добавляются существа, предметы, ловушки и переключатели сценариев;
8. завершается написание сценариев;

К окончанию проекта мы обнаружили несколько слабых звеньев в этой цепи. Например, следовало подробнейшим образом описывать изменения игровых уровней во время разработки. Мы старались сохранять актуальность документации, однако с таким количеством работающих над игрой людей и её масштабом практически невозможно поддерживать абсолютную точность. Отдельные команды разработчиков не имели связи с другими или не всегда понимали, чего от них хотят — в результате в игровых областях отсутствовали некоторые элементы, а различные правила именования объектов между проектировщиками и художниками могли привести к большим проблемам в разработке игры, состоящей из сотен областей, тысяч существ и художественных элементов. Улучшение взаимодействия команд разработчиков (программистов, художников, проектировщиков, тестировщиков и прочих) стало одной из основных целей всех наших проектов. Например, разрабатывая Neverwinter Nights, мы создали особую базу данных (названную редактором событий), в которой отражались все изменения, внесённые в игровой уровень различными разработчиками — это позволило всем участникам проекта быть в курсе происходящего.

Ещё одной ошибкой в проектировании уровней Baldur’s Gate II стало недостаточное тестирование на ранних этапах разработки. Такое тестирование помогло бы внести необходимые правки в процессе разработки уровня, когда сделать это относительно просто, в отличие от этапа окончательного тестирования (который, к тому же, заметно бы упростился) отделом контроля качества. Мы приступили к тестированию уровней уже после подготовки окончательных версий больших кусков игры. В процессе разработки Baldur’s Gate II мы открыли собственный отдел контроля качества, чтобы начать тестирование как можно раньше. Значительную помощь в улучшении качества игры оказал издатель в лице Black Isle/Interplay, приславший тестировщиков за несколько месяцев до окончания работы.

Экран инвентаря Baldur’s Gate II.

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

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

Преодоление кризиса середины разработки

В разработке игры, какой бы крутой он ни была, наступает момент, когда люди начинают от неё уставать. Важно подойти к этому со всей серьёзностью. В случае Baldur’s Gate II ситуация осложнялась тем, что буквально через коридор разрабатывался другой проект под названием Neverwinter Nights, а также делались первые наброски будущей Star Wars RPG.

Стремясь разрядить обстановку, мы каждый месяц проводим особые мероприятия — ходим в кино или на барбекю. Это наш способ напомнить, что мы работаем ради удовольствия — мы работаем над играми, и это должно быть интересно! Работая над Baldur’s Gate II, мы старались поддерживать людей, особенно уставших от проекта. Одно из основных преимуществ большой студии — возможность разработки несколько проектов одновременно с переброской сотрудников между ними. Не забывайте, что если одним нравится начинать проекты, то другим нравится их завершать — стоит учитывать особенности характера сотрудников в интересах рабочего процесса.

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

Подготовка к завершению

С таким масштабным проектом как Baldur's Gate II нам не пришлось беспокоиться о вырезанных материалах. Практически все запланированные особенности проекта воплотились в жизнь, вырезать задания и персонажей мы стали лишь в процессе окончательного тестирования. И даже так на прохождение Baldur's Gate II может потребоваться более двухсот часов.

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

Мы научились оценивать время разработки и соответствующим образом строить график разработки. Качество почти всегда важнее количества. Baldur’s Gate II оказалась больше Baldur’s Gate, а качество наполнения значительно выше — но мы не понимали масштаба, пока не стало слишком поздно.

Тестирование, тестирование и ещё раз тестирование

Из-за размера Baldur’s Gate II была сущим кошмаром для тестировщиков, к тому же, по ходу разработки всё новых игровых областей мы почти не тестировали их. В Baldur’s Gate II примерно 290 заданий — некоторые небольшие (продолжительностью примерно 20 минут), другие значительно длиннее (до нескольких часов). Каждое задание необходимо проверить как в одиночном, так и в многопользовательском режимах.

В ходе тестирования мы взяли на вооружение очень качественную методику отслеживания ошибок и хода выполнения задач, с которой нас ознакомили Фергюс Уркхарт, директор Black Isle Studios, а также Крис Паркер и Дуг Эйвери, продюсеры из Black Isle (все они так или иначе помогали проекту). Мы поставили в зале тестирования и разработки несколько досок, на которых записали все задания. Рядом с каждым заданием мы прикрепили крестик. Дизайнеров и техническую поддержку мы разбили попарно (один дизайнер и один оператор техподдержки), каждая команда отвечала за тщательную проверку и отладку отдельного задания. Убедившись, что задание отлажено, они снимали крестик. Примерно за 2 недели мы смогли очистить доски от крестиков (за первый проход).

Отдельная команда (состоявшая не только из специально подготовленных людей, но и из младших программистов и проектировщиков) тестировала многопользовательский режим, помогая команде Interplay численностью около 30 человек. В процессе тестирования Baldur’s Gate II мы убедились, что ролевые игры необходимо проверять особенно тщательно.

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

Урок: начинайте тестировать игру как можно раньше! Скорее всего, к концу разработки времени на всестороннюю проверку качества игры у вас уже не останется.

Финишная прямая

Последние дни разработки Baldur’s Gate II прошли на удивление спокойно. Мы не паниковали, как это часто бывает в работе над другими проектами, но некоторое напряжение ощущалось: за три дня мы успели подготовить 21 версию окончательной сборки. После нескольких ночей интенсивной игры всей командой, мы смогли подготовить сборку, качество которой нас удовлетворило. И отправили её в печать.

Мы научились беречь энергию даже на финишной прямой, ведь она может понадобиться в любой момент.

Поддержка

Последнее, о чём мне хотелось бы рассказать, это поддержка уже вышедшей игры. Несмотря на то, что мы оказывали её и раньше, лишь после выхода Baldur’s Gate II поддержка игр стала одной из основных целей BioWare. Команде линейных продюсеров поручили оказывать её в кратчайшие сроки — иными словами, убедиться, что игроки смогут сыграть в купленную ими игру.

Мы могли бы воспользоваться обычными способами поддержки (и мы прибегали к их помощи в лице отделов поддержки пользователей наших издателей, Black Isle/Interplay и LucasArts), однако нам хотелось общаться с игроками напрямую. В конце концов, кто лучше разберётся в технических проблемах игры, как не её разработчики? В первую неделю после выхода игры мы забыли назначить ответственного за чтение форумов и просмотр электронной почты службы поддержки, поэтому основателям BioWare пришлось заниматься этим самим. Было забавно наблюдать, как люди сомневались в том, что именно мы отвечали на письма и сообщения на форумах — никто не мог поверить, что генеральные директора BioWare снизойдут до ответа простым смертным (а это были действительно мы).

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

Что было сделано правильно:

• Отлаженный движок;
• увлечённость разработчиков собственным проектом;
• будучи знакомыми с процессом разработки, ветераны прошлых проектов значительно его улучшили;
• хорошая дисциплина;
• тестирование качества в конце разработки.

С чем возникли проблемы:

• Отсутствие отлаженных связей между отдельными командами разработчиков;
• переизбыток игровых материалов (игра получилась слишком большой);
• недостаточное тестирование на ранних этапах разработки;
• подготовка озвучения и звуковых эффектов слишком затянулась;
• плохое взаимодействие с переводчиками на другие языки;
• многопользовательский режим — диалоги без остановки игры, игровые персонажи.

Заключение

В заключение мы хотели бы поблагодарить всех участвовавших в разработке Baldur’s Gate II — как непосредственных разработчиков, так и издателя в лице Black Isle Studios/Interplay. Как и любой другой масштабный проект, Baldur’s Gate II обладала достоинствами и недостатками, но в конце концов мы гордимся сделанной игрой. Мы надеемся, что прочитанное поможет вам лучше понять методики разработки и даст толчок новым идеям, которые вы примените в разработке собственных проектов. Главное помнить: чтобы получить хороший результат, придётся постараться.