6. Release. Это готовая версия игры, которую размещают на площадках распространения игрового контента (например, в магазинах игр). Дефектов в ней должно быть минимальное количество, хотя, как мы помним, найти все баги невозможно.
Также нужно помнить, что игровые подсистемы разрабатываются постепенно и могут интегрироваться между собой на разных этапах неодновременно. Так что, если говорить о подходе к проверкам, тестировщику нужно обязательно планировать проведение модульного (компонентного, юнит) тестирования для тестирования отдельных игровых подсистем и даже частей внутри их, интеграционного тестирования для обнаружения ошибок в интерфейсах взаимодействия и системного тестирования, когда мы тестируем целиком продукт на разных стадиях его развития.
Для лучшего понимания сути давай посмотрим на то, как создаются и тестируются игры типа Angry Birds. Чтобы продемонстрировать суть игры, нам не нужны модели (в данном случае изображения) птиц, свиней и игровых ассетов. Всю игровую механику мы можем запрограммировать, используя геометрические фигуры разного цвета: красный круг, который увеличивает скорость при тапе по экрану, белый овал, из которого при тапе по экрану будет вываливаться другой круг с эффектом бомбы, и т. д. Также мы можем запрограммировать свойства всех строительных материалов: льда, дерева и камня. В это же время нашему художнику параллельно процессу программирования и независимо от него нужно нарисовать спрайты анимаций птиц в трех разных состояниях: обычном, слегка поврежденном и сильно поврежденном. На этом же этапе мы можем провести проверку и программной части, и моделей независимо друг от друга. А затем просто заменить красный круг в игровом движке на спрайты красной злой птицы. Нам останется только проверить, не возникло ли каких-либо дефектов при такой интеграции. Потом мы добавим и синхронизируем с действиями персонажей и объектов на сцене звуки. А после этого мы можем проводить тестирование игры как полноценной системы.
Пример программирования физики и коллизий без реальных моделей персонажей
Чем раньше появилась и была пропущена ошибка, тем больше вероятность того, что на более поздних этапах она вызовет большее количество проблем. Еще раз: тестирование нужно начинать как можно раньше.
Post-Production. На этом этапе нужно исправлять баги, которые находят пользователи, пока команда разработки продолжает работу по поддержке проекта. Если планируется выпускать дополнительный загружаемый игровой контент, тестировщику надо приготовиться к проведению повторного и регрессионного тестирования.
Хотелось бы сказать еще несколько слов о наиболее часто возникающих причинах возникновения дефектов или ситуаций, этому способствующих.
Пара причин уже называлась выше: например, отсутствие коммуникации или неправильная коммуникация между участниками разработки проекта. Чтобы понять, где в процессе коммуникации может искажаться или теряться информация, давай взглянем на этот процесс немного пристальнее.
Стандартная модель коммуникации выглядит примерно так:
Адресант – это тот, кто передает сообщение, а адресат – тот, кто его получает. В процессе общения эти роли постоянно меняются, поскольку коммуникация – это не только передавать сообщение (например, говорить), но и получать его (слушать). Если человек не меняет роли, то коммуникация осуществляется с трудом или не осуществляется вовсе, поскольку для принятия решений требуется получение информации извне и ее критическая обработка. Отсутствие коммуникации приводит к возникновению ошибок, о которых я говорил в случае с рисованием дракона.
Не менее важны другие атрибуты коммуникации. Для передачи сообщения требуется канал. Это может быть разговор с глазу на глаз, письмо по электронной почте, сообщение в мессенджере, запись на доске, задача в баг-трекере и т. д. Если нам недоступен канал, то недоступны и сообщения, что автоматически приводит к невозможности коммуникации. Вот почему программисты и тестировщики используют ПО, обеспечивающее совместную работу над разрабатываемым продуктом.
Кодер/декодер есть у каждого участника коммуникации. Этот удивительный «прибор» позволяет нам облекать наше сообщение в понятную собеседнику форму, а ему «дешифровать» его. К этому понятию могут относиться одновременно разные вещи. Это может быть, например, язык общения, причем в самом широком смысле.
Если я вдруг, без предупреждения, перейду на эльфийский, то наверняка это вызовет у тебя некоторое недоумение, поскольку ты тут же перестанешь понимать, о чем идет речь. С другой стороны, если бы профессор астрофизики рассказал нам с тобой краткую историю теории струн, то мы бы наверняка долго пытались понять, как это возможно – хорошо понимать отдельные слова, но терять смысл сказанного, когда слова соединяются в предложения. Таким образом, кодер/декодер – это нечто, что позволяет нам облекать свои сообщения в форму, понятную нашему собеседнику, в том числе и учитывая уровень его знаний и развития.
Сообщения передаются в какой-то среде, которая зачастую наполнена помехами. Это могут быть настоящие помехи на канале радиосвязи, из-за которых твой собеседник не слышит тебя и не понимает сути того, что ты стремишься сказать. А могут быть и более «хитрые» – например, слухи, которые распускают конкуренты для того, чтобы дезинформировать вашу команду и заставить сделать неправильные шаги.
Чтобы избежать ошибок, возникающих из-за недопонимания между сотрудниками, неправильно переданной или понятой информации, важно не только передать сообщение, но и убедиться в том, что наш собеседник его принял и понял.
Другой причиной возникновения дефектов можно назвать частые изменения в требованиях. Разработка видеоигр – это очень динамичная область. Изменениями требований там никого не удивить. Генерируются новые идеи, которые необходимо быстро воплощать, чтобы добиться успеха на рынке. Даже модели разработки, которые применяются в работе, как правило, относятся к виду Agile и «заточены» как раз под постоянные изменения. Но создание требований в цикле разработки идет раньше реализации их в программном коде. А это значит, что, пытаясь адаптировать код к новым требованиям (чтобы не начинать реализацию каждый раз с самого начала), мы сами создаем условия для возникновения ошибок, потому что создаем или меняем функционал, который интегрируется с уже существующим. И нам при этом нужно очень внимательно проверять то, что получилось в итоге и особенно те области ранее проверенного кода, которые не содержали дефектов, – то есть постоянно проводить регрессионное тестирование.
Важно убедиться, что собеседник тебя хорошо понимает
В некоторых ситуациях, когда забывают сообщить об изменениях, это может стать фатальным
Какой вывод можно сделать? Необходимо постоянно тестировать измененные требования, чтобы не упустить момент, когда ошибки в них станут причиной ненужности реализованного функционала, хотя в его коде нет ошибок.
Еще одна причина появления дефектов в игровом продукте – ошибки разработчиков. Мы все люди, и нам свойственно ошибаться. Попробуй просто печатать пару страниц текста, например текста этой книги, в редакторе. Я поячти на 100 % уверрен, что в тектсе будут содержаться опечатки. А программист пишет сотни строк кода каждый день, пытаясь реализовать игровую логику, да еще оптимально использовать вычислительные ресурсы PC игрока.
Другие ошибки программистов: невнимательность и недостаток знаний, низкая культура написания кода, слабый контроль версий создаваемого продукта, неверный выбор инструментов разработки. Все они могут привести к возникновению ситуации для появления дефектов в программном коде на любой стадии разработки игрового продукта.
Помимо программистов над игрой трудится куча людей, и все они тоже могут делать ошибки.
1. «Графики» – 3D-моделлеры, риггеры, скиннеры, аниматоры, художники – занимаются реализацией графической части, одной из важнейшей в любой игре, воздействующей на игрока через органы зрения.
2. «Звуковики» – звукоинженеры, композиторы, аудиодизайнеры спецэффектов, аудиопрограммисты, актеры озвучки – полностью погружены в процесс формирования звуковой подсистемы игры, записывая и внедряя в игровой процесс все необходимые звуки.
3. Специалисты по уровням – левел-дизайнеры – обеспечивают работу игровых механик на различных уровнях. Для простоты понимания – это, например, ответы на вопрос, куда персонаж может прыгнуть на уровне, а где этого делать не стоит.
4. Специалисты по искусственному интеллекту – это программисты, разрабатывающие алгоритмы для неигровых персонажей или врагов, чтобы сделать их поведение естественным. Например, стражник не может видеть твоего персонажа, который находится у него за спиной, не может видеть в темноте без специального оборудования, не должен проявлять агрессию, если персонаж не вооружен. Поведение животных также должно отличаться от поведения людей и т. д.
5. Специалисты по локализации – переводчики, консультанты, эксперты – занимаются адаптацией игрового продукта для адекватного восприятия его представителями разных культур или обеспечивают игровым событиям и объектам историческую достоверность и схожесть с реальным прототипом.
Именно поэтому при тестировании игр выделяются главные подсистемы, реализующие важнейший игровой функционал, и именно их проверке уделяется самое пристальное внимание.
Ситуации, которые могут стать причинами и первопричинами появления дефектов, могут возникать на разных этапах разработки игрового проекта. Чем раньше это происходит, тем существеннее может быть влияние дефекта на развитие проекта. А в некоторых случаях такой дефект может привести к невозможности реализовать проект. На рисунке ниже представлена обобщенная информация о том, насколько критичны и к каким последствиям могут приводить дефекты, возникающие на ранних стадиях проекта.