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

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

Если играется хорошо, стоит попробовать собрать прототип в простой игровой системе. С помощью готового игрового движка, разработка на котором будет наименее затратной, проверяем, насколько интересны придуманные нами игровые механики, полностью пренебрегая графикой. На этом этапе стараемся использовать максимум готовых решений: программы и низкоуровневые движки, которые позволяют быстро скомпоновать из ассетов базовый геймплей. Если игра планируется на Unreal Engine 4, прототип для нее все равно вполне можно собирать с помощью Game Maker и аналогичных программ, главное – быстро, просто и дешево; лучше использовать знакомые инструменты, чтобы не тратить время на изучение новых.

Для создания прототипов можно использовать и чисто графические методы (Flash, Figma и пр.), тогда эта работа ложится на плечи художника-дизайнера. Этот метод подходит для игр, где важно проверить, например, как решения игрока влияют на геймплей (в какую сторону он отправился, какой вариант в ветке диалогов выбрал и прочее).

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

Когда вы проверяете какие-то инновационные идеи, которые нельзя найти в Unity или Unreal Engine, задача усложняется. Есть несколько вариантов решения этой проблемы.

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

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

МАТЕМАТИЧЕСКИЕ ПРОТОТИПЫ создают, чтобы убедиться, правильно ли работают математические расчеты. Причем методы могут быть вообще не связаны с реальной игрой, а работающий над ними специалист может обладать знаниями скорее в области математики, нежели гейм-дизайна.

Чтобы создать АРТ-ПРОТОТИП, необходимо проанализировать игры, которые мы считаем конкурентами, и оценить стандарты индустрии для выбранного жанра. Причем не только сегодня, но и на момент предполагаемого выхода игры. После этого арт-директор и технический художник (или кто-то, выполняющий их функции) принимают решение, графику какого качества мы хотим обеспечить в нашей игре.

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

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

Такие ТЕХНИЧЕСКИЕ ПРОТОТИПЫ проверяют производительность или технические идеи. В первом варианте методы те же, что и с арт-прототипом, – собрать сложную, нагруженную сцену и посмотреть, как все работает на целевом железе. Это необходимо для понимания, насколько мы сможем оптимизировать игру к моменту запуска. Особенное внимание здесь уделяют сложным сущностям: большому количеству однотипных объектов в кадре, сложным анимационным системам, разрушаемым объектам.