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

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

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

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

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

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

<p>Полировка</p>

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

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

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

<p>Правки баланса игры</p>

В своей книге Challenges for Game Designers: Non-Digital Exercises for Video Game Designers Бренда Ромеро и Ян Шрайбер дают следующее определение игрового баланса:

Перейти на страницу:

Похожие книги

Исторические информационные системы: теория и практика
Исторические информационные системы: теория и практика

Исторические, или историко-ориентированные, информационные системы – значимый элемент информационной среды гуманитарных наук. Его выделение связано с развитием исторической информатики и историко-ориентированного подхода, формированием информационной среды, практикой создания исторических ресурсов.Книга содержит результаты исследования теоретических и прикладных проблем создания и внедрения историко-ориентированных информационных систем. Это первое комплексное исследование по данной тематике. Одни проблемы в книге рассматриваются впервые, другие – хотя и находили ранее отражение в литературе, но не изучались специально.Издание адресовано историкам, специалистам в области цифровой истории и цифровых гуманитарных наук, а также разработчикам цифровых ресурсов, содержащих исторический контент или ориентированных на использование в исторических исследованиях и образовании.В формате PDF A4 сохранен издательский макет.

Динара Амировна Гагарина , Надежда Георгиевна Поврозник , Сергей Иванович Корниенко

Зарубежная компьютерная, околокомпьютерная литература / Учебная и научная литература / Образование и наука