Процесс разработки новой игры

Я тут вчера опубликовал свои сумбурные мысли о разработке настолок, а теперь думаю, стоило ли этой заметке появляться на свет. Всё дело в том, что ещё неделю назад Random_Phobosis опубликовал ещё один отличный теоретический материал, посвящённый разработке настольных игр.

Он пишет о том же — детально рассматривает процесс придумывания новой игры, демонстрируя, как и что, опираясь на принцип "от общего — к частному" следует делать, создавая свою игру. Только в отличие от меня, у него всё получается куда более логично и куда более структурировано. Рекомендую!

Дискуссия о модификации Zombie Plague на boardgamer.ru, показала, как по-разному настольщики подходят к разработке игр. Кто-то сразу же предлагает готовые механики, кто-то – смакует ситуации, которые возникнут в игре, кто-то анализирует опыт кино и компьютерных игр.

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

Шаг 1. Кадр

Проведём небольшой эксперимент.

Что возникает у вас в воображении, когда звучит название знакомой игры? Вот я сказал – Манчкин. SimCity. StarCraft. О чём вы подумали?

Когда я слышу Unreal Tournament, передо мной сразу же возникает картина перестрелок в коридорах незабвенной deck_16. Carcassonne? Прямо вижу, как я ставлю район п-образной формы, и закрываю город. Quake 3? Вот я, с “рельсой” наперевес, прыгаю по трамплинам Longest Yard. Battlestar Galactica? Ресурсные треки и отчаянное желание не спалиться. TES III: Morrowind? Чистое небо и уходящая вдаль дорога.

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

Эту смысловую единицу я предлагаю называть “кадр”. Когда я перебираю в памяти игры, я перелистываю их кадры, один за другим. Попробуйте сами, я подожду.

Если подумать об игре чуть дольше и начать вспоминать, что же в ней происходило, мы снова получим кадры – на сей раз каждый будет характеризовать какую-то игровую ситуацию. Среди воспоминаний о Космических Рейнджерах, без которых, кажется, тут не обходится ни один пост, у меня есть кадр с космическими битвами, кадр с торговым экраном и кадр с гипером, кадр с текстовым квестом и кадр с бегством от пиратов. Может быть, так устроена только моя голова, и у вас память работает совсем по-другому, но для меня “кадровая” абстракция оказалась очень полезной.

Итак, ещё раз: кадр – это комплекс впечатлений, создаваемых правилами игры. Тут важно заметить следующее. Во-первых, кадр – это не механики, а то, что мы по поводу них думаем. В состав кадра не входят формулы расчёта скоростей и повреждений, зато в нём есть мысль “А-а-а! Валим, валим, валим, от этого пирата!” Поэтому кадром очень сложной, вдумчивой, комплексной игры вполне может стать мутное месиво (тот редкий случай, когда Hearts of Iron и Disgaea можно упомянуть в одном предложении). Во-вторых, игра по большей части происходит у нас в голове, а не на экране/столе, поэтому и запоминается чаще всего не реальная графика/компоненты, а то, как наш мозг их интерпретировал. В-третьих, в отличие от, например, сцен в пьесе, кадр иллюстрирует не столько процесс, проходящий внутри системы, сколько состояние наблюдателя, то есть, игрока.

И вот, мы решили сделать свою собственную игру – или даже просто модифицировать уже существующую. С чего начать? Предлагаю решать задачу с конца: если игрокам в конечном счёте запомнится кадр, надо его придумать!

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

К сожалению, свериться с кадрами мы догадываемся не всегда: не имея кадра, в который в конце концов должна уложиться наша игра, мы отдаём формирование этой – самой главной – части игры на волю случая.

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

Прежде, чем вы продолжите разработку игры, закройте глаза и просто представьте себе кадр. Запишите или зарисуйте то, что вы увидели. Постоянно сверяйтесь с этой записью, корректируйте её, если придётся, но ни в коем случае не забывайте. Каждое ваше дальнейшее действие должно быть направлено на воплощение этого кадра в жизнь. Больше от разработчика, по сути, ничего не требуется :]

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

Если у вас есть классные механики, но ещё нет кадра – сидим и придумываем. Без вижена, выражающегося в кадре, дальше нельзя.

Шаг 2. Цели

Ужасно хочется приступить уже к механикам – но сначал нам придётся наметить ответ на ещё один важный вопрос.

Кадр – это по сути отпечаток игрового конфликта. Значит, конфликт у нас уже есть – теперь нам нужны противоречащие друг другу мотивации (традиционные “игрок против игрока” или “игрок против игры”), которые к этому конфликту приведут.

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

За примерами далеко ходить не надо: в упомянутых мной в одном из предыдущих постов Battlestar Galactica и Resistance механики очень похожи, но посмотрите, насколько отличаются цели игроков. Цель людей в Баттлстаре – “улететь” (продвинуть один трек до конца) и при этом “не погибнуть” (не дать опуститься до нуля остальным трекам). Поскольку предатели могут мешать операциям с треками, их вычисление становится важной дополнительной задачей, но вовсе не определяет победителя партии. Цель людей в Резистансе – “узнать, кто предатели”. В свете таких различий действия, доступные игрокам, выглядят в этих играх совсем по-разному, хотя и схожи чисто механически.

Другой любопытный пример – Panic Station. Разработчик придумал замечательный кадр и неплохие механики, а вот о целях забыл – и на вопросы вроде “почему чтобы выиграть, я должен совершать абсолютно нелогичные поступки и предпринимать действия, ломающие игру” вынужден отвечать в духе “ну, цели – это же не главное, главное – переживание…” Такого кошмара, господа, можно было бы легко избежать, немного потрудившись на Шаге 2 нашей схемы.

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

Например, я могу думать так: “В начале игры у меня есть база и пара рабочих. Я отправляю рабочих добывать ресурсы и строю ещё рабочих. Затем я покупаю несколько солдат для защиты от возможных атак противника. После этого я строю продвинутую фабрику, где производятся крутые роботы, и с их помощью уничтожаю базу противника!”

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

Шаг 3. Механики

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

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

Сейчас будет очень полезно заняться микротестами: придумать конкретную игровую ситуацию с заданными значениями параметров и посмотреть, как себя в ней поведёт та или иная механика. Например: “если каждое повреждение влияет на скорость моего корабля, то смогу ли я вообще вернуться в порт после некоторого количества пробоин? Смогу ли я это сделать с переполненным трюмом?”

Шаг 4. Динамика

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

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

Может получиться, что у нас неплохие цели и механики, а вот динамика в игре провисает – мы видели такое и в Twilight Imperium, и в Twilight Struggle, и в Колонизаторах. На помощь опять приходит концептуальный плейтест – попробуйте оценить, как будут изменяться параметры игры в процессе партии, сколько будет добываться ресурсов, гибнуть юнитов, изучаться технологий. Точные цифры не нужны – главное получить примерное представление.

Шаг 5. Рабочий прототип

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

Главная задача на этом этапе – собирать фидбэк! Кто выиграл, на каком ходу и с какими силами, что привело его к победе, большой ли был отрыв? Плейтесты – занятие долгое и довольно утомительное, поэтому результаты надо использовать на все сто.

…Профит?

А вот и весь план целиком:

1. Кадры (погружаемся!)

2. Цели (концептуальный плейтест)

3. Механики (микротесты)

4. Динамика (концептуальный плейтест, опять)

5. Прототип (не забываем про фидбэк)

Самый большой челлендж – увлекшись мелочами на каждом из этапов не забыть, для чего изначально придумывалась игра. Кадры решают всё!