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

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

• Результаты:

• всем понравился дизайн «дино-лодки». Члены команды вместе с представителями потенциальной аудитории сошлись на том, что «плавающие динозавры» лучше всего подходят для этой игры;

• после нескольких испытаний стало ясно, что на протяжении большинства уровней 60 % времени подлодка должна быть под водой, 20 % – в воздухе, и еще 20 % – ближе к поверхности воды, где игрок будет собирать ускорители, позволяющие ему набирать скорость и выскакивать из воды;

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

Цикл 3: Игра про «летающих динозавров»

• Постановка проблемы: создать игру про «летающих динозавров», где рептилии состязаются в скорости под водой и над ее поверхностью.

• Детальная постановка проблемы:

• нужно понять, сколько потребуется времени для создания анимации всех динозавров;

• нужно разработать «правильное» количество уровней;

• нужно определиться с бонусами в игре;

• нужно составить список доступного в игре оружия (и избежать использования скорострельных пулеметов, потому как они усложняют разработку режима «мультиплеер»).

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

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

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

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

Геймдизайнер Марк Церни дал свое описание системе разработки игры и назвал его «Метод» (The Method). Неудивительно, что в нем он описывает вышеупомянутые системы итераций и оптимизации рисков. Но в «Методе» Церни делает интересное различие между тем, что он сам назвал «предпродакшен» и «продакшен» (термины позаимствованы из киноиндустрии). Он говорит, что вы находитесь на стадии предпродакшена до тех пор, пока у вас не будет двух готовых к изданию уровней с полным комплектом всех необходимых функций. Иными словами, если у вас нет двух полностью готовых уровней игры, у вас нет сформированного дизайна игры. Как только вы достигаете волшебной отметки, вы переходите на стадию продакшена. Это значит, что у вас появляется четкое видение игры и вы можете переходить к планированию графика ее дальнейшей разработки. Церни говорит, что обычно к этой отметке подходят, израсходовав примерно 30 % имеющегося бюджета. То есть, если к этому моменту вы потратили $1 миллион, вам, скорее всего, понадобится еще $2,3 миллиона на то, чтобы довести проект до конца. Этот приблизительный подсчет на деле является самым точным способом спланировать дату выхода игры. Недостаток этого подхода состоит лишь в том, что вы не сможете ничего планировать, пока не истратите 30 % бюджета. По правде, этой проблемы нельзя избежать – «Метод» лишь показывает нам, как в кратчайшие сроки достичь «точки прогнозируемости».

За годы работы я вывел собственные правила, которые помогают мне доводить игры до конца, не выходя за рамки бюджета и сроков. Я назвал эти правила «правилами 50 %».

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

Второе правило 50 %: Все основные элементы гейм-плея должны быть готовы уже на середине вашего пути. Таким образом, вы сможете использовать первую половину срока для создания просто рабочей версии, а вторую половину потратите на превращение рабочей версии в хит. Обычно разработчики планируют потрать 80 % времени на рабочую версию и 20 % – на доведение ее до финального вида, но с таким подходом результат оставляет желать лучшего. Если же вы отдадите под рабочую версию лишь 50 % своего времени, вы сумеете создать готовый продукт, даже если что-то пойдет не так.

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