А если еще и гейм-дизайнер на этом же этапе отдаст в работу игровую механику, недостаточно полно продумав и описав ее функционал, то программист может реализовать ее на свое усмотрение.
То есть даже на ранних этапах, когда мы обсуждаем концептуальные вещи, могут появляться ошибки из-за неправильно поставленной задачи или отсутствия коммуникации. И если эту ошибку не заметить и не исправить, то неправильно сделанная механика будет добавлена в игру, а набросок персонажа превратится в анимированную в игровом движке модель, прежде чем кто-то обратит внимание, что хотели сделать совсем не так. Все ресурсы были потрачены впустую, и работу нужно делать заново.
Первопричины условий, в которых появляются дефекты, могут относиться к самым ранним этапам. Поэтому даже концепции и гипотезы, особенно связанные с поиском ответа на вопросы «Зачем мы это делаем?» и «Кому это нужно?», требуют тестирования. Впрочем, я уже говорил о том, что раннее тестирование серьезно экономит время и деньги.
Создание прототипа на этой же стадии нужно не только для того, чтобы продемонстрировать вашу идею инвестору, но и чтобы как следует протестировать ее. Большинство идей хоронятся как раз на этом этапе, поскольку не проходят тестирование и не дают нам ответа на вопрос: «Является ли идея рабочей и стоит ли это пытаться реализовать?» Хотя инвестор – как раз тот человек, который способен протестировать вашу идею и прототип беспристрастно и очень профессионально, ведь на кону будут стоять его деньги.
Production (Производство). Это самый длительный этап, связанный с непосредственной разработкой игрового проекта. На этой стадии в проект может быть вовлечено большое количество специалистов, которые будут заняты реализацией тех игровых подсистем, о которых я рассказывал в Главе 1. На всех этапах разработки (в разных компаниях этапы могут добавляться или отсутствовать), особенно самых ранних, нужно тщательно следить за выявлением наиболее критичных для проекта дефектов.
1. Prototype. О нем мы говорили выше. Это быстрая, черновая реализация базового геймплея для демонстрации заинтересованным лицам и дальнейших исследований, улучшений и проверок различных гипотез.
2. FPP (First Playable Product). В отличие от прототипа, дает гораздо лучшее представление о внешнем виде и игровом процессе. Конечно, он очень далек от финальной версии, но в нем «заглушки» уже заменяются нормальными моделями, добавляются интересные детали.
3. Vertical slice. Это фактически демоверсия игрового продукта, фрагмент игры. Играя в него, можно понять, как будет выглядеть игра целиком и какие механики в ней будут использованы. Как правило, такой продукт используется в маркетинговых целях или для представления инвесторам.
4. Alpha. Это готовая игра, где реализованы все игровые механики. Хотя некоторые модели в альфе могут быть заменены временными заглушками, в нее можно играть от начала и до конца. Тестировщики на этом этапе прилагают особые усилия, чтобы отследить самые критичные баги, плотно работая с программистами. Но многие команды разработки считают, что нет ничего страшного, если этот этап сдается с критическими дефектами.
5. Beta. Это еще более продвинутая альфа-версия игры, но на этом этапе разработчики часто сосредотачиваются на оптимизации продукта, а не на добавлении новых функций. Они стараются устранить максимальное количество известных багов, часто вовлекая в ее тестирование большое количество людей, перед выпуском игры. Часто к бета-тестированию в качестве тестировщиков привлекают обычных игроков. Этот этап может быть сдан с дефектами, которые могут считаться значительными.
6. Release. Это готовая версия игры, которую размещают на площадках распространения игрового контента (например, в магазинах игр). Дефектов в ней должно быть минимальное количество, хотя, как мы помним, найти все баги невозможно.
Также нужно помнить, что игровые подсистемы разрабатываются постепенно и могут интегрироваться между собой на разных этапах неодновременно. Так что, если говорить о подходе к проверкам, тестировщику нужно обязательно планировать проведение модульного (компонентного, юнит) тестирования для тестирования отдельных игровых подсистем и даже частей внутри их, интеграционного тестирования для обнаружения ошибок в интерфейсах взаимодействия и системного тестирования, когда мы тестируем целиком продукт на разных стадиях его развития.