Ознакомительная версия. Доступно 26 страниц из 130
Исправление багов
В главе 23 мы говорили о процессе поиска багов и последующего отслеживания багов. К тому времени, когда игра выходит из беты, у нас на руках длинный список багов, которые необходимо исправить, даже если мы исправили серьезные баги сразу после их возникновения. Новые баги появляются каждый раз, когда мы что-то добавляем в нашу игру, – и это нормально, особенно в суматохе, которая сопровождает майлстоун бета-версии, наш список багов обычно растет очень быстро. После беты большая часть усилий команды вполне может быть сосредоточена на исправлении багов. QA-отдел становится более важным для процесса разработки, чем когда-либо прежде, поскольку между командой и готовой игрой теперь стоят только базы данных багов.
Отдельные баги будут проверяться и обсуждаться, иногда энергично или даже горячо, но, надеюсь, всегда в атмосфере уважения и доверия. Каждому члену команды крайне важно помнить, что мы все работаем ради одной цели: прекрасной игры. Из-за того, что мы по-разному ценим разные дисциплины и отделы, может возникнуть конфликт: баг, который одному кажется незначительным, для другого может иметь колоссальное значение. Но мы должны руководствоваться не сиюминутными порывами и целями, а думать о том, что принесет наибольшую пользу игре и нашему сообществу игроков. И только работая вместе, мы сможем выяснить, как лучше всего решить каждую проблему за оставшееся у нас время.
Исправления, над которыми мы работаем, могут легко привнести в игру другие проблемы. Некоторые исправления более рискованны, чем другие: любое исправление бага, которое подразумевает внесение глобальных изменений в игру, куда рискованнее, чем то, которое затронет лишь малую часть игры. Конечно, тестирование должно выявить новые возникающие проблемы, но чем ближе мы к релизу, тем больше вероятность того, что новые проблемы останутся незамеченными.
В эпоху цифрового распространения мы можем выпускать обновления для устранения багов в уже изданной игре, но мы все равно должны быть очень осторожны во время этапа постпродакшена. Необнаруженные баги, появившиеся в игре из-за внесенных изменений, могут вызвать у нас большие проблемы. Вдруг очень серьезный баг попадет в билд, который мы отправляем инфлюенсеру или рецензенту, или окажется в уже изданной игре? Если у людей сложится негативное впечатление о нашей игре или они вообще не смогут в нее играть, это сильно ударит по нашей карьере. Вирусные видеоролики с впечатляюще ужасными багами могут легко убить интерес аудитории к игре.
Я не сторонник тотальной паранойи, что нужно успеть исправить все за этап постпродакшена – опытные гейм-дизайнеры учатся определять, насколько рискованно то или иное исправление бага. Но мы должны действовать осторожно, особенно ближе к концу этапа постпродакшена. Чем мы ближе к майлстоуну релиз-кандидата, тем продуманнее должны быть наши исправления – у нас попросту не хватит времени на устранение новых багов. Так что подходите к этому процессу с осторожностью хирурга. Повысьте приоритет более сложных и рискованных исправлений и займитесь ими в первую очередь.
Полировка
Как только игра будет завершена к бета-майлстоуну, вы сможете начать полировать контент, внося небольшие изменения, чтобы улучшить внешний вид, звучание и ощущение игры. В предыдущей главе мы говорили, что мы должны внедрять контент в таком качестве, чтобы при необходимости игру можно было уже опубликовать. Желательно, чтобы наши первые наброски контента были хорошо отполированы еще до того, как они попадут в игру, – как и в любом виде ремесла, чем опытнее мы становимся, тем более высокого качества будут даже самые черновые наши работы.
Чем больше времени у нас на постпродакшен и чем меньше у нас багов, тем больше времени мы можем посвятить полировке. И наоборот, если у нас не так много времени на постпродакшен и нужно исправить много багов, на полировку у нас остается совсем немного времени. Исправление ошибок обычно приоритетнее улучшения контента: выпускать игру с плохим звуковым сопровождением или визуалом никто не захочет, но у забагованной игры еще меньше шансов на успех.
Как и в случае с исправлением багов, любая работа, связанная с полировкой игры во время этапа постпродакшена, рискованна, поскольку она может привести к появлению новых ошибок и проблем с дизайном. Чем больше изменений требует полишинг, тем выше риск. Основная работа по полировке – особенно если она глобально меняет игру – должна быть сделана в самом начале этапа постпродакшена. Полировка должна быть закончена к его середине, чтобы у нас было время выявить и устранить все возникшие проблемы.
Правки баланса игры
В своей книге Challenges for Game Designers: Non-Digital Exercises for Video Game Designers Бренда Ромеро и Ян Шрайбер дают следующее определение игрового баланса:
Баланс: термин, используемый для описания состояния систем игры как «сбалансированных» или «несбалансированных». Когда игра не сбалансирована, она слишком легка, слишком сложна либо же подходит только определенной группе игроков. Когда игра сбалансирована, она предоставляет консистентный уровень испытаний для своей целевой аудитории. В соревновательных играх баланс подразумевает то, что нет какой-то единой стратегии, которая лучше прочих, и что нет эксплойтов, которые позволят игроку обойти предлагаемые игрой испытания. Мы также иногда называем отдельные игровые элементы «сбалансированными» друг с другом, что означает, что стоимость их получения пропорциональна производимому ими эффекту, как в случае с картами в ККИ или оружием в шутерах от первого лица и RPG[186].
Большинство гейм-дизайнеров пытаются сбалансировать дизайн своей игры на протяжении этапов препродакшена и продакшена, настраивая механизмы и механики для создания интересного, приятного опыта в игре, который будет не слишком легким, не слишком сложным. Тем не менее точно настроить игровой баланс к бета-версии может быть непросто. Этап постпродакшена дает нам последний шанс окончательно разобраться с балансом игры.
В своем блоге Game Balance Concepts («Принципы игрового баланса») Ян Шрайбер пишет:
Ознакомительная версия. Доступно 26 страниц из 130
