Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан
Как вы, вероятно, можете судить по этим заголовкам, жизненный цикл бага выглядит следующим образом.
• Баг обнаруживается QA-отделом или одним из разработчиков в команде.
• Баг назначается разработчику для исправления, тот подтверждает, что получил его, и приступает к работе.
• Разработчик пытается исправить баг.
• Когда разработчик думает, что исправил его, он делает пометку «Исправлен».
• Затем баг возвращается в QA-отдел для проверки, был ли он исправлен.
• В зависимости от результатов проверки баг помечается либо как «Подтвержден», либо как «Не исправлен».
• Если разработчику требуется дополнительная информация, он не может воспроизвести баг или обнаруживает, что это дубликат, он помечает его соответствующим образом и возвращает в QA-отдел.
• Если разработчик не может исправить баг, он сообщает об этом своему менеджеру или руководителю группы. Затем баг передается другому разработчику, который может его исправить, или же закрывается.
Этот простой метод отслеживания багов на основе электронных таблиц будет полезен для небольших проектов и даст вам знания, необходимые для работы со специальными системами баг-трекинга в более крупной команде. Однако вы быстро обнаружите, что отслеживать баги в электронной таблице неудобно, а потому я рекомендую вам найти и использовать инструмент управления проектами с функцией отслеживания багов. Мередит Холл дает хороший обзор таких функций в различных инструментах управления проектами, с которым вы можете ознакомиться в ее статье Choosing a Project Management Tool for Game Development[167] («Выбор инструмента управления проектами для разработки игр») для Gamasutra.
* * *Теперь, когда вы знаете, как отслеживать ошибки, вы готовы приступить к работе над альфа-версией вашего проекта. Мы вернемся к теме исправления багов в главе 32. Вооружившись информацией об альфа-фазе, давайте подробно рассмотрим альфа-майлстоун и то, как мы будем его достигать.
Глава 28
Майлстоун альфа-версии
В предыдущей главе мы обсудили альфа-фазу нашего проекта и методы баг-трекинга. Теперь давайте посмотрим на майлстоун альфа-версии, который знаменует конец альфа-фазы. На этапе альфы все фичи уже присутствуют в игре, иначе говоря, в игре представлены все функциональные возможности. В этом цель альфа-фазы для большинства видов разработки программного обеспечения, от игр до бизнеса. Чтобы игра достигла альфа-майлстоуна, мы должны внедрить в нее все фичи и все уровни финальной игры – вскоре мы обсудим это подробнее.
Фичи и контент
Давайте подробнее рассмотрим само слово фича и что оно означает. Мы могли бы сказать, что в играх две составляющие: фичи и контент. Вообще говоря, фича – это элемент функциональности игры. Механизмы, благодаря которым игра работает. Если что-то в игре управляется логикой или реагирует на действие игрока, скорее всего, это фича.
Проиллюстрируем эту идею примерами.
• Фича, которая управляет персонажем игрока в ответ на вводимые игроком данные в экшен-игре.
• Фича, которая управляет неигровыми персонажами (NPC), когда те занимаются своими делами в игровой среде игры-симулятора.
• Фича, которая определяет, что происходит со зданием с течением времени, в симуляторе городского строительства.
Фичи более высокого порядка, подобные приведенным выше, обычно можно разбить на фичи более низкого порядка.
• Фича управления персонажем игрока может состоять из отдельных фич, которые управляют бегом и прыжками.
• Фича управления NPC может состоять из отдельных фич, которые управляют ходьбой, переносом предметов из одного места в другое и разговором с персонажем игрока.
• Фича, определяющая, что происходит со зданием с течением времени, может состоять из отдельных фич, определяющих, когда здание загрязняется, разрушается или загорается.
Мы могли бы продолжать разбивать эти фичи и дальше, пока не доберемся до конкретных функций в коде, которые воздействуют на структуры данных, представляющие эти игровые объекты.
А контент – это структуры данных и ассеты, составляющие игровые объекты, на которые воздействуют фичи игры: арт, анимация, звуковые эффекты, визуальные эффекты, музыка и диалоги, и это лишь часть набора данных. Конечно, у вас не может быть фичей без контента. Если вы запрограммировали систему для перемещения NPC по игровому миру, но не создали арт, анимацию и звуки этого NPC, этой фичи на самом деле в игре нет. Контент часто помогает функциям проявляться в игровом мире, и размытая грань между фичами и контентом иногда может привести разработчиков игр к неприятностям, как мы увидим позже.
Полнофункциональность
Когда все фичи игры реализованы и исправно работают, игру можно считать полнофункциональной (feature complete). Этого проще добиться, если разрабатывать игру концентрически, тестируя все новое и исправляя баги по ходу дела.
Когда игра полностью завершена с точки зрения фич, в ней должно присутствовать все, что будет в конечной игре, будь то разговоры между NPC и игроками, логические головоломки, боевая механика или алгоритмы поиска пути ИИ. Если вы хотите внедрить какой-то механизм, то он должен быть в игре к альфа-майлстоуну.
Однако по мере приближения к майлстоуну разработчики часто сталкиваются с непреодолимым масштабом задач, поскольку перед ними цель реализовать все «движущиеся части» игры. Вот тут разработчики могут воспользоваться размытостью границ между фичами и контентом, что может привести как к положительным результатам (если разумно их использовать), так и к весьма плачевным.
За время своей работы в игровой индустрии я узнал от коллег, что к альфе у вас должно быть хотя бы по одному элементу всего того, что вы хотите
