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

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

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

Эстетика. Мультипликационная графика.

Технология. Мультиплатформенная консольная игра на трехмерном движке от стороннего разработчика.

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

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

Риск 1. Возможно, механика собирания пузырей и уничтожения стервятников будет не такой интересной, как нам кажется.

Риск 2. Возможно, движок не сможет поддержать одновременное отображение целого города и всех этих пузырей и стервятников.

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

Риск 4. Мы не уверены, что людям понравятся наши персонажи и история.

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

На деле рисков будет куда больше, но ради нашего эксперимента мы ограничимся только этими. Так что же делать с рисками? Мы могли бы скрестить пальцы и понадеяться, что ничего из вышеперечисленного не произойдет. Или поступить умнее: оптимизировать риски. Чтобы смягчить или даже предотвратить риски, нам потребуется разработка небольших прототипов. Давайте рассмотрим, как можно оптимизировать каждый из описанных рисков.

Риск 1. Возможно, механика собирания пузырей и уничтожения стервятников будет не такой интересной, как нам кажется.

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

Риск 2. Возможно, движок не сможет поддержать одновременное отображение целого города и всех этих пузырей и стервятников.

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

И да, это снова исключительно «одноразовый» прототип.

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

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

Риск 4. Мы не уверены, что людям понравятся наши персонажи и история.

Если вас действительно волнует этот момент, то нельзя ждать, пока персонажи проявят себя уже в готовой игре. Какой прототип создать в этом случае? Художественный прототип: для этого можно обойтись и без компьютера – достаточно будет маркерной доски. Попросите художника сделать приблизительный концепт иллюстраций к игре или тест-рендер ваших персонажей. Создайте несколько раскадровок, в которых наглядно видно, как развивается ваша история. Закончив, покажите эти наработки людям (желательно, чтобы это были представители вашей целевой аудитории) и проследите за их реакцией. Вам нужно понять, что им понравилось, что не понравилось и почему. Возможно, они в восторге от внешнего вида главного героя, но его поведение в игре им не по душе. Может быть, вы хорошо раскрыли образ злодея, а вот история получилась скучной. Это все можно легко узнать и без самой игры. Каждый раз, делая это, вы проходите очередной цикл и становитесь на шаг ближе к вашей идеальной игре.

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

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

Оценка и оптимизация рисков – это очень полезный подход, а также призма 16.