Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан
Глава 33
Майлстоун релиз-кандидата
Майлстоун релиз-кандидата наступает, когда мы наконец собираем билд игры, который, по нашему мнению, готов к выпуску. Мы исправили все баги, которые смогли, завершили полировку, на которую нам хватило времени, и сбалансировали игру, насколько это было возможно. Мы тщательно протестировали игру, не обнаружив никаких серьезных проблем. Теперь мы готовы провести последний раунд тестирования, чтобы наконец дать добро на распространение игры. Когда игра достигает майлстоуна релиз-кандидата, иногда говорят, что она «ушла на серебро» – а за серебром, как известно, следует золото.
На протяжении всей этой книги я говорил вам, что релиз-кандидат – заключительная ступень цифровой игры. Но это не совсем так. Выпуск программного обеспечения – сложный процесс, и, как и в случае с поэтапностью процесса постпродакшена, в самом конце проекта скрывается еще один майлстоун. Как только мы тщательно протестируем релиз-кандидат, он алхимически переходит из серебра в золото, становясь финальной – золотой – версией, а мы получаем возможность нашу игру распространять.
Такая версия называется золотой, потому что в начале 90‑х некоторые диски CD-ROM были золотистого цвета из-за органических красителей или настоящего золота в составе записываемого слоя[189]. Физический золотой мастер-диск создавался в игровой студии или у издателя и отправлялся на завод-изготовитель для дублирования на картриджи, дискеты или компакт-диски, которые потом продавали в игровых магазинах. Сегодня мы можем отправлять эту информацию через интернет несколькими щелчками мыши и распространять ее онлайн.
Другими словами, на этапе релиз-кандидата программисты, режиссеры и продюсеры проекта готовы отступить и сказать: «Хорошо, кажется, игра закончена. Протестируйте ее еще раз, чтобы быть уверенными. И тогда у нас будет золотая версия, готовая к выпуску».
Что нужно для релиз-кандидата
С практической точки зрения релиз-кандидат – это версия игры, которая:
• завершена с точки зрения фичей и контента;
• прошла некоторую полировку как фичей, так и контента;
• была сбалансирована;
• достаточно часто тестировалась, чтобы мы были уверены, что обнаружили все существенные баги;
• прошла проверку на исправление всех критических багов и блокеров (при этом баги, которые мы решили не исправлять, закрыты).
Уточнение в последнем пункте, вероятно, покажется многим читателям странным или даже ужасным. Как можно выпускать игру с ошибками, о существовании которых мы знаем? Я сам долгое время восставал против этой идеи. Как гейм-дизайнера, который заботится о высоком качестве своей работы, меня мысль о релизе игры с багами приводила в ужас.
Но в конце концов мне пришлось принять это как реальность разработки программного обеспечения. Мы здесь говорим не о багах, которые вызовут проблемы у игрока – такие баги, конечно, стоит исправлять. Мы закрываем только те ошибки, наличие или отсутствие которых является скорее суждением о субъективном восприятии игры. Если ошибка не влияет на геймплей и большинство игроков ее не заметит, то мы можем ее закрыть, особенно если у нас мало времени на исправление куда худших багов.
К релиз-кандидату нам нужно сделать кое-что еще. Что-то из перечисленного может требоваться на ранней стадии этапа постпродакшена и, возможно, для достижения майлстоуна бета-версии:
• из билда должны быть удалены меню отладки и комбинации клавиш для быстрого перемещения. Разработчики часто встраивают такие функции, чтобы телепортироваться по игре, сделать персонажа игрока неуязвимым или предоставить ему неограниченные ресурсы, а также проанализировать технические системы игры;
• должны быть удалены любые отладочные показания на экране (например, показатель частоты кадров);
• должны быть созданы фичи и контент, которые потребуются для сертификации игры, если они еще не были созданы и доработаны. Мы обсудим это более подробно в главе 34.
Как только мы подготовим релиз-кандидат, мы готовы еще его потестировать.
От релиз-кандидата к золотой мастер-версии
Тестирование релиз-кандидата для перевода проекта в статус золотой мастер-версии как никогда строго. Нужен комплексный и всеобъемлющий тест-план, легион квалифицированных специалистов по обеспечению качества, а также несколько инженеров, продюсеров и других членов руководства команды. Могут также потребоваться художники, аниматоры, звукорежиссеры и гейм-дизайнеры.
Подобно детективам, расследующим сложное дело, QA-команда зорким орлиным глазом выискивает ошибки билда. Они охотятся за неприятными скрытыми багами, которые воспроизводятся очень редко или только тогда, когда игрок делает что-то необычное и неожиданное. Конечно, все это – регулярная практика обеспечения качества, но здесь, на заключительном этапе тестирования, она становится еще важнее.
QA проводит «тестирование утечек», оставляя игру запущенной, но бездействующей в течение нескольких дней подряд, чтобы убедиться, что она не выйдет из строя. Они проверяют каждую часть пространства возможностей игры в последний раз, чтобы убедиться, что все на месте и исправно работает. Они проверяют, соответствует ли игра сертификационным требованиям издателя или платформы – мы обсудим это в следующей главе.
Если обнаружатся какие-либо ошибки, с QA встретится руководство команды, чтобы выяснить, насколько серьезна проблема и не придется ли вносить изменения в релиз-кандидат. Как мы обсуждали в предыдущих главах, каждый раз, когда мы что-то меняем в игре, мы рискуем непреднамеренно создать новые проблемы. QA-отдел будет начинать весь процесс тестирования заново каждый раз, как в код вносится даже одно изменение.
Таким образом мы кропотливо продвигаемся к созданию золотой версии. Конечно, небольшим командам с ограниченными ресурсами этот этап проекта покажется сложным. Существуют QA-студии, которым команды передают это бремя на аутсорс, но командам с маленьким бюджетом придется проводить тестирование самостоятельно.
Профессиональные команды должны перейти к золотой версии игры
