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

1. Придумали идею.

2. Сделали из нее игру.

3. Редактировали и тестировали игру, пока она не стала такой, как вы хотите.

Теперь этот процесс стал более формальным.

1. Определились с проблемой.

2. Придумали несколько возможных решений.

3. Выбрали одно решение.

4. Составили список рисков, связанных с этим решением.

5. Сделали прототипы, которые позволяют оптимизировать эти риски.

6. Испытали прототипы. Если с ними все хорошо, закончили.

7. Определились с новой проблемой, которую нужно решить, и вернулись к шагу 2.

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

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

• Решение: гонки на подводных лодках (с торпедами!).

• Риски:

• непонятно, как должна выглядеть подводная гоночная трасса;

• возможно, игра не будет достаточно инновационной;

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

• Прототипы:

• художники рисуют наброски подводных трасс;

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

• программисты тестируют упрощенные водные эффекты.

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

• подводные трассы в виде «светящихся дорожек» выглядят хорошо. Подводные тоннели – это круто! Круто будут выглядеть и летающие подводные лодки, периодически выпрыгивающие из воды!

• прототипы выглядят достаточно интересно при условии, что субмарины будут очень быстрыми и маневренными. Нужно сделать «гонки на субмаринах». Смесь плавания и полетов выглядит свежо. Скорость подводных лодок должна увеличиваться, когда они летят, поэтому нам нужно придумать, чем ограничить время полета. Немного поиграв, мы поняли, что в игре должен быть мультиплеер;

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

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

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

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

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

• нужно понять, как обеспечить поддержку многопользовательского режима.

• Риски:

• если гоночные субмарины будут выглядеть «слишком мультяшно», это может отпугнуть игроков постарше. Если они будут выглядеть слишком реалистично, это будет выглядеть глупо на контрасте с таким гейм-плеем;

• пока мы не узнаем точное количество времени, проводимое лодками под водой и в полете, невозможно приступить к дизайну уровней или к отрисовке ландшафтов;

• команда никогда ранее не делала игры с многопользовательским режимом. Мы не совсем уверены, получится ли.

• Прототипы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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