Текст книги "Геймдизайн"

Правило цикла

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

На этом этапе вы уже наверняка обдумали множество идей и выбрали самую лучшую из них, а значит, пришло время переходить к следующему шагу 2: «сделать из нее игру». Многие дизайнеры и разработчики воспринимают это довольно буквально – просто приступают к реализации. И если ваша игра простая – например, карточная, настольная или примитивная компьютерная игра – и у вас достаточно времени, чтобы раз за разом тестировать и изменять ее до тех пор, пока вас полностью не устроит результат, пожалуй, вам подойдет такой подход.

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

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

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

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

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

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

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

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

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

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

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

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

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

И это, конечно, выглядит привлекательно! Модель состоит из семи упорядоченных шагов: выполнив один из них, вы просто переходите к следующему. Само название «водопад» не предусматривает повторов, ведь водопады не текут вверх по течению.

У этой модели несомненно было одно хорошее качество: она мотивировала разработчиков посвящать больше времени планированию и дизайну до того, как они приступят непосредственно к написанию кода. Но в остальном это полная ерунда, подобный подход нарушает Правило цикла. Менеджеры нашли модель привлекательной, но программисты знали, что это абсурд: в применении к таким сложным сферам, как разработка ПО, подобные линейные процессы обречены на провал. Даже Винстон Ройс (Winston Royce), чья работа послужила фундаментом для создания этой модели, не признает ее эффективность в общепринятом виде. Интересно, что в своей работе он подчеркивает важность циклов в разработке и говорит о возможности возврата на несколько шагов назад, если ситуация того требует. И он никогда не использовал слово «водопад»! Но в университетах и корпорациях изучали именно этот линейный подход. Это можно объяснить лишь тем, что люди, которые никогда в жизни не имели дело с разработкой программного обеспечения, принимали желаемое за действительное.

Барри Бим любит тебя

Позже, в 1986-м, Барри Бим представил другую модель, имевшую гораздо больше общего с реальным процессом разработки ПО. Это несколько пугающая своим видом схема, в которой процесс разработки начинается с середины и раскручивается по часовой стрелке, проходя через окружность снова и снова (рис. 8.3).

Его модель состоит из множества сложных деталей, но все они нам не нужны. В основном здесь можно отметить три замечательные идеи: оценка рисков, прототипы и цикличность. Согласно спиральной модели, вам нужно сделать следующее.

1. Определиться с основой дизайна.

2. Высчитать самые большие риски вашего дизайна.

3. Создать прототипы, которые уменьшат эти риски.

4. Протестировать прототипы.

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

6. Вернуться к пункту 2.

В целом вы просто повторяете этот цикл, пока все не встанет на свои места. При таком раскладе у модели водопада нет никаких шансов, потому что в данном цикле все основывается на вышеупомянутом Правиле цикла. Также это позволяет нам ответить на вопросы, которые мы задавали ранее.

• Вопрос цикла 1: Как сделать каждый цикл эффективным? Ответ спиральной модели: Оцените ваши риски и оптимизируйте их.

• Вопрос цикла 2: Как можно максимально ускорить циклы? Ответ спиральной модели: Создавайте больше «черновых» прототипов.

У спиральной модели было множество последователей, но еще более широкого распространения добился манифест Agile.

Манифест Agile

В 2001 году на лыжном курорте Сноуберд в штате Юта произошло событие, оказавшее очень сильное влияние на современный геймдизайн и разработку: группа программистов приняла Манифест Agile. Следуя по стопам Барри Бима, они сформировали список ценностей и принципов, лежащих в основе разработки высококачественного ПО. Давайте ознакомимся с самим манифестом и его 12 принципами.

Люди и взаимодействия важнее процессов и инструментов

Работающий продукт важнее исчерпывающей документации

Сотрудничество с заказчиком важнее согласования условий контракта

Готовность к изменениям важнее следования первоначальному плану

Иными словами, мы осознаем ценность понятий, которые находятся справа, но понятия слева мы ценим выше

Мы исповедуем следующие принципы.

1. Наша главная цель – удовлетворить заказчика быстрой и бесперебойной поставкой качественного программного обеспечения.

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

3. Поставлять работающее ПО с частотой от раза в несколько недель до раза в несколько месяцев, стараясь изменять частоту в меньшую сторону.

4. Тесное общение заказчика с разработчиками на протяжении всего проекта.

5. Проектом должны заниматься заинтересованные люди, нужно обеспечить их необходимыми условиями работы, поддерживать их и доверять им.

6. Самый эффективный способ передавать информацию между членами команды – это личный разговор (лицом к лицу).

7. Работающее ПО – лучшая оценка хода процесса.

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

9. Постоянное внимание к улучшению технического мастерства и удобному дизайну увеличивает гибкость.

10. Простота – искусство минимизации лишней работы – крайне необходима.

11. Лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды.

12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

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

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

Гибкие цели. Центральным понятием Agile-философии является утверждение, что мы не можем знать точно, какой результат получится в конце разработки. Команда куда легче приспосабливается к новым идеям по ходу разработки, если заранее не только допускает возможность внесения изменения в утвержденный план, но и действительно готова их вносить.

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

Спринты. Вместо того чтобы фокусироваться на выполнении долгосрочной (многомесячной) цели, в Agile программисты работают сериями так называемых спринтов – коротких этапов (несколько недель) с четко сформулированными задачами, решение которых необходимо предоставить к концу этапа. Основатель Atari Нолан Бушлелл как-то сказал: «Лучший источник вдохновения – это дедлайн», и это правда. Часто случается, что задачи волшебным образом выполняются, когда дедлайн уже рядом, и именно эта философия лежит в понятии спринтов: чем больше дедлайнов, тем больше задач будет сделано.

Scrum-собрания. Вместо еженедельных собраний для подведения итогов в Agile разработчики проводят ежедневные scrum-собрания, специально созданные для краткости и эффективности. Обычно эти собрания длятся всего 10–15 минут и проводятся стоя, что лишь подчеркивает их краткость. Во время такого собрания каждый из членов команды должен объяснить не больше трех вещей: что они сделали вчера, что они собираются сделать сегодня и с какими проблемами они столкнулись. Решение этих проблем обсуждается уже после окончания собрания один-на-один с членами команды, обладающими нужной квалификацией. С таким подходом каждый член команды знает, чем занимаются остальные, и каждый может оперативно получить помощь, если он в ней нуждается.

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

Ретроспективы. Также в конце каждого спринта команда проводит «ретроспективное совещание», на котором обсуждает не столько продукт, над которым работает, столько используемые процессы. Это возможность обсудить, что команда делает правильно, а что – нет, и то, как им следует улучшить процессы для следующего спринта.

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

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

Пример: Prisoners of Bubbleville

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

Prisoners of Bubbleville. Краткое описание

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

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

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

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

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

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

Prisoners of Bubbleville. Список рисков

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

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

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

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

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

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

Prisoners of Bubbleville. Оптимизация рисков

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

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

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

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

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

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

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

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

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

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

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

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

Призма 16: Призма оптимизации рисков

Чтобы использовать эту призму, перестаньте надеяться на лучшее и начните серьезно обдумывать вещи, способные поставить вашу игру под угрозу. Спросите себя:

• Что может не дать этой игре стать хитом?

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

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