Вскрытие: Resident Evil 2 от Angel Studios (версия для N64)

В октябре 1997 года два сотрудника Angel Studios вывесили на стене послание самим себе: "1 сентября 1999 года мы выпустим игру, которая понравится людям. Мы будем знать, что её любят, потому что к 1 января 2000 года будет продано два миллиона копий".

Вскоре после этого Capcom выбрала Angel Studios для портирования Resident Evil 2 на Nintendo 64. Директору проекта Крису Фодору и ведущему программисту Джейми Брайанту было поручено это задание, и они начали закладывать основу и собирать команду. Хотя у них обоих уже был опыт работы с Nintendo 64, этот амбициозный и сложный проект быстро показал, что они не знают, как работает N64. Конечно, у нее есть процессор, обработчик геометрии, графический чип, пожарные выходы здесь, здесь и там, но на какой именно высоте опускаются кислородные маски, или они должны включаться вручную пилотом? В следующие несколько месяцев ОС была перестроена, векторные блоки (да, в N64 есть векторный блок) эмансипированы, и N64 выдала свои секреты.

Оригинальная игра Resident Evil 2 для Playstation занимала два компакт-диска. Нам пришлось выпускать ее на одном картридже. Но ведь это всего лишь порт, верно? У нас в руках была уже классическая игра с отличным дизайном, все иллюстрации были сделаны, а искусственный интеллект настроен и находится на своем месте. Однако, чтобы запустить ее на N64, требовалось довольно хитрое проектирование. Это была задача, в решении которой сомневались новостные ленты, игровые сайты и, возможно, даже издатель.

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

1. Рабочая среда и коллектив

Учитывая, что это должен был быть очень технологичный проект, было очень важно, чтобы у нас была сильная и сплоченная команда программистов. Проект быстро набрал обороты, когда в декабре 1998 года к нам присоединился Алекс Эрат, а затем и я. Алекс привнес богатый опыт, преданность делу и трудолюбие. Только что окончив колледж, я получил задание создать полномасштабное видео. (Подробнее о том, как это было сделано, читайте в моей статье "Миссия: Compressible -- Achieving Full-Motion Video on the Nintendo 64" в предстоящем сентябрьском номере журнала Game Developer за 2000 год). Крис Фодор и Джейми Брайант разделили между собой руководство. Иногда это приводило к "слишком большому количеству поваров на кухне", но чаще всего они дополняли друг друга и обеспечивали эффективное руководство на протяжении всего проекта. Кен Камдар появился в конце проекта, привнеся чувство спокойствия и умиротворения (а также свои навыки программирования) в самый нужный момент. К этому моменту у нас были представители Австралии, Германии, Англии, Ирана и США. Вы бы не подумали, но это необычное сочетание дало такой уровень синергии, который редко встречается во многих командах программистов.

У нас, программистов, столы располагались полукругом, лицом наружу, но все начиналось иначе. Изначально у Криса был свой кабинет, а Алекс и Джейми сидели довольно далеко друг от друга, отстаивая свою собственную территорию. Однако уже через месяц после начала проекта мы отставали от графика. Нам нужно было быть на высоте и больше общаться.

Мы решили сидеть вместе. Когда пришел я, а затем и Кен, они просто расширили полукруг". О работе мозга и о его зонах написано много, и, как вспоминает Джейми, "Алекс иногда прерывал меня, когда я был на взводе, чтобы рассказать какую-нибудь очень глупую шутку, но я ручаюсь, что потерянное время было ничто по сравнению с выигрышем в эффективности от того, что все были рядом". В начале проекта возникает множество вопросов и решений, которые необходимо принять. Каждый мог слушать, даже если он изначально не участвовал в обсуждении, и часто кто-то поворачивался и предлагал свою идею, которая приводила к наилучшему решению. К середине проекта мы смогли лучше понять, как не перебивать тех, кто погружен в размышления. В итоге, я думаю, мы сэкономили несколько месяцев": " Сбой" [показывает]. [поворачивает голову] "О да, это ошибка с ликером - не нажимай на кнопку B, когда он это делает [показывает] - и я проверю исправление через десять минут".

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

2. Достижение первого рубежа

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

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

3. Отсутствие религиозной привязанности

Никогда не стоит слишком привязываться к чему-то, что вы сделали, будь то бизнес-процесс, алгоритм или просто реализация. Если что-то не работает, не надо этого делать. Если что-то работало, но больше не работает, бросьте это и найдите что-то новое.

Мы применили этот принцип к нашим коммуникациям. Мы начали с использования Microsoft Team Manager 97. Он не продержался и месяца. Затем мы сдвинули столы в полукруг, чтобы все были под рукой и в одной комнате. Это сработало очень хорошо, и мы сохранили этот принцип.

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

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

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

Мы также узнали, что важно писать код для текущей задачи, а не для той, которая может возникнуть в будущем. Я надеюсь, что для большинства программистов это очевидно, но многие из нас (включая меня в свое время) потерялись в мире C++. У C++ есть много преимуществ, но многие из них просто нежизнеспособны по причинам производительности и размера на стареющей консоли. Очень легко при написании объектно-ориентированного кода попасть в ловушку, пытаясь спроектировать даже толковую систему. Не утруждайте себя. Будьте готовы все переписать. Возможно, вы сможете переписать какой-то участок кода в три раза быстрее, чем вам потребуется для проектирования идеальной иерархии классов. Суть в том, что вы не должны привязываться к тому, что у вас есть. Будьте готовы отбросить это и попробовать что-то другое.

4. Использование подробного расписания и плана

С самого начала у RE2 был четкий и подробный план того, что именно потребуется, разбитый на мельчайшие детали. Благодаря этой информации наш умелый продюсер Стюарт Спилкин смог точно спланировать задачи проекта и распределение ресурсов (Стюарт сыграл важную роль в преодолении внешних трудностей, что позволило нам сосредоточиться на разработке, постоянно приближая завершение проекта). Я не могу переоценить важность подробного плана. Он заставляет вас изучить и часто обнаружить то, что действительно необходимо сделать, и это позволяет вам планировать. Невозможно иметь слишком много деталей. Это был, конечно, амбициозный график, но вполне достижимый - что сделало его одновременно трудным и полезным.

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

Мы с блеском справились с просьбами издателя о добавлении новых функций, особенно к концу проекта. Вместо нападок изнутри на "ползучесть функций"*, они приходили извне. Каждый раз, когда предлагалась новая функция, мы изучали, что потребуется для ее реализации, и представляли честный отчет о том, сколько ресурсов потребуется для ее реализации. Например, мы подсчитали, что с дополнительным штатным программистом мы точно сможем решить задачу А, возможно, задачу Б (80 процентов) и, возможно, задачу В (20 процентов). После этого клиент получал всю необходимую информацию, чтобы сделать выбор, и в большинстве случаев он выбирал "нет".

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

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

5. Максимальное многократное использование того, что есть

Учитывая огромное количество ресурсов, предоставленных PSX-версией, гораздо разумнее было проанализировать каждый тип данных (2D-спрайты, данные о коллизиях и так далее) и реализовать конвейер, который затем преобразовал бы PSX-специфичные ресурсы в то, что мы могли бы прочитать и использовать на N64. Поскольку это был порт, мы могли быть уверены, что в итоге получим все нужные нам части, если просто пакетно конвертируем их целиком, а не будем вручную дорабатывать каждую из них, и сэкономим таким образом огромное количество времени. Написание кода, который преобразовывал все 2D спрайты в нужный нам формат, заняло несколько дней, но художнику потребовалось бы очень много времени, чтобы вручную откорректировать тысячи спрайтов.

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

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

1. Процесс подачи заявки в Nintendo

Закон Мерфи: для проекта, который шел так гладко, наша самая большая проблема возникла в последний момент, после того как игра была "завершена" и мы ожидали одобрения Nintendo. Мы были готовы откинуться на спинки кресел и поздравить друг друга с хорошо выполненной работой, но наша игра все еще нуждалась в одобрении Nintendo, как в Японии, так и в США. Последовавшие задержки привели к тому, что мы пропустили идеальную дату релиза, которая в США приходилась на Хэллоуин.

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

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

Если вы сможете напрямую поговорить с людьми, вы сможете исправить ситуацию гораздо быстрее и буквально сэкономить несколько дней. Вы также будете знать, где находится ваша игра в любой момент времени. Вместо того чтобы представлять себе, что она варится в запутанных недрах какой-то демонической компании, вы будете знать, что Сэм сказал, что передал ее Бобу, и вы сможете позвонить Сэму и попросить его подойти к Бобу и попросить его сделать что-нибудь с вашей игрой. Это часто упускается из виду в небольшой команде, которая в течение длительного периода времени была очень сосредоточена на своей работе. Внезапная необходимость полагаться на кого-то еще, или на множество других людей, не является чем-то естественным. Заставьте себя звонить по телефону и знать свой статус в любой момент времени - вы этого заслуживаете. Это был радостный момент для Криса, когда ему позвонил человек из Nintendo, с которым он никогда раньше не встречался, изменил один бит за несколько мгновений и отправил игру в обратный путь через 30 минут. Он просто неправильно расслышал сплетни и не знал каким должен был быть бит состояния.

2. Недостаточное тестирование

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

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

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

3. Сжатие

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

4. Отсутствие контроля со стороны руководства

У каждого человека есть определенный набор вещей, которыми он дорожит. Для некоторых из нас очень важна добросовестность в работе, для других - нет. Как я уже говорил раньше (и скажу еще раз), когда вы показываете, что понимаете слово " этап", вы выделяетесь в игровой индустрии. Это особенно верно в игре, где ваш текущий прогресс может быть сопоставлен с завершенным эталоном. Не все, и уж точно не все в вашей команде, будут разделять это понимание.

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

5. Недостаточно высокий приоритет аудио

В начале проекта это была самая недооцененная и малобюджетная задача. Мы быстро осознали масштаб: не менее 200 музыкальных произведений, много коротких, но, тем не менее, каждое MIDI-произведение имеет свои собственные уникальные сэмплы - кошмар для конвертации на картридж. У Angel Studios просто не было опыта и знаний для выполнения этой части проекта.

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

Компания Factor 5 занимается разработкой инструментария для воспроизведения звука на Nintendo нового поколения. У них есть система, которая воспроизводит на ПК в точности то, что вы услышите на Nintendo. Любое изменение можно услышать мгновенно, а образцы можно постоянно дорабатывать, пока они не будут соответствовать ограничениям по размеру и качеству. Они ускорили для нас процесс конвертации и обучили наших сотрудников работе с их инструментами, одновременно конвертировав половину MIDI-файлов и все сэмплы музыкальных инструментов. Ноты, которые звучали одинаково и были разбросаны по нескольким MIDI-файлам, были собраны и многократно использованы в банке звуков. Каждый зацикленный образец (например, реверберирующая нота фортепиано) был обработан Руди Штембером из Factor 5, а Крис Хельсбек участвовал в процессе преобразования MIDI. Результат превзошел все ожидания. Наконец, использование их звукового драйвера на N64 позволило нам использовать Dolby Surround Sound для размещения звуков в настоящем трехмерном пространстве, что сделало внутриигровой звук намного лучше, чем у его старшего брата на PSX.

Итог

Сейчас я хочу выпустить немного пара. Тот, кто придумал использовать "порядок байтов", должен быть расстрелян. Мы это предвидели, поэтому я не могу сказать, что все пошло не так, но было очень тяжело работать из-за огромного количества магических чисел и жестко закодированных значений в коде RE2. Нам буквально пришлось понять и перефразировать каждый бит данных в библиотеке RE2. И мы это сделали, к чести каждого программиста в команде. В процессе работы возникло довольно много ошибок, но мы их все устранили.

Хотя оригинальный код RE2 был написан на C, он больше напоминал язык ассемблера, чем структурированный код. Учитывая, что большинство из нас читает на английском, японские комментарии тоже не особенно помогли.

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

Несмотря на эти незначительные разглагольствования, RE2 на N64 имела большой успех. Хотя мы не достигли нашей высокой цели - 2 миллиона копий к январю 2000 года, мы сделали точное воплощение великой игры на Nintendo 64, и даже успели сделать пару первых шагов в индустрии создав пару дополнений. Нам удалось сделать это в срок (почти) и в рамках бюджета, несмотря на большие технические трудности, свалившиеся на нас, во многом благодаря отличной команде, подробному плану и графику, а также огромному количеству тяжелой работы!

Статистика:

Издатель: Capcom
Количество штатных разработчиков: 9
Количество подрядчиков: 1
Бюджет: $1,000,000 (на 1999 год) 1,825,492.20 (По стоимости на 2023 год)
Продолжительность разработки: 12 месяцев
Дата релиза: 16 ноября 1999 года
Используемое оборудование для разработки: SN64 от SN Systems Используемое программное обеспечение для разработки: Visual SlickEdit, gcc, Debabalizer, Photoshop, Softimage
Примечательные технологии: Наша собственная ОС N64 и система сжатия и воспроизведения FMV.
Общее количество строк кода: около 200 000

Источник: Тут
Перевод: ReLive Team (LeonSK)