Ознакомительная версия. Доступно 26 страниц из 130
баг, тогда они могут соответствующим образом пометить ее и передать для дальнейшей оценки.) В следующем билде баги, отмеченные как исправленные, возвращаются в QA-отдел для повторной проверки, чтобы убедиться, что проблема действительно устранена.
Баг-репорты в конечном счете становятся важной частью жизни каждого члена команды, и устранение проблем, о которых в них сообщается, займет большую часть рабочего дня отдельного разработчика. QA-тестировщики не просто специалисты по поиску багов и исправлению ошибок – они превосходный источник знаний в области гейм-дизайна и получают отличное представление об опыте, который игра дает своим игрокам. Люди, работающие в QA-отделах, обычно очень увлечены и хорошо разбираются в играх. Зачастую они обладают аналитическим мышлением и развитым пониманием гейм-дизайна и полны превосходных идей. Я всегда старался найти людей, работающих в отделе обеспечения качества, выразить им свое почтение, расспросить их об их работе и чему-нибудь у них научиться.
QA – это дисциплина, относящаяся к сфере разработки, и люди, которые работают в QA, – разработчики игр. В соответствии с философией этой книги, согласно которой каждый, кто вносит вклад в игру, считается одним из ее разработчиков (об этом говорилось в главе 4), мы должны помнить, что люди, работающие в QA-отделе, тоже разработчики. Мы должны приглашать отдел обеспечения качества на каждом этапе проекта, тесно и эффективно работая вместе, чтобы создавать лучшие игры, какие только можем.
Автоматизированное тестирование
Разработчики программного обеспечения создавали механизмы для автоматического тестирования написанного ими кода почти с того самого момента, с какого существует сама информатика. В автоматизированном тестировании используется специальное программное обеспечение, которое тестирует другое программное обеспечение, также оно может быстро и эффективно выполнять рутинную работу тестировщика или же проводить тесты, которые человек вовсе не смог бы провести.
Самые известные примеры автоматизированного тестирования – это модульное, интеграционное и нагрузочное тестирование сервера, где модули и группы кода и данных тестируются на предмет того, правильно ли они работают. Автоматизированные плейтесты могут имитировать ввод данных человеком в игру с помощью контроллера, клавиатуры, мыши или сенсорного экрана. Автоматизированный тест может использовать программный интерфейс, чтобы полностью обойти систему ввода и напрямую взаимодействовать с кодом и контентом.
Автоматизированное тестирование в настоящее время является общепринятой и важной частью инструментария разработчика. Пока я был в Naughty Dog, талантливая инженерная команда студии начала применять смоук-тесты (также известны как тестирование достоверности, сэнити-тесты и тестирование для проверки билда[154]), чтобы убедиться, что у наших новых билдов нет никаких проблем, связанных с памятью и загрузкой уровня. Это гарантировало, что у нашего QA-отдела каждое утро будет билд для проверки без каких-либо критических сбоев.
Учитывая, что разработка игр – это творческая человеко-ориентированная область, я думаю, что автоматическое тестирование вряд ли когда-нибудь полностью заменит тестирование человеком. Однако оно помогает быстрее и тщательнее проверить код на наличие определенных багов и ошибок, поскольку компьютеры хорошо справляются с детализированными, скучными, повторяющимися задачами с безупречной точностью. Я считаю, что машинное обучение поможет нам тестировать наши игры по-новому точно так же, как оно начало творить чудеса в таких областях нашей жизни, как распознавание речи и манипулирование изображениями.
Публичное тестирование
Публичное тестирование – это тот вид тестирования, который мы проводим, выпуская нашу игру для широкой публики до того, как она будет полностью завершена, возможно, в какой-то ограниченной форме. Публичное тестирование будет включать бета-тестирование, тестирование в раннем доступе и выпуск игры на небольшом тестовом рынке до ее глобального релиза.
При публичном бета-тестировании разработчик или издатель игры позволяет широкой публике установить и попробовать игру после майлстоуна бета-версии, но за несколько недель или месяцев до ее полного завершения. (В публичной бета-версии чаще всего выпускается не вся игра целиком, а только ее часть, возможно, демоуровень.)
Разработчики получают множество различных отзывов от публичного бета-тестирования. Они могут перепроверить результаты загрузки своих серверов, чтобы убедиться, что их серверы могут обрабатывать нагрузку в тысячи – или сотни тысяч – игроков, играющих одновременно. Разработчики также могут собрать данные о действиях игроков и при этом проверить, работает ли дизайн игры так, как задумано. Они могут найти проблемы с производительностью, связанные с частотой кадров и задержками, и проблемы с безопасностью. Пользователи ранних версий часто ищут лазейки в защите игры, чтобы посмотреть, смогут ли они ее взломать. Разработчики также могут получить прямую обратную связь от своих публичных бета-тестеров об их опыте точно так же, как мы сделали бы это при формальном тестировании, опрашивая тестеров.
При тестировании раннего доступа игра выпускается – и, возможно, даже продается – до того, как она завершена с точки зрения либо фичей, либо контента. Эта практика сейчас распространена в мире профессионального гейм-дизайна благодаря раннему доступу (Early Access) в Steam и таким платформам, как Itch.io, которые могут использовать разработчики, чтобы привлекать свою аудиторию к процессу создания и разработки раньше, проще и в большем масштабе, чем когда-либо прежде. Публичное тестирование также поможет создать игровое сообщество и пробудить интерес к игре.
* * *
Мы рассмотрели некоторые виды тестирования, и в следующих двух главах подробнее рассмотрим формальное тестирование, которое служит разработчикам ценным инструментом в работе над игрой.
Глава 24
Подготовка к формальным плейтестам
В начале нашего производственного процесса, на этапах формирования идей и препродакшена, мы подходим к дизайну и созданию нашей игры очень свободно и творчески – все структурировано в достаточной степени для принятия верного решения в нужный момент. На этапе продакшена мы не прекращаем работать интуитивно, но – следуя намеченному плану и таблице макродизайна – переходим к более рациональному способу работы.
Сейчас мы находимся на пути к созданию альфа-версии, когда наша игра будет завершена с точки зрения ее фичей (все основные
Ознакомительная версия. Доступно 26 страниц из 130
