Совет для прототипирования #7: Выберите легко редактируемый игровой движок

 

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

 

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

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

3 Запуск игры

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

5 Тестинг

6 Назад к шагу 1

 

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

 

1 Запуск игры

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

3 Тестинг

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

5 Назад к шагу 3

 

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

 

Совет для прототипирования #8: Сначала делайте игрушку

 

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

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

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

 

Линза #15: Линза Игрушки

Чтобы воспользоваться этой линзой, думайте не о том, насколько интересно играть в вашу игру, а о том, насколько интересно играть с ней. Спросите себя:   ● Если бы в моей игре не было цели, была бы она такой же интересной? Если нет, как я могу это изменить? ● Возникает ли у людей желание поиграть в мою игру еще до того, как они узнают, что им нужно будет делать? Если нет — как я могу это изменить?   Есть два способа использовать Линзу Игрушки. Первый способ: использовать его вместе с уже существующей игрой, чтобы понять, можно ли придать ей больше “игрушечных” качеств – иными словами, как ее можно сделать более понятной и “приятной в обращении”. Но если быть достаточно смелым и пойти по второму пути, можно изобрести абсолютно новую игрушку еще до того, как вы решите, какую игру будете создавать вокруг нее. Это может быть рискованно, если вы работаете по графику, но если нет — линза может стать вашей собственной “волшебной лозой”, которая поможет вам отыскать чудесные идеи для ваших игр, к которым вы сами вряд ли когда-то пришли бы.

 

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

 

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

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

 

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

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

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

 

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

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

 

1 Постановили проблему

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

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

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

5 Сделали прототипы, которые смягчают эти риски

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

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

 

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

 

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

 

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

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

● Риски:

 

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

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

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

 

● Прототипы:

 

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

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

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

 

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

 

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

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

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

 

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

 

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

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

 

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

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

○ Нужно понять, как обеспечить поддержку режима мультиплеер.

 

● Риски:

 

○ Если гоночные субмарины будут выглядеть “слишком мультяшно”, это может отпугнуть игроков постарше. Если они будут выглядеть слишком реалистично, это будет выглядеть глупо на контрасте с таким геймплеем.

○ Пока мы не узнаем точное количество времени, которое подлодки будут проводить под водой и в полете, невозможно приступить к дизайну уровней или к рисованию ландшафтов.

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

 

● Прототипы:

 

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

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

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

 

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

 

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

○ После нескольких испытаний стало ясно, что на протяжении большинства уровней, 60% подлодка должна быть под водой, 20% — в воздухе, и еще 20% — ближе к поверхности воды, где игрок будет собирать необходимые пауер-апы, которые позволят ему набрать высоту, набрав при этом ускорение.

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

 

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

 

● Постановка проблемы: Создать игры про “летающих динозавров”, где рептилии состязаются в скорости под водой и над ее поверхностью.

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

 

○ Нужно понять, сколько нужно времени для анимации всех динозавров.

○ Нужно разработать “правильное” количество уровней.

○ Нужно определиться с пауер-апами, которые будут доступны в игре.

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

 

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

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

 

Сколько будет достаточно?

 

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

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

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

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

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

 

Глава 8

 

Игра делается для игрока

 

Скрипка Эйнштейна

 

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

У Эйнштейна получилось создать такой запоминающийся опыт, потому что он знал свою аудиторию. Как бы сильно он ни любил разговоры о физике, он знал, что данную аудиторию это вряд ли заинтересует. Конечно, его попросили рассказать о физике, потому что они думали, что это самый лучший путь получить то, что они хотели – личную встречу со знаменитым Альбертом Эйнштейном.

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

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