Ознакомительная версия. Доступно 11 страниц из 52
систему, можно попробовать использовать наработки предшественников. Допустим, вы хотите добавить в игру механику осады замков. Чтобы оценить, впишется ли фича в игру, уже многое должно быть готово (боевая система, прокачка персонажей). Создавать целую игру, чтобы проверить одну фичу, долго и неэффективно. Стоит постараться найти движок наиболее похожей игры и «прикрутить» туда нужный функционал.
Другая ситуация: сложный технический запрос. Например, гейм-дизайнер задумал сделать жидкого персонажа, который должен правдоподобно перетекать, менять форму, иметь определенные способности и адекватно взаимодействовать с более привычными героями. Такого с помощью готовых решений не соберешь, подыскать подходящую программу может быть проблематично. Обычно над такими нетривиальными задачами трудится отдельный программист, задача которого – максимально быстро написать код нужной нам системы. Такой прототип не ответит на вопрос о стабильности решения или совместимости с полноценным движком, просто нужно в сжатые сроки сформировать и оценить задуманный геймплей.
МАТЕМАТИЧЕСКИЕ ПРОТОТИПЫ создают, чтобы убедиться, правильно ли работают математические расчеты. Причем методы могут быть вообще не связаны с реальной игрой, а работающий над ними специалист может обладать знаниями скорее в области математики, нежели гейм-дизайна.
Чтобы создать АРТ-ПРОТОТИП, необходимо проанализировать игры, которые мы считаем конкурентами, и оценить стандарты индустрии для выбранного жанра. Причем не только сегодня, но и на момент предполагаемого выхода игры. После этого арт-директор и технический художник (или кто-то, выполняющий их функции) принимают решение, графику какого качества мы хотим обеспечить в нашей игре.
Принципиальное отличие от геймплейных прототипов состоит в том, что даже на раннем этапе, когда еще может не быть проработана игровая логика, арт-прототип нужно делать на выбранном движке. Если вы сумели продемонстрировать запрашиваемый уровень графики на CryEngine, нет никаких гарантий, что такую же картинку покажет Unreal Engine 4. Проблемы на данном этапе вполне могут быть аргументом для того, чтобы отказаться от одного движка в пользу другого.
В результате принятых решений необходимо создать арт-прототип – демонстрационную сцену. В зависимости от поставленных задач мы таким образом проверяем, могут ли наши художники красиво нарисовать нужную картинку, или, при другом подходе, оцениваем технические возможности нашего движка, сделав высокополигональную[49], но при этом совершенно необязательно красивую, модель.
Такие ТЕХНИЧЕСКИЕ ПРОТОТИПЫ проверяют производительность или технические идеи. В первом варианте методы те же, что и с арт-прототипом, – собрать сложную, нагруженную сцену и посмотреть, как все работает на целевом железе. Это необходимо для понимания, насколько мы сможем оптимизировать игру к моменту запуска. Особенное внимание здесь уделяют сложным сущностям: большому количеству однотипных объектов в кадре, сложным анимационным системам, разрушаемым объектам.
Технические прототипы создаются также для отработки конкретной технической части игры, например сетевого протокола. Допустим, нам нужно проверить, как ведет себя игра при медленном интернете или на слабом компьютере. Для проверки многих технических составляющих существуют готовые решения, так что нет необходимости ехать к бабушке в деревню в поисках старого компьютера или плохого интернет-соединения.
По ходу любой разработки приходят новые идеи и их решения, так что запросы к технической части обычно растут. Здесь есть две крайности, из-за которых могут появиться проблемы. Делая все только по ТЗ и не учитывая возможное расширение функционала, можно столкнуться с ситуацией, когда любое отклонение повлечет за собой коллапс и необходимость переделывать все сначала. Лучше заранее предусмотреть возможность расширения, например, максимального количества участников сессии, или слотов персонажа, или других множимых сущностей.
С другой стороны, стараясь сразу создавать максимальные возможности для любых задумок гейм-дизайнеров или для миллиарда онлайн-игроков, вы, скорее всего, потратите время и силы на нечто, что никогда не будет реализовано. Поэтому, чтобы придерживаться золотой середины, следует провести исследование, выслушать все запросы других специалистов и, проанализировав данные, умножить требования, к примеру, вдвое.
Технические прототипы также часто нужны, чтобы понять, сможем ли мы реализовать ту или иную физическую модель. Физика в играх – вещь для игроков сама собою разумеющаяся: мало кто задумывается о том, как непросто воссоздать реалистичное взаимодействие разных предметов. Скажем, мы хотим, чтобы в нашей игре была возможность честно топить предметы в воде. Необходимо проверить, можем ли мы написать физическую модель, при которой предметы различной массы и плотности станут по-разному тонуть.
Арт и технические прототипы часто объединяют, чтобы убедиться, что, с учетом имеющихся у нас ресурсов, можно создать красивую картинку необходимого качества. Здесь нет никакого геймплея: важно проверить, что самые тяжелые и сложные модели, виды освещения, разные ракурсы и т. д. смотрятся органично, воспроизводятся, как задумано, и ничего не ломают.
Прежде чем запускать полноценный продакшен, имеет смысл протестировать и ПРОТОТИП ИНТЕРФЕЙСА. Его также можно собрать на базе Figma, Flash или другой программы, помогающей предварительно оценить удобство и доступность интерфейса. Его можно собрать даже с помощью бумажных прототипов, хотя это более опасный путь, чем в случае с геймплейными прототипами, так как в этом вопросе большую роль играют именно ощущения. Лучше проводить тесты с реальными размерами, разрешениями и артом, чтобы проверить, как это будет выглядеть в конечном продукте.
Прототипы интерфейсов имеют другие задачи. Прежде всего, тестируется возможность реализации всех задумок в рамках одного экрана, насколько удобно и красиво выглядят наши решения. Во-вторых, проверяем, правильно ли игрок понимает расставленные дизайнерами акценты, насколько просто и быстро он находит нужные ему функции. И, в-третьих, нужно убедиться, не вызывают ли наши решения ненужные паттерны поведения у игрока.
Например, главная часть интерфейса гиперказуальных[50] игр – это управление. Эти простые по своей сути продукты, сделанные в первую очередь для нон-геймеров[51], должны предоставить игроку максимально простое и понятное управление. Понятность заключается в использовании исключительно знакомых жестов: это прокручивание, как у ленты мобильных версий социальных сетей, например Instagram, это листание в стороны, клики и удержание касания. Непривычные пользователям жесты, типа двойного клика или многоходового использования кнопок, сильно усложняют продукт для казуальной аудитории.
Что же касается термина «простота в управлении» для гиперказуальных игр, то здесь имеется в виду однокнопочность управления и возможность играть в любом месте. Для этого мы используем вертикальную ориентацию экрана, привычную по мессенджерам. А также не требуем совершать составных действий. К примеру, считается хорошим тоном использовать в игре только одно из двух действий: прицеливание или выстрел. То есть либо игра прицеливается автоматически, а игрок решает, когда стрелять, либо игра стреляет постоянно автоматически, а пользователь лишь выбирает цели.
Будет вполне логично, если ваша команда станет работать над геймплейным, художественным и техническим прототипом одновременно.
КОМУ ПОКАЗЫВАТЬ ПРОТОТИП
Любой прототип, кроме совсем технических, должен помочь понять, какие ощущения вызывает игра, но во многом они субъективны.
Ознакомительная версия. Доступно 11 страниц из 52
