Ключевой вопрос: «Достаточно ли игра нравится игрокам?»

Иногда во время разработки приходится редактировать характеристики фильтров: предположим, что изначально у вас была одна целевая аудитория (скажем, мужчины 18–35 лет), но в процессе разработки вы находите что-то, что лучше подходит другой ЦА (скажем, женщины за 50). Нет ничего плохого в том, чтобы изменять фильтры, если ваш дизайн это позволяет. Самое главное, чтобы игра прошла через все восемь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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