Однажды я услышал в компьютерном магазине разговор, который очень меня рассмешил. Я остановился с витриной, чтобы посмотреть на десятку лучших игр для PC и подслушал следующий диалог между двумя ребятами:
«Что ты думаешь об этой Age of Empires?», — спросил первый.
Его друг ответил: «Да ну, корпоративные роботы из Microsoft просто соединили Warcraft и Civilization, чтобы стрясти немного денег».
Как всегда стремясь увеличить наши продажи, я воспользовался возможностью и рассказал этим парням о том, что AoE была продуктом не огромной корпорации, а небольшой группы талантливых людей, живущих с ними по соседству.
Для нас Age of Empires стала не только игрой эпических пропорций, это было эпическое путешествие небольшой команды, решивших превратить идею в настоящую компанию по разработке игр. В этом путешествии мы смеялись и плакали, уничтожили тонны пиццы и кофеина и многое узнали о том, как делаются игры.
Воссоздание прошлого
Очевидно, что Age of Empires изначально выглядела совсем иначе, чем конечный продукт. Несмотря на обвинения, Dawn of Man (первое название AoE) не должна была стать клоном Warcraft II. (На самом деле Warcraft II была выпущена уже тогда, когда AoE находилась в процессе разработки).
Дизайн со временем эволюционировал и улучшался. На этом пути произошло несколько важных событий. Мне кажется, что лучше всего, когда сотрудники игровой компании много играют в разные игры.
Именно такими были сотрудники Ensemble, и нам в большой степени помогала привычка программиста Тима Дина (Tim Deen) покупать почти каждую выпущенную для PC игру. Именно Тим обратил внимание остальной части Ensemble на Warcraft II. В то время обрели форму многие игровые элементы AoE, такие как управление ресурсами, построение империи и исследование технологий.
Однако мы не могли решить, что делать с боями. Warcraft II стала для нас холодным душем, она разбудила нас и показала, насколько интересными могут быть бои в реальном времени. Несколько раз в неделю наша команда оставалась на работе и играла в многопользовательский Warcraft. Такие импровизированные встречи продолжались до тех пор, пока AoE не стала более интересной, чем Warcraft.
Ещё одно важное изменение произошло примерно в середине процесса разработки, когда дизайнеры посмотрели на планы локализации AoE. Они осознали, что AoE будет продаваться в Азии, но в игре нет ни одной культуры из этого региона.
Мы созвали всеобщее собрание и решили добавить к уже созданным ранним европейским, африканским и средневосточным племенам ещё и азиатские цивилизации. Хотя такое дополнение потребовало ещё больше труда художников и дизайнеров, повышенное внимание, уделённое игре в Азии, доказало, что это стало выгодным решением.
Все эти изменения вносились потому, что дизайнеры игры не боялись прислушиваться к отзывам других сотрудников о дизайне. Мы стремились создать игру, которой будут гордиться все в Ensemble, и это не было пустыми словами. Наверно, лучшим примером такой приверженности стало Чудо света, здание которое игрок мог построить и использовать для победы в игре.
В начале 1997 года AoE отлично выглядела на фоне конкурентов, но все чувствовали, что геймплею нужно что-то большее. Мы пробовали и отбрасывали множество идей. Потом наш сетевой программист Марк Террано (Mark Terrano) придумал идею создания «Часов Судного дня», которые заставят игроков бросить всё и решать новую проблему. В AoE куча мелких идей и штрихов, придуманных художниками и программистами. Их участие в создании дизайна заметно усилило чувство причастности и гордости за работу над игрой.
По-настоящему недооценённой осталась работа дизайнера по балансировке игрового процесса. Дизайнеры потратили долгие месяцы на регулировку цен, сил, скорости и других параметров, стремясь создать игру, в которую будет интересно играть, и в которой не будет всяких «лазеек» и читов.
На этом этапе я осознал, что Тим Дин действительно самый настоящий геймерский геймер. Если в процессе разработки какая-то итерация дизайна AoE давала одному игроку преимущества над другими и делала игру одномерной, то Тим обязательно это обнаруживал.
И когда мы не верили его оценкам, он доказывал нам это, выигрывая у нас с помощью таких уловок. Большую часть времени балансировка геймплея была приоритетной задачей, и это дало результаты: AoE прожила дольше и обеспечивала более качественный геймплей, чем другие игры в жанре RTS.
Тропой мультиплеера
Поддержка мультиплеера была неотъемлемой частью дизайна с самого начала, и AoE строилась таким образом, чтобы бо́льшая часть игры не обращала внимания на различия между живыми и компьютерными игроками. Когда выпустили DirectX, выяснилось, что DirectPlay будет наилучшим выбором для реализации передачи данных между разными вариантами соединений.
Для поддержки большого количества подвижных юнитов мы использовали изменённую синхронную модель игры, в которой вся игра одновременно выполнялась на всех машинах. Машины обменивались между собой только движениями, изменениями и командами. Такой подход позволял минимизировать объем передаваемых данных.
При использовании этой модели существовала опасность возникновения состояния, при котором игра на одной машине рассинхронизируется с игрой на других машинах. Это приводило к очень трудно отслеживаемым багам в AoE.
Процесс определения скорости соединения, необходимой для передачи обновлений игры, выполнялся до завершения работы над компьютерным ИИ, и был основан на модели передачи данных, полученной от живых игроков. В результате мы сначала упустили тот факт, что компьютерные игроки могут иногда давать большое количество команд за короткий промежуток времени.
Однако мы исправили эту оплошность первым патчем. AoE лучше, чем ожидалось, проявила себя в динамической адаптации к задержкам. Смещающееся окно окладывало применение команды, поэтому все игроки успевали получать команды и для их выполнения не требовались паузы.
Проблема обработки состояния игроков, выброшенных из игры, представляла для Марка Террано серьёзное препятствие. Поскольку выход из игры предсказать невозможно, то обычно нет никакого способа узнать, что случилось. Проблема могла заключаться в игровой логике, Winsock, физическом соединении или провайдере, и возникала на стороне отправителя или получателя. Очень сложно было заставить игру правильно обрабатывать вылеты игроков и передачу состояния всегда и для всех машин.
Одним из уроков, полученных от процесса многопользовательской игры, стало то, что нужно максимально использовать инструменты тестирования обмена данными, такие как автоматизированные логи и проверка контрольных сумм. Кроме того, мы обнаружили, что простая программа симуляции передачи данных даёт большие преимущества и изолирует сетевой код от остальной части игры.
В DirectPlay тоже возникали проблемы. С трудом воспроизводимые баги, странное поведение и плохая документация ещё больше всё усложняли. Одним из самых заметных примеров была гарантированная доставка пакетов для IPX. На CGDC компания Microsoft обещала добавить эту функцию в DirectX 5 и даже включила её в бета-версию.
Однако после выпуска DirectX этой функции нигде не было. Ценой отсутствия единственного элемента стало время, которое пришлось потратить на написание собственной системы гарантированной доставки пакетов и программы-генератора плохих пакетов для её тестирования.
Раскрашиваем мир
Все двухмерные спрайты AoE начинали свою жизнь как 3D-модели. В Age of Empires было 20 МБ игровой спрайтовой графики. Даже несмотря на то, что всё было двухмерным, мы с самого начала решили, что графика в игре будет взята из трёхмерных моделей. Для создания графики мы использовали 3D Studio и 3D Studio MAX.
Поскольку 3D-рендеринг требовал много времени, каждый художник использовал по две машины. Обычно это были 200-мегагерцовые Pentium Pro с 128 МБ ОЗУ. На то время такое «железо» было мощнее, чем у наших программистов. Объекты игры создавались как 3D-модели от двух тысяч до ста тысяч полигонов. Затем все модели текстурировались, анимировались и рендерились в файл .FLC (Autodesk Animator) с фиксированной 256-цветной палитрой.
До этого этапа описанный мной процесс походит на используемый во многих других играх. Но после него художники добавили ещё один долгий процесс. Файлы .FLC передавались специалисту по 2D, который разделял анимацию по кадрам и «очищал» каждое изображение в Photoshop.
Процесс очистки заключался в выделении деталей и сглаживании углов неподходящих форм. Поскольку большинство спрайтов AoE имело на экране размер всего 20-100 пикселей, усовершенствование качества графики было важным этапом. Когда AoE показывали на E3 1997 года, художники получили множество комплиментов о своей работе от их коллег из других компаний.
Использование 3D-моделей для игровых объектов давал преимущества при работе и над другими художественными элементами: их можно было использовать в статичных фоновых сценах, появлявшихся в меню, экранах статуса и различных кинематографических вставках. Видеовставки, включая трёхминутный вступительный ролик, сами по себе были полномасштабным проектом.
256-цветная палитра (на самом деле 236-цветная) тоже представляла проблему. Палитра была выбрана и принята в самом начале проекта, ещё до создания большинства моделей и текстур. В результате оказалось, что некоторые части цветового спектра, например, коричневый для текстур дерева, имели недостаточно цветов для обеспечения высокого качества графики.
Палитру не пересматривали в процессе разработки, потому что это потребовало бы повторного рендеринга и обработки всех изображений в игре, а это слишком затратно по времени. С другой стороны, в палитре был широкий и хорошо сбалансированный диапазон цветов, придававший графике игры яркий и приветливый вид. Если бы мы делали ещё одну 8-битную игру, то сгенерировали бы палитру чуть позже в процессе разработки.
Развиваем скорость
Производительность бывает проблемой во всех играх, кроме самых примитивных. Так случилось и с AoE. Когда я пришёл в Ensemble, игра всё ещё находилась в начальной форме и сильно тормозила. Двумя самыми большими проблемами были графический движок (он тормозил) и различные процедуры обновления, приводившие к случайным паузам в игре вплоть до одной секунды.
Если мы собирались продавать игру не только владельцам мощных компьютеров, то требовалась серьёзная оптимизация. Здесь история становится личной, потому что большую часть работы над этой частью AoE делал я.
Я начал с того, что постарался разобраться в работе более ста тысяч строк кода на C++ (до конца проекта исходный код вырос до 220 тысяч строк). Потратив на изучение готового кода несколько недель, я предложил провести масштабную переработку структуры графического движка, в том числе переписать большую часть на ассемблере.
Команда разработчиков AoE спросила, можно ли увеличить частоту кадров с текущих 7-12 fps до 20 fps. Я ответил положительно. Но в душе я паниковал и надеялся, что смогу справиться с таким объёмом.
Я не мог просто взять и вырезать весь старый графический движок, иначе я помешал бы работе всех остальных, поэтому потратил следующие пять месяцев в основном на создание нового движка. В процессе мне удалось внести небольшие изменения, повысившие частоту кадров до 10-14 fps, но настоящий прорыв произошёл после одной бессонной ночи, когда я реализовал последнюю часть новой архитектуры.
К моему удивлению, бенчмарк теперь работал с частотой 55 fps. Было удивительно возвращаться в офис на следующий день и видеть, как тормозившая раньше анимация стала проигрываться очень плавно. Но моя работа заключалась не только в графическом движке.
Много времени я потратил на разбор и оптимизацию множества игровых процессов. Игра проходила в реальном времени, поэтому многие усовершенствования распределялись на несколько циклов, а не останавливали игру до своего завершения. В конце концов оптимизации оправдали себя и позволили нам увеличить разрешение по умолчанию с 640x480 до 800x600.
Из этого опыта я извлёк следующий урок: чем ближе к завершению, тем более тормозной и перегруженной может становиться игра. Часто на ранних этапах разработки движок демонстрировал высокую скорость, но игра ещё не была завершена. Потом простые тестовые уровни заменялись на сложные окончательные, добавлялся AI, интерфейс, разные функции и возможности, и производительность могла значительно снизиться. С AoE была такая же история. Перед завершением проекта, когда мы заделывали все дыры, многие из трюков для повышения производительности обменяли на новые функции.
То, что нам удалось
1. Игра была разбита на отдельные компоненты движка и игры. Примерно на середине процесса разработки у нас возникли мысли, что кодовая база в некоторых частях сильно разрослась, а каждое новое изменение и дополнение выглядело неуклюжим хаком. Ведущий программист Энджело Лоудон (Angelo Laudon) и Тим Дин за две недели разделили кодовую базу на две отдельные части: движок (Genie) и игру (Tribe).
Это преобразование оказалось очень успешным и позволило программистам AoE добиться качественного объектно-ориентированного дизайна. Мы выиграли в том, что код стало гораздо проще изменять и расширять, и это сэкономило программистам кучу времени.
2. Мы сделали игру управляемой через базу данных. Благодаря объектно-ориентированному подходу почти никакие объекты AoE не были жёстко прописаны в коде программы. Огромные таблицы информации описывали каждую из характеристик игровых объектов. Для управления игрой дизайнеры использовали систему из более чем сорока таблиц Paradox. Поэтому они могли постоянно обновлять и настраивать игру, а потом тестировать изменения без участия программистов.
3. Мы поддерживали тесный контакт и работали вместе с издателем. Не могу найти слов, чтобы выразить, насколько близкий контакт с нашим издателем, Microsoft, помог нам в разработке AoE. Благодаря тому, что они находились в цикле процесса, при возникновении проблем они помогали нам, а не мешали.
Лучшим примером такой помощи в разработке является то, как мы управляли сдвигом графика выпуска. Когда что-то занимало больше времени, чем запланировано, или возникали новые проблемы, мы быстро сообщали о задержке в Microsoft.
Благодаря чёткому пониманию того, что и почему происходит, они продолжали поддерживать нас, стремясь к созданию качественной игры, несмотря на время, которое для этого потребуется. Поэтому вместо того, чтобы паниковать и нервничать, мы оставались профессиональными и сосредоточенными.
4. Мы играли в свою игру. Этот пункт может казаться банальным, но это очень важно. В процессе разработки все сотрудники компании не только тестировали, но и играли в AoE из интереса.
Поэтому мы чётко понимали, что в игре развлекает, и что в ней находят люди. Двадцать человек стремились к тому, чтобы игровой процесс был сильным и не имел ограничений.
5. Мы добились хорошей скорости. Скорость очень важна, если вы хотите добиться широкой популярности игры. Age of Empires довольно быстро работала в игре с восемью игроками на Pentium 120 с 16 МБ ОЗУ. Сравните с Total Annihilation, которой для восьми игроков нужно было 32 МБ и не менее 200 МГц. Обеспечение такого уровня производительности требовало общих усилий. Программисты вкладывали особые усилия к тому, чтобы сохранить низкое потребление памяти, и искали узкие места, а художники урезали лишние кадры анимации, чтобы освободить память.
6. Компания уважала своих сотрудников. Должен сказать о том, как Ensemble Studios обращалась со своими сотрудниками и их семьями. Всем известно, что разработка ПО, а особенно создание игр, требует огромных жертв времени и может разрушать личные отношения.
Умное руководство Ensemble понимало это и приглашало семьи на частые совместные ужины в компании и на другие мероприятия и делало так, чтобы они чувствовали себя в офисе как дома. После напряжённых дедлайнов руководители настаивали, чтобы сотрудники брали отпуски на пару дней для встречи с семьями. Работники могли при необходимости выбирать себе гибкие графики, а семьям периодически отправляли цветы и другие знаки признательности.
Результаты этих продуманных действий были очевидными: моральный дух и лояльность в компании были выше, чем я видел за четырнадцать лет разработки ПО. Моя жена полюбила мою работу так же, как и я.
7. Продуманная локализация. С самого начала мы знали, что Microsoft хочет выпустить AoE на шести языках, в том числе на японском. Примерно в середине процесса разрабокти мы добавили в кодовую базу полную поддержку локализации. Для этого потребовалось вырезать и заменить в исходном коде все текстовые строки и хранить весь текст игры во внешнем файле ресурсов.
Также существовали строгие ограничения на отрисовку и отображение текста. Нам можно было использовать исключительно Windows GDI, от которого многие разработчики игр бежали, как от чумы. Кроме того, это значило, что элементы интерфейса (например, кнопки) должны были иметь такие размеры, чтобы в них умещались самые большие переводы их текстов. Это ограничивало список хитростей, которые можно было применять в пользовательском интерфейсе.
Но мы закатали рукава и справились, в точности следуя инструкциями. К нашему удивлению, такие преобразования оказались безболезненными и лёгкими. Мы почувствовали себя ещё лучше, когда переводчики из Microsoft сказали нам, что локализация AoE стала для них самым беспроблемным проектом.
Для нас такой подход стал огромным преимуществом: для всех переведённых версий игры у нас был единственный исполняемый файл, что позволило нам избежать огромной головной боли от вылавливания багов и выпуска обновлений для нескольких версий.
8. Мы работали как команда, уважающая всех своих членов. Проект размеров AoE требовал нашей долгой совместной работы в тесном контакте. Одним из критериев найма новых людей была возможность уважать друг друга.
Такое уважение, дополненное поддержкой сотрудников компанией, создавало удивительное ощущение семьи и командного духа. Мы избегали того, чтобы у отдельных групп создавалось чувство изолированности от проекта, поэтому отношения и моральный дух оставались на высоком уровне даже в моменты самой напряжённой работы.
Если бы у нас возникали конфликты и группировки, то не думаю, что мы бы успели выпустить AoE в 1997 году.
Что нам не удалось или можно было сделать лучше
1. Бета-тестирование провели слишком поздно. Публичный бета-тест AoE начался в августе 1997 года, но мы не смогли полностью использовать его потенциал. Мы были слишком близко к концу проекта, чтобы вносить в игру какие-то изменения, несмотря на множество полезных отзывов. Руководства к игре уже были готовы к печати, и почти весь дизайн нельзя было изменить. Мы могли только исправить обнаруженные ошибки. Для будущих проектов мы решили проводить бета-тестирование раньше.
2. Обмен информации с отделом контроля качества в Microsoft был построен неправильно. По большей части система баг-репортов управлялась через базу данных и разработчики не могли общаться непосредственно с тестерами. В результате на устранение многих ошибок потребовалось гораздо больше времени, а новые функции не тестировались.
Промежуточной базы данных было недостаточно для обмена информацией между тестерами и разработчиками. В будущих проектах мы хотели бы назначить каждому программисту отдельного тестера, чтобы они созванивались и обменивались информацией.
Ближе к концу разработки такую систему реализовали для пары программистов, и их продуктивность в тестировании и исправлении ошибок сильно повысилась.
3. Иногда нам не удавалось обеспечивать координацию между лидерами групп. Ещё одна область, в которой межличностная коммуникация могла бы улучшить разработку — это наши собственные группы разработчиков. У каждой из групп (программистов, художников, гейм-дизайнеров и специалистов по звуку) был лидер, следящий за работой каждого члена своей команды. Именно к лидерам обращались в случае появления новых запросов к команде со стороны.
В процессе разработки AoE давление увеличивалось, и эта система разрушилась. Люди общались непосредственно друг с другом, чтобы их запросы выполнялись быстрее. За это нам пришлось заплатить. Люди не знали об изменениях в коде или добавлении новой графики в игру, неразбериха нарастала, что приводило к тратам времени и отвлечению внимания. Иногда всем нам приходилось останавливать работу, чтобы выяснить, что происходит.
4. Нам не удалось адекватно протестировать многопользовательский режим с модемными соединениями. Среда разработки была непохожа на типичные системы конечных пользователей. В процессе разработки мы интенсивно тестировали многопользовательские функции AoE.
Когда мы играли в офисе, наши быстрые машины с большими объёмами ОЗУ обменивались данными по высокоскоростной локальной сети. Когда мы тестировали игру по Интернету, связь обеспечивала сеть T1 компании. Но в процессе тестирования мы не догадались, что большинство игроков будет использовать dial-up-модемы и медленное подключение к Интернет-провайдерам.
И так произошло не только у нас, та же ситуация возникла в тестовых лабораториях Microsoft. В результате мы недостаточно хорошо протестировали модемные соединения. Безобидные при низких задержках баги приводили на медленных Интернет-каналах к отключению пользователей от игры. И наша высокоскоростная сеть скрыла тот факт, что при определённых, довольно часто возникающих условиях AoE могла требоваться частота передачи в 15 Кбит/с. Такая исходящая скорость в шесть раз больше, чем мог обеспечить модем на 56 Кбит/с.
Поэтому сообщения о проблемах с многопользовательской игрой стали для нас неприятным сюрпризом. Хоть наш первый патч и решил эту проблему, ситуация была неприемлемой. После этого каждый разработчик начал использовать модем и соединения нескольких провайдеров, потому что проверка работы по модему было важной частью процесса тестирования.
5. Отдельные этапы разработки зависели от продуктов, которые не успевали выпускать вовремя. Была ещё одна причина того, что игры по модему тестировались недостаточно: проблемы с выпуском и качеством DirectPlay Microsoft. Функции, обещанные и даже добавленные в бета-релизы, отсутствовали в выпущенном с задержкой финальном релизе.
Direct X 5a стал доступен нам только за месяц до выпуска игры. Тем временем наш сетевой программист проводил бессонные ночи, реализуя обещанные нам Microsoft, но не выпущенные функции. Ожидание обещанных драйверов и SDK — одно из тяжелейших испытаний для разработчика. Нашим издателем была сама Microsoft, но даже у нас не было над этим контроля.
6. У нас не было планов выпуска патчей. Патч версии 1.0a, хотя и был успешен, всё равно вызвал проблемы, потому что мы его не планировали. Главный аргумент был таким: если вы знаете, что собираетесь делать патч, то не стоит выпускать игру вообще.
Можно понять эту точку зрения, но также ясно, что ни один разработчик не сможет протестировать игру так, как первые 50 тысяч покупателей. Покупатели будут пробовать такие вещи, о которых вы даже не задумаетесь, запуская игру на машинах и с драйверами, о которых вы даже не слышали. Насколько я знаю, почти для каждой крупной игры, выпущенной в этом году, появился патч или обновление.
Вместо того, чтобы отрицать реальность, нам нужно было выделить ресурсы и подготовиться к будущему, чтобы выпустить все необходимые обновления через несколько дней или недель после начала продаж игры, а не через месяцы.
7. У нас не получалось справляться с «внезапными» событиями. В процессе разработки возникло несколько ситуаций, которые привели к временной приостановке работы компании. Например, такими событиями были выпуск демо-версии и подготовка материалов о AoE для прессы.
Хотя многие из этих событий были для компании благоприятными, мы не очень справлялись с их организацией и наши планы срывались. Эти срывы в основном происходили на поздних этапах разработки, когда их влияние ощущалось наиболее сильно. Одна из наших целей при выпуске будущих игр — минимизировать влияние незапланированных событий с помощью предварительных уведомлений и ограничением количества людей, которые должны на них реагировать.
8. Мы недостаточно пользовались преимуществами автоматического тестирования. В последние недели разработки мы настроили игру на автоматическую битву до восьми компьютерных игроков друг против друга. Кроме того, за каждым искусственным интеллектом наблюдал второй компьютер, оснащённый платформой разработки и отладчиком. Эти игры генерировались случайным образом, но последовательность всех действий фиксировалась, так что мы могли повторять любую игру снова и снова, пока не удастся найти причину проблемы.
Сами игры можно было выполнять на повышенной скорости и их оставляли работать на всю ночь. Это было очень удобно и сильно помогло нам в воспроизведении проблем и определении их причин. Но наша ошибка была в том, что это нужно было сделать на более ранних этапах разработки. Так бы мы сэкономили огромный объём времени и труда. Теперь все планы будущих разработок включают в себя автоматическое тестирование с самого начала процесса.
Коллектив разработчиков Age of Empires. Мэтт Притчард в переднем ряду, второй справа.
Накладываем заплатки
После выпуска в AoE производство мы закатили большую вечеринку, чтобы немного сбросить стресс. Но оказалось, что радоваться пока ещё рано. Вскоре после появления AoE на полках магазинов мы начали получать сообщения о проблемах с поиском путей, поведением ИИ юнитов, ограничениями количества юнитов и многопользовательским режимом.
Кроме того, обнаружились баги, позволявшие игроку эксплуатировать в игре нечестные преимущества. Руководство Ensemble и Microsoft пришло в движение, и было принято решение выпустить для AoE патч.
Несмотря на то, что пришлось отвлечься от других проектов и разработка длилась больше, чем хотелось, патч был успешным. Он сильно улучшил качество многопользовательских игр, исправил ошибки и решил возникшие в игровом процессе проблемы. И так возникла современная версия AoE, которая, как я надеюсь, хранится у вас где-то на жёстком диске…
[Мэтт Притчард создавал графический движок для Age of Empires. Также он работал над Age of Empires II, Age of Mythology и BlackSite: Area 51.]
