Game Design

71

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

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

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

Настоящая проблема здесь – это Правило Цикла.

Правило Цикла: Чем больше раз вы улучшаете и испытываете ваш дизайн, тем качественнее игра у вас получается.

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

Если, вы несмотря ни на что, решились взяться за игру, разработка которой потребует долгих циклов “тестирования и улучшений”, то необходимо ответить на эти два вопроса:

●Вопрос Цикла 1: Как сделать каждый цикл эффективным?

●Вопрос Цикла 2: Как можно максимально ускорить циклы?

72

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

Краткая история индустрии ПО

Опасность – Водопад – Шаг Назад

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

Рис. 7.1

И это на самом деле выглядит убедительно. Модель состоит из семи упорядоченных шагов, и когда вы выполняете один шаг, не остается больше ничего, кроме как приступить к следующему шагу – само название “водопад” не предусматривает повторения, потому что водопады обычно не текут вверх по течению.

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

74

Рис. 7.2

Спиральная модель разработки ПО

Оценка рисков и создание прототипов

Пример: “Заключенные Баблвилля”

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

“Заключенные Баблвилля” — Краткое описание История: Вы кот-парашютист по имени Смайли. Злой волшебник превратил дома

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

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

75

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

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

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

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

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

Заключенные Баблвилля – Список Рисков

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

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

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

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

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

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

Заключенные Баблвилля – Смягчение рисков Риск #1: Возможно, механика собирания пузырей и уничтожения стервятников

будет не такой интересной, как нам кажется.

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

76

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

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

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

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

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

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

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

77

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

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

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

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

Линза #14: Совет Смягчения Рисков

Чтобы использовать эту линзу, перестаньте надеяться на лучшее и начните серьезно

обдумывать вещи, которые могут поставить вашу игру под угрозу. Спросите себя: Что может не дать этой игре стать хитом?

Как мы можем это предотвратить?

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

Восемь советов для продуктивного прототипирования

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

Совет для прототипирования #1: Ответьте на вопрос

Каждый прототип создается для того, чтобы получить ответ на вопрос или на несколько вопросов. Вы должны научиться формулировать вопрос четко. Если вы не умеете этого делать, вы рискуете потерять время из-за прототипа, а не сохранить его, как изначально планировали. Вот некоторые примеры вопросов, на которые может отвечать прототип:

79

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

Совет для прототипирования #5: Совмещайте прототипы эффективно

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

Совет для прототипирования #6: Они не должны быть цифровыми

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

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

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

Tetris: Бумажный прототип

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

80

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

Doom: Бумажный прототип

Можно ли создать бумажный прототип шутера от первого лица? Конечно! Сначала найдите людей и разделите их на AI персонажей и других игроков. На большом листе клетчатой бумаги нарисуйте карту и расставьте по ней фишки, которые будут вашими игроками и монстрами. Каждым виртуальным персонажем должен управлять отдельный человек. Далее можно придумать некое подобие пошаговых правил для вашей игры или же просто взять метроном. Программу-метроном можно легко найти в интернете. Настройте частоту ударов метронома на 5 секунд и введите правило, согласно которому персонаж делает шаг вперед на одну клетку после каждого удара. Когда на прицеле появляется враг, вы можете в него выстрелить, но только с расчетом один выстрел на один удар метронома. Это даст вам возможность посмотреть на вашу игру в замедленном действии, что является определенным преимуществом, потому что это дает вам время подумать, что в вашей игре хорошо, а что плохо, не переставая при этом играть. Вы сможете понять, насколько большой должна быть ваша карта, какой должна быть форма комнат и коридоров, чтобы игроку было интереснее по ним бегать, какими свойствами должно обладать оружие, и многое другое – и для всего этого вам понадобится совсем немного времени.

Совет для прототипирования #7: Выберите легко редактируемый игровой движок

Традиционный метод разработки ПО чем-то напоминает выпекание хлеба:

1Написание кода

2Компиляция и компоновка

3Запуск игры

4Поиск в игре той части, которую нужно тестить

5Тестинг

6Назад к шагу 1

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

1Запуск игры

2Поиск в игре той части, которую нужно тестить

3Тестинг

4Написание кода