Хочу в геймдев!

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

По ходу любой разработки приходят новые идеи и их решения, так что запросы к технической части обычно растут. Здесь есть две крайности, из-за которых могут появиться проблемы. Делая все только по ТЗ и не учитывая возможное расширение функционала, можно столкнуться с ситуацией, когда любое отклонение повлечет за собой коллапс и необходимость переделывать все сначала. Лучше заранее предусмотреть возможность расширения, например, максимального количества участников сессии, или слотов персонажа, или других множимых сущностей.

С другой стороны, стараясь сразу создавать максимальные возможности для любых задумок гейм-дизайнеров или для миллиарда онлайн-игроков, вы, скорее всего, потратите время и силы на нечто, что никогда не будет реализовано. Поэтому, чтобы придерживаться золотой середины, следует провести исследование, выслушать все запросы других специалистов и, проанализировав данные, умножить требования, к примеру, вдвое.

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

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

Прежде чем запускать полноценный продакшен, имеет смысл протестировать и ПРОТОТИП ИНТЕРФЕЙСА. Его также можно собрать на базе Figma, Flash или другой программы, помогающей предварительно оценить удобство и доступность интерфейса. Его можно собрать даже с помощью бумажных прототипов, хотя это более опасный путь, чем в случае с геймплейными прототипами, так как в этом вопросе большую роль играют именно ощущения. Лучше проводить тесты с реальными размерами, разрешениями и артом, чтобы проверить, как это будет выглядеть в конечном продукте.

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

Например, главная часть интерфейса гиперказуальных[50] игр – это управление. Эти простые по своей сути продукты, сделанные в первую очередь для нон-геймеров[51], должны предоставить игроку максимально простое и понятное управление. Понятность заключается в использовании исключительно знакомых жестов: это прокручивание, как у ленты мобильных версий социальных сетей, например Instagram, это листание в стороны, клики и удержание касания. Непривычные пользователям жесты, типа двойного клика или многоходового использования кнопок, сильно усложняют продукт для казуальной аудитории.

Что же касается термина «простота в управлении» для гиперказуальных игр, то здесь имеется в виду однокнопочность управления и возможность играть в любом месте. Для этого мы используем вертикальную ориентацию экрана, привычную по мессенджерам. А также не требуем совершать составных действий. К примеру, считается хорошим тоном использовать в игре только одно из двух действий: прицеливание или выстрел. То есть либо игра прицеливается автоматически, а игрок решает, когда стрелять, либо игра стреляет постоянно автоматически, а пользователь лишь выбирает цели.

Будет вполне логично, если ваша команда станет работать над геймплейным, художественным и техническим прототипом одновременно.

КОМУ ПОКАЗЫВАТЬ ПРОТОТИП

Любой прототип, кроме совсем технических, должен помочь понять, какие ощущения вызывает игра, но во многом они субъективны. Без UX-тестирования довольно трудно отследить, в каком месте игроки могут столкнуться с затруднениями. И здесь очень важен выбор, на ком тестировать еще не готовый продукт.