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

☉ Когда разработчик думает, что исправил баг, он помечает его как «Исправлен» и передает обратно в QA-отдел для проверки, действительно ли баг устранен.

• Невозможно воспроизвести

☉ Если разработчик не может воспроизвести баг, он меняет его статус и передает обратно в QA-отдел для проверки. Отдел обеспечения качества проверяет, воспроизводится ли все еще этот баг.

• Дубликат

☉ Багу присваивается этот статус, если он уже есть в базе данных с другим номером.

• Не исправлен

☉ Если во время проверки баг, помеченный как «Исправлен», на самом деле не был устранен, он помечается как «Не исправлен» и возвращается разработчику, который над ним работал, или его руководителю.

• Подтвержден

☉ Если во время проверки баг, помеченный как «Исправлен», действительно оказывается устранен, он получает статус «Подтвержден» и отправляется на большое райское кладбище ошибок.

• Закрыт (нельзя исправить)

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

• Закрыт (отклонен)

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

• Повторно открыт

☉ Иногда баг, который был закрыт, снова открывается, и тогда он помечается таким образом.

Приложения

Зачастую к отчету стоит добавить скриншоты или видеоролики, иллюстрирующие баг.

Примечания

Раздел примечаний к багу – это хороший способ передавать информацию между QA-отделом и командой разработчиков. Например, когда запрашивается дополнительная информация о баге или когда баг помечен как «Не исправлен».

Примечания к исправлению

Если есть что-то особенное в том, как был исправлен баг, или если баг по какой-либо причине закрыт, надо написать об этом в этом разделе.

* * *

Как вы, вероятно, можете судить по этим заголовкам, жизненный цикл бага выглядит следующим образом.

• Баг обнаруживается QA-отделом или одним из разработчиков в команде.

• Баг назначается разработчику для исправления, тот подтверждает, что получил его, и приступает к работе.

• Разработчик пытается исправить баг.

• Когда разработчик думает, что исправил его, он делает пометку «Исправлен».

• Затем баг возвращается в QA-отдел для проверки, был ли он исправлен.

• В зависимости от результатов проверки баг помечается либо как «Подтвержден», либо как «Не исправлен».

• Если разработчику требуется дополнительная информация, он не может воспроизвести баг или обнаруживает, что это дубликат, он помечает его соответствующим образом и возвращает в QA-отдел.

• Если разработчик не может исправить баг, он сообщает об этом своему менеджеру или руководителю группы. Затем баг передается другому разработчику, который может его исправить, или же закрывается.

Этот простой метод отслеживания багов на основе электронных таблиц будет полезен для небольших проектов и даст вам знания, необходимые для работы со специальными системами баг-трекинга в более крупной команде. Однако вы быстро обнаружите, что отслеживать баги в электронной таблице неудобно, а потому я рекомендую вам найти и использовать инструмент управления проектами с функцией отслеживания багов. Мередит Холл дает хороший обзор таких функций в различных инструментах управления проектами, с которым вы можете ознакомиться в ее статье Choosing a Project Management Tool for Game Development[167] («Выбор инструмента управления проектами для разработки игр») для Gamasutra.

* * *

Теперь, когда вы знаете, как отслеживать ошибки, вы готовы приступить к работе над альфа-версией вашего проекта. Мы вернемся к теме исправления багов в главе 32. Вооружившись информацией об альфа-фазе, давайте подробно рассмотрим альфа-майлстоун и то, как мы будем его достигать.

Глава 28 Майлстоун альфа-версии

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

Фичи и контент

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

Проиллюстрируем эту идею примерами.