Прототипирование игр: теория и практика

Сергей Азаров
Некоторое время работал программистом в различных неигровых компаниях, затем как руководитель/геймдизайнер в компаниях Destiny Games и Step Creative Group. В данный момент работает в компании "Новый Диск" на должности геймдизайнера, совмещая ее с руководством отделом разработки аркадных игр.

> Демо-версия программы для прототипирования, о которой идет речь в статье (2.88 Мб)

Введение

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

Теория

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

Для начала немного терминологии.

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

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

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

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

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

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

• Риск неиграбельности фичи. Стандартный риск, который может возникнуть на любом этапе разработки. Как правило, он относится к новаторским feature. Вероятность возникновения этого риска практически напрямую зависит от опытности геймдизайнера, поэтому реализация в прототипе креативных feature для молодых и неопытных является практически обязательным действием.
• Риск безынтересности фичи в плане игрового процесса. Стандартный риск. Как правило, применим к фичам второго порядка (говоря другими словами, второстепенными), но в принципе не исключено и возникновение риска по отношению к основным фичам. Без прототипирования данный риск может проявиться как на стадии first-playable, так и на стадии альфа версии, что довольно сильно может повлиять на сроки появления бета-версии.
• Риск усложнения игрового процесса за счет внедрения фичи. Весьма распространенный риск среди геймдизайнеров, проявляется исключительно из-за неконтролируемого потока мыслей. Опять же, данный риск проявляется у более неопытных (хотя и у опытных это тоже может проявиться). Попытка сделать мега-фичу, как правило, приводит к тому, что игровой процесс может стать настолько сложным, что играть в подобную игру смогут только хардкорные игроки после трехкратного прочтения руководства пользователя. Возможно, здесь слегка утрируется проблема, но так становится более понятной суть подобного риска, без прототипирования которого, возможен срыв сроков из-за внесения соответствующих изменений на стадии first-playable или даже более позднем сроке, что еще хуже.
• Риск несовместимости одной фичи с другой. Не сильно распространенный риск, однако, от этого не менее важный. Без геймплей-тестов довольно сложно выявляется. Фактически, определить наличие этого риска будет трудно даже для опытного дизайнера (речь естественно идет не об очевидных вещах, наподобие "стрелять из дробовика и чесать себе спину при этом"). Без прототипирования последствия от срабатывания данного риска могут разниться от степени важности фичи и ее укоренения в игровом процессе.

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

В качестве неиграбельности фичи приведем пример из проекта "Предназначение", в демо-версии которого была реализована такая способность персонажа: используя магию, контролировать положение предмета в пространстве с возможностью кидать его от себя. Однако чтобы кинуть предмет (да или просто его передвинуть), нужно было разве что с бубном не танцевать. Судите сами: для выполнения этого действия нужно было навести курсор на объект, зажать правую кнопку мыши, затем колесом мыши подтянуть предмет к себе и, удерживая правую кнопку мыши, нажать левую. Фактически осуществить это удавалась минимум с расстояния в 30-40 метров. Ближе игрок просто не успевал ничего сделать. Правильной реализацией подобной фичи может служить гравитационная пушка в Half-Life 2.

Примером безынтересной фичи может служить псевдопошаговый бой с автопарированием ударов опять же из проекта "Предназначение". Псевдопошаговость заключалось в том, что персонажи проводили удары друг по другу по очереди (удары главного персонажа контролировал сам игрок), но в реальном времени. При этом защита от ударов производилась автоматически в зависимости от параметров противников. Технически, играть можно, но тривиально не интересно, не было ни драйва, ни чего-то другого, что могло бы заинтересовать игрока. Примером же интересного боя может служить таковой из игры Dark Messiah или, например, консольного God of War.

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

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

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

Продолжим наш разговор о мотивах выбора фич к реализации в прототипе. Не раскрытой осталось тема оценки стоимости подобной реализации. Многие могут подумать, что здесь может действовать классический треугольник Время - Деньги - Качество с фиксацией любых двух вершин. Однако, следуя определению понятия прототипирования о черновой реализации функциональности, вершиной Качество можно пренебречь (в реализации прототипа вполне уместно правило "Главное, чтобы работало!"). В итоге у нас остаются две вершины: Время и Деньги. Соответственно, в какие пропорции и соотношения могут быть между ними (по отношению к прототипированию), зависит от конкретного проекта. Единственно, здесь стоит отметить тот факт, что бывают случаи, когда при фиксированном бюджете наличествует довольно солидный кусок времени, который можно потратить на прототипирование, а точнее, на реализацию большего числа фич в прототипе. Однако подобное, как правило, случается при неправильном планировании. Поэтому рассчитывать на данное стечение обстоятельств не стоит. Идеальный вариант, если прототипирование будет закладываться изначально в разработку проекта.

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

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

Начнем с того, что если геймдизайнер хочет сделать что-то хорошее, то прототипирование уместно всегда, может лишь меняться его объем. Скорее всего, каждый из нас когда-либо делал какой-либо прототип, сам того не подозревая - точнее, не называя свое творение прототипом. Например, все в том же проекте "Предназначение" с целью проверки работоспособности системы писалась текстовая программка, симулирующая бой согласно ролевым правилам между двумя персонажами. Для проекта "Корабль Поколений" писалась небольшая программа, моделирующая получение персонажем опыта, развитие персонажа согласно ролевой системе, а также симулятор системы стрельбы из оружия, там же дизайнер мог контролировать состав оружия, доступный для использования игроку на определенном уровне развития. Таким образом, можно предположить, что каждый геймдизайнер занимался чем-то подобным. Кстати, прототип это не обязательно программный продукт, например, в книге Эндрю Роллингза и Дейва Морриса "Проектирование и Архитектура Игр" приводится пример игры Warrior Kings, для которой создавался прототип в виде нарисованной от руки настольной игры.

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

• Все фичи проекта являются проверенными многими ранее вышедшими проектами. Такое возможно, если игра является клоном, или делается с целью быстрого выпуска на рынок, например, игра по фильму.
• Стоимость реализации прототипа сравнима или больше стоимости разработки playable демо-версии. Данный вариант возможен, если наличествует готовый инструментарий разработки игры (engine) и при этом большая часть фич или как минимум ключевые, проверены вышедшими играми.

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

Практика

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

Ответ прост: было бы неплохо иметь некий инструментарий, в котором была бы следующая функциональность:

1. Возможность проведения теоретических изысканий: балансировка игры, проверка работоспособности и функционирования механики игры, сбор статистических данных, вывод необходимой информации в виде графиков и диаграмм, проведение различных математических расчетов.
2. Возможность прототипирования игровых диалогов и связанных с ними геймплейных моментов.
3. Возможность быстрого создания прототипа без знания сложных языков программирования.
4. Возможность быстрого изменения параметров и функциональности прототипов.
5. Возможность легкого использования полученных в ходе прототипирования данных.

После анализа исходных данных, а также имеющегося временного отрезка, было решено в качестве средства создания подобного программного продукта использовать в качестве языка программирования C#, а в качестве среды - Visual Studio .NET 2005. Почему был выбран C#, можно пояснить очень коротко - это быстро, гибко и визуально.