Геймдизайн. Как создать игру, в которую будут играть все

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

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

Совет 1: Ответьте на вопрос

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

• Сколько анимированных персонажей может поддержать ваша технология?

• Увлекателен ли основной гейм-плей? Как долго он может оставаться увлекательным?

• Насколько хорошо персонажи и окружающий мир сочетаются в эстетическом плане?

• Насколько большими должны быть уровни?

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

Совет 2: Забудьте о качестве

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

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

Совет 3: Никаких привязанностей

В книге «Мифический человеко-месяц, или Как создаются программные системы» (The Mythical Man-Month) Фред Брукс впервые употребляет свое знаменитое выражение «Отпускайте легко, так как это неизбежно». Этим он хотел сказать, что нравится вам это или нет, но первая версия вашего проекта – это не конечный продукт, а прототип, от которого впоследствии придется отказаться и создать «правильно» работающую систему. Но по правде, «отпустить», возможно, придется много прототипов. Для разработчиков с небольшим опытом такое дается непросто – они воспринимают это как провал. Создавая опытный образец, убедите себя в том, что прототип – временное явление и его жизненный цикл заканчивается в тот самый момент, когда вы получаете ответ на свой вопрос. Смотрите на каждый прототип как на возможность чему-то научиться – потренироваться перед созданием «настоящей» игры. Конечно, отказываться от всего не нужно – собирайте работающие «кусочки», чтобы впоследствии слепить из них что-то действительно стоящее. Иногда это больно. Дизайнер Николь Эппс сказала следующее: «Это как зарезать собственное дитя, но этому нужно научиться».

Совет 4: Расположите прототипы в порядке их важности

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

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

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

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

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

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

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

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

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

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

Совет 7: Прототип не должен быть интерактивным

Ваши прототипы не обязаны быть цифровыми; они даже не обязаны быть интерактивными. Простых скетчей и анимаций может быть более чем достаточно для ответов на часть вопросов по гейм-плею. Ранние прототипы игры «Принц Персии: Пески времени» (Prince of Persia: Sands of Time) с ее инновационными механиками прыжков и перемотки времени были сделаны в виде неинтерактивных анимаций, демонстрирующих всевозможные акробатические трюки. В результате у команды была возможность быстро проверить, как будут выглядеть их идеи, и обсудить, как лучше сделать раскрывающую потенциал этих идей интерактивную систему.

Совет 8: Выберите легко редактируемый игровой движок

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

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

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

3. Запуск игры.

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

5. Тестирование.

6. Возврат к шагу 1.

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

1. Запуск игры.

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

3. Тестирование.

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

5. Возврат к шагу 3.

Меняя код запущенной игры, вы ускоряете весь процесс и проходите больше циклов в день, что, в свою очередь, повышает качество вашей игры. Раньше я использовал Scheme, Smalltalk и Python, но в целом подойдут любые языки программирования высокого уровня. Связать все воедино поможет Javascript. Если вы боитесь, что эти языки медленно запускаются, помните, что игры можно писать на нескольких языках одновременно: напишите второстепенный контент, который не нужно будет сильно изменять, на чем-то быстром и статическом (Ассемблер, C++ и т. д.), а для написания более важного контента используйте медленный, но динамичный язык. Это может потребовать дополнительных усилий, но оно того стоит, так как у вас появляется возможность воспользоваться преимуществами Правила цикла.

Совет 9: Сначала делайте игрушку

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

Геймдизайнер Дэвид Джонс признается, что для создания игры Lemmings его команда воспользовалась именно этим методом. Они просто подумали, что будет интересно создать маленький мир с толпами маленьких созданий, которые ходят туда-сюда и занимаются своими делами. У них не было четкого видения игры, но идея такого мира звучала интересно, поэтому они взялись за ее воплощение. Как только у них появилась «игрушка», начались серьезные обсуждения того, какую игру можно создать вокруг нее. Джонс говорит, что в случае с Grand Theft Auto все было так же: «GTA не делали как GTA. GTA делали как средство. Задача была – построить живой полноценный город, в котором было бы интересно играть». Как только удалось разработать «средство» и команда убедилась, что это действительно хорошая игрушка, нужно было решить, какую игру из нее можно сделать. Им показалось, что город похож на лабиринт, поэтому они решили взять механику лабиринта из достаточно надежного, на их взгляд, источника. Джонс продолжает: «GTA произошла от Pac-Man. Точки – это маленькие люди. Вот я еду в своей маленькой желтой машинке. А привидения – это полицейские».

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

Призма 17: Призма игрушки

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

• Если бы в моей игре не было цели, была бы она такой же интересной? Если нет, как я могу это изменить?

• Возникает ли у людей желание поиграть в мою игру еще до того, как они поймут, что им нужно будет делать? Если нет – как я могу это изменить?

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

Совет 10: Хватайтесь за возможность повторить цикл

Иногда в процессе разработки могут измениться условия, и это дает больше времени на доработку игры. В игровой индустрии бывали случаи, когда игра добивалась успеха благодаря тому, что у разработчиков внезапно появлялась возможность провести новые эксперименты с игрой. Например, Halo изначально разрабатывалась для Macintosh. Но позже компания-разработчик заключила контракт с Microsoft и игру стали портировать на ПК. Команда воспользовалась этим, чтобы доработать продукт. Второй такой шанс компания получила, когда Microsoft попросили их портировать игру с ПК на Xbox! Дополнительного времени хватило не только на то, чтобы внести все необходимые технические изменения, но также и на доработки гейм-плея. Дизайнеры здраво распорядились временем изначально не запланированных итераций, и это позволило им значительно повысить качество игры.

Замыкание цикла

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

Неформальный цикл

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

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

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

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

Формальный цикл

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

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

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

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

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

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

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

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

Цикл 1: «Новый гоночный симулятор»

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

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

• Риски:

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

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

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

• Прототипы:

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

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

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

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

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

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

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

Цикл 2: Игра про «гонки на субмаринах»

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

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

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

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

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

• Риски:

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

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

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

• Прототипы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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