В апреле 2001 года в журнале Game Developer Magazine постмортемом месяца стала American McGee's Alice — готическая игра в жанре action-adventure, переосмысленная классическая «Алиса в стране чудес» Льюиса Кэррола. Ее же поместили и на обложку журнала. Эта игра для ПК была первым самостоятельным проектом Американ Макги после начала его работы в id Software и стала наиболее известной серией, в которой он использовал мрачную сказочную тематику. Позже она проявилась в Grimm — эпизодическом пересказе «Красной шапочки», созданной Макги. Автор, объяснявший свои вкусы религиозным воспитанием, впоследствии выпустил продолжение «Алисы» — “Alice: Madness Returns”, которое вывело игру на консоли. Однако Electronic Arts не поддержал третью часть серии, что побудило Макги полностью отказаться от разработки игры. Этот постмортем написал один из основателей Rogue Entertainment Джим Молинец (Jim Molinets). В нем речь пойдет о том, что, по мнению участников, в оригинальном проекте было сделано правильно и что неправильно. Это первая публикация с оригинальными иллюстрациями.

Чтобы узнать подробнее об этой культовой игре и ее уникальном месте в истории разработки, прочтите наше интервью с Американ Макги от 2001 года, в котором разработчик рассказывает о том, что привело его к созданию концепции игры. Также можете взглянуть на постмортем пересказа «Красной Шапочки» Макги, Grimm.

Что получится, если взять успешного независимого разработчика, одного из крупнейших в мире издателей игр и дизайн, вдохновленный одновременно уникальным и знакомым всем произведением — сказками Льюиса Кэрролла про Алису? Electronic Arts, желающая произвести фурор своей первой игрой для ПК; Rogue Entertainment, создающая American McGee's Alice; а также все взлеты и падения заключены в одну маленькую черную коробочку с девочкой и ее загадочным котом на обложке.

American McGee's Alice — это рассказ о юной девушке, с которой произошла трагическая история, в результате которой она потеряла связь с реальностью и оказалась заключена в безопасности собственного разума. Спустя годы пережитое начинает атаковать Страну чудес, превращая ее в мрачное и угрожающее место — такое же разбитое и фрагментированное, как и сама Алиса. Мы хотели, чтобы игра сочетала бы в себе и боевые элементы таких легендарных игр, как Doom и Quake, и приключенческие элементы Tomb Raider. Мы стремились к тому, чтобы в нашей игре эти элементы органично сочетались с интригующим сюжетом, а безграничная свобода Страны чудес позволила создать фантастическое окружение. Еще одной целью было создание сильной женской героини, лишенной преувеличенных стереотипно женских качеств. Алиса должна была стать персонажем, который бы перешагнул привычные гендерные границы в экшн-играх и привлек бы внимание геймеров-женщин.

Rogue была готова выполнить эти задачи благодаря нашему богатому опыту работы с технологией QUAKE. Этот опыт мы получили в результате пятилетней работы с id Software над миссионными пакетами для QUAKE и QUAKE 2, а также портом QUAKE 2 для N64. Когда мы начали вести переговоры с Electronic Arts, одним из наших главных преимуществ было то, что мы вдоль и поперек знали технологию id. У нас была команда из девяти преданных своему делу профессионалов, готовых к решению задач, связанных с созданием первой полноценной игры Rogue со времен нашей первой игры Strife, которая вышла за четыре года до этого. Мы также чувствовали, что пора оставить в прошлом репутацию «компании, ориентированной на миссии», и что Alice поможет нам сделать это. 

Как компания, мы все были в восторге от того, что именно нам предстоит рассказать новую сказку о Стране чудес и приключениях нашей Алисы в ней. Команда программистов была готова усовершенствовать и расширить технологию, чтобы создать платформу, способную выдержать огромный вес игровых ассетов. Дизайнеры были готовы создать захватывающий мир, который бы установил новые стандарты в level-дизайне. Художники были готовы перенести искаженные представления безумного мира в текстуры этого мира. Наши моделеры/аниматоры хотели раздвинуть рамки привычных представлений о персонажах Льюиса Кэрролла и обогатить бестиарий своими собственными дополнениями так, чтобы эти персонажи запечатлелись в сознании игроков. Мы хотели, чтобы Alice была лучшей игрой, на которую мы способны, и ничто не должно было стоять на нашем пути.

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

1. Рост компании и команды

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

2. Уровень профессионализма

Профессионализм команды положительно сказывался на всех аспектах проектирования. В индустрии есть печальные истории о командах, которые разрушаются из-за проявлений эгоизма. Почему-то кажется, что для разработчиков это стало нормой. Rogue всегда старалась не допускать появления такой проблемы, и мы считаем, что команде это удалось. Во время разработки Alice людей интересовало не то, кто за что получил признание, или кто принес самые крутые идеи, а просто то, что все работали над улучшением игры. Это касалось и критики — еще одной области, где эго может помешать. Члены команды открыто критиковали работу друг друга, и это никогда не переходило в разряд личных обид, а воспринималось как благо, которое сделает продукт сильнее и поможет всем.

3. Творческая свобода

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

4. «Партизанские» встречи

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

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

«Партизанские» встречи стали полезным инструментом в частности для инженеров. Это были короткие митинги, на которых присутствовали только ключевые сотрудники всех отделов, и они были очень сфокусированными, что позволяло участникам быстро вернуться к своей работе.

5. Интеллектуальная собственность 

Я оставил этот пункт напоследок, но большинство сотрудников Rogue согласятся с тем, что это была одна из лучших, если не самая лучшая часть проекта. Большинство разработчиков стремятся создать что-то новое и захватывающее. Иногда это удается (Age of Empires, Starcraft, Doom, The Sims). Иногда — нет (Battlezone, Interstate '76). Все это отличные игры, в которые я с удовольствием играл, но игры из второй группы не вызвали у пользователей того же отклика, что игры из первой. 

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

Это одна из проблем, связанных с использованием реальной ситуации. Какими бы причудливыми ни были различия между реальным миром и миром игры, люди все равно ориентируются на то, что должно работать в реальном мире. Electronic Arts не ограничивала эту свободу, и мы позволили команде творчески в нее погрузиться. Рецензенты также отметили это как одно из главных достоинств Alice.

Что пошло не так 

1. Планирование

Ни один план не доживает до первого рубежа в изначальном своем виде. Мы переделывали план из-за вмешательства многих факторов, но самым важным из них был рост команды. Мы начинали проект с девятью разработчиками, думая, что сможем завершить игру в таком составе, а к концу потребовалось около 25. Наша первая ошибка заключалась в том, что мы думали, что один моделер/аниматор сможет сделать персонажа Алису и все ее анимации за три недели. К концу проекта у нашей юной героини было 180 последовательностей и около 12 000 кадров анимации. Часть из них не вошла в игру, но по этим цифрам можно судить о том, что мы не успели, очень не успели. Несомненно, главные герои в играх с перспективой от третьего лица требуют от художника самоотверженной работы от начала и до конца. 

Еще одним фактором, повлиявшим на наш график, стала недооценка количества времени, необходимого для создания одного уровня. В Quake 2 на создание и наполнение уровня, если он был заранее проработан, у одного дизайнера уходило около полутора-двух недель. В Alice на это уходил почти месяц. И это без учета сценария и кинематографических эффектов, которые требовали еще как минимум неделю. Мы были готовы сделать Страну чудес такой, какой она могла бы быть, просто у нас не было представления о том, сколько времени это займет. Эти ошибки в сочетании с другими аналогичными факторами грозили перевести Alice в разряд «еще одного опоздавшего софта».

Для того чтобы минимизировать это влияние, мы были вынуждены попросить команду войти в печально известный Crunch Time примерно за четыре месяца до ожидаемой даты поставки. (Думаю, любой, кто проходил через подобное, поймет, почему я написал с заглавных букв).

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

2. Коммуникации. Во многих проектах причиной задержек в цикле разработки продукта и срыва сроков поставки называют недопонимания или недостаток коммуникаций. Alice, к сожалению, не стала исключением. Rogue начинался как команда из девяти человек в небольшом офисе, в теплой ламповой атмосфере, что способствовало формированию сообщества и сознательного процесса разработки. Это работает с очень небольшой группой людей, но просто не подходит для команды из 25 человек. Мы понимали, что переезд в новый офис во время цикла разработки повлечет изменения в организации команды, чтобы придать ей большую структурированность и улучшить процесс обмена информацией.

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

3. Нехватка ресурсов на предварительную разработку 

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

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

4. Нехватка времени на инновационные решения

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

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

5. «Помощь» со стороны

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

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

Усвоенные уроки 

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

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

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

Также важной частью команды являются тестировщики. Они помогают своевременно найти баги и сделать так, чтобы игра отвечала ожиданиям и требованиям. Искусство тестирования игр можно постичь с нуля на онлайн-курсе "Game QA Engineer". Скоро в рамках этого курса пройдут открытые уроки, на которые приглашаем всех желающих:

• Особенности тестирования игр, 9 ноября

• Инструменты для тестирования игр, 15 ноября