Вячеслав Уточкин – Хочу в геймдев! Основы игровой разработки для начинающих (страница 16)

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

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

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

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

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

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

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

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

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

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

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

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

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

Совершенно иначе обстоит дело, если мы хотим показать прототип широким массам. Чтобы отзывы были честными, зачастую не имеет смысла указывать, что это наша первая игра, над которой мы год трудимся в одиночку в гараже и на «Дошираке». Да, придется столкнуться с непониманием того, что это всего лишь прототип, половина функций пока недоступна и, вообще, «в GTA-5 графика круче». Но если обозначить все известные проблемы и попросить не обращать на них внимания, получить адекватную комплексную оценку будет невозможно. Так что придется стиснуть зубы, спокойно принять все отзывы, предупредив, что сейчас вы демонстрируете именно прототип, не проверяете качество графики, а лишь, например, хотите узнать мнение о core-геймплее.

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

Прототипы очень редко показывают журналистам и стримерам. Первое впечатление очень трудно исправить, поэтому нужно четко осознавать, зачем показывается прототип. Но если игра построена на необычной идее и мы планируем привлечь за счет этого много органического трафика[52], чтобы заранее заинтересовать издания или стримеров и начать создавать комьюнити уже на этапе прототипа, это может быть оправданно. Но, так как это еще не полноценный показ, обычно лучше договориться о нераспространении информации.

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

Часто в игровых студиях человек, который презентует проект инвестору, и тот, кто представляет его аудитории, – разные люди, ведь для этого нужны разные навыки.

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

Большинство прототипов не пригодятся вам в будущем. Следует относиться к ним как к получению опыта и знаний; это не конечный продукт, а лишь способ вовремя ответить на важные вопросы о проекте. Цель прототипа – не только проверить гипотезу, но и снять риски. Он помогает собрать все шишки, понять, как не надо делать и какие вещи вызывают наибольшие трудности, набраться опыта и наладить взаимодействие между членами команды, не затрачивая много времени и ресурсов.

Со временем вопросы, на которые должны ответить прототипы, будут становиться все более конкретными. Для отдельных механик подходят бумажные или написанные в простых программах прототипы; чем больше мы приближаемся к проверке полноценного геймплейного взаимодействия, тем сильнее нам нужны игровые движки; в случае же, когда мы проверяем сложную физику, уже не справиться без технического прототипа – часто с артом, созданным на ассетах, близких к реальным. Очень сложно с помощью готовых ассетов проверить, не будет ли, например, игрока укачивать, пока он будет уворачиваться от монстров в нашем VR-шутере. Здесь нельзя обойтись геймплейным прототипом, он не ответит на этот вопрос.