Первый прототип игры: проверка основного цикла

Что такое основной цикл и что именно вы проверяете?

Опишите основной игровой цикл в нескольких строках: что делает игрок, как на это отвечает игра, как он продвигается вперёд и почему ему хочется повторить. Если это не получается записать просто, прототипу будет трудно дать ясный ответ хоть на что-нибудь. Ясный игровой цикл — отправная точка любого проекта разработки игр на заказ.

Затем выберите одну неопределённость, которую прототип должен снять. Это может быть понятность управления, подходящая сложность, темп, который удерживает внимание, или вопрос, приносит ли конкретное действие удовольствие вообще. Один чёткий вопрос даёт гораздо больше, чем смутная надежда, что игра «будет ощущаться хорошо».

Держите играбельный объём настолько маленьким, чтобы можно было несколько раз понаблюдать, как в него играют. Финальная графика, большой сюжетный мир и множество уровней делают прототип дороже, но не помогают понять, работает ли основная механика. На этом этапе серые блоки вместо моделей и временные звуки — совершенно нормальное решение.

Стоит также сразу решить, чем прототип не является. Это не вертикальный срез, не презентационный ролик и не техническая демонстрация движка. У каждого из них своё место, но если смешать их в первом прототипе, вопрос размывается, а каждая итерация идёт медленнее.

Как наблюдать за игроками?

Подготовьте короткую сессию с понятной целью и отмечайте, где игроки медлят, неверно понимают реакцию игры или бросают играть. Особенно ценны игроки не из команды: сама команда уже знает, как всё должно работать, и не замечает того, что непонятно новичку.

Не поддавайтесь желанию объяснять каждое действие. Если вы проверяете, понятна ли игра без подсказок, каждая подсказка скрывает именно ту проблему, которую вы ищете. Вопросы лучше задать после сессии. Короткая анкета после каждой сессии — с одними и теми же несколькими вопросами — помогает сравнивать ответы разных игроков. Если есть возможность, записывайте экран и руки игрока: видео часто показывает то, что человек не может сформулировать словами.

Рядом с заметками записывайте устройство, способ управления и версию сборки — иначе потом будет неясно, к какой версии относится замечание. Затем отделите личные вкусы («мне бы хотелось другой цвет») от проблем, которые повторяются в нескольких сессиях, и решите, какая гипотеза заслуживает следующего изменения.

Когда прототип можно расширять?

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

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

Итог хорошего прототипа — играбельное взаимодействие и записанное решение; короткий дизайн-документ игры держит и то и другое в одном месте. Это ещё не значит, что полная игра готова к производству: до этого нужно как следует спланировать сам этап производства. Зато к его началу команда уже знает, на чём держится игра и что в ней стоит развивать. А если данные говорят «останавливаемся», это тоже полноценный результат: прототип сэкономил стоимость полной игры, построенной вокруг идеи, которая не работает.