20 лет, одна очень сложная взаимосвязанная целостная система взглядов на геймдизайн Марка Роузвотера - финал

Последняя (но не по значению!) часть перевода прекраснейшего доклада геймдизайнера со стажем в вызывающую уважение и трепет четверть века. Наш неизменный комментатор, FrankStein , в этот раз превзошёл сам себя — по крайней мере, в объёме размышлений он поравнялся с Марком.

Название четвёртой части, как вы могли заметить, отличается от предыдущих. По какой причине — узнаете, если дочитаете до конца. Чур, не пролистывать!

Урок №16

Вернёмся ещё раз в 1999 год к специальному набору Unglued. Он разрабатывался как шуточный, попирающий устои и стал первым набором с серой рамкой, то есть — сознательно созданный не для официальных соревнований. Самой популярной картой (картами) в нём была вот эта:

Название этой карты — B.F.M, Big Furry Monster (Б. М. М. — Большой Мохнатый Монстрюга — прим. пер.), и он такой огромный, что, как видите, не помещается на одной карте. Для того, чтобы его призвать, вам нужно иметь в руке обе карты — после чего выложить их на стол, соединив в одно гигантское существо. Годом позже, когда я работал над Unglued 2 (набором, который так и не будет выпущен), я задумался — если игрокам понравился монстр, состоящий из двух карт, то почему бы не пойти в обратном направлении и не сделать карту, на которой помещались бы сразу два заклинания? Я назвал это «сплит-картами».

Unglued 2 благополучно канул в Лету, и похоже было, что сплит-карты обречены на вечное забвение. Однако, год спустя, во время работы над дизайном Invasion я неожиданно понял, что многоцветный блок (Блок — сочетание нескольких наборов, разделяющих одну идею, механики, атмосферу и турнирную ротацию. Multicolor block — блок, построенный вокруг идеи использования в колоде карт сразу нескольких цветов, с последующей их синергией — прим. пер.) — отличное место для презентации сплит-карт. Я показал их Bill Rose, ведущему дизайнеру Invasion, и они настолько ему понравились, что он сразу же решил добавить их в набор. Также я продемонстрировал сплит-карты Richard Garfield, и тот тоже заявил, что эта механика очень интересна. К сожалению, эти два человека были единственными в компании, кто положительно отозвался о моём детище.

Начиная с первого дня разработки, Henry Stern, ведущий разработчик Invasion, пытался их уничтожить (сплит-карты, а не Билла с Ричардом, конечно — прим. пер). Остальные члены команды разработки пытались их уничтожить. Весь бренд пытался их уничтожить. Необходимо подчеркнуть, что всё это было из самых лучших побуждений — люди просто были обеспокоены тем, что сплит-карты чересчур сильно отличались от обычных карт в Magic. Другие переживали, что это будет воспринято, как оверинжиниринг. Но независимо от аргументации, все они считали, что от сплит-карт стоило избавиться.

Билл и я день за днём держали оборону. Мало-помалу, мы переубеждали людей, и к тому моменту, как набор был готов к печати, большая часть Визардов поменяла свою точку зрения, став скорее «за», чем «против». Под звуки фанфар, сплит-карты всё-таки были выпущены. Игрокам они понравились и по результатам маркетингового исследования оказалось, что эта механика была наиболее популярной в наборе.

И вот следующий урок:

Урок №16 — Больше бойтесь наскучить вашим игрокам, чем бросить им вызов

За двадцать лет, проведённых в Визардах, я много раз создавал революционные, потрясающие основы вещи. И каждый раз находились люди, которые совершенно искренне, с самыми честными намерениями заявляли мне, что введение той неконвенционной новой штуки — плохая идея. «У тебя ничего не выйдет!», «Это слишком рискованно!», «Это повредит игре!».

В то же время — я приложил руку и к ряду скучных механик. Однако, лишь немногие нашли в себе силы и указали мне на это, не позволив добавить их в игру. Почему так? Да потому, что разработчики больше боятся отпугнуть игроков неожиданными дизайнерскими решениями, чем утомить их чем-то скучным. Лично я считаю, что на самом деле всё наоборот — когда ты замахиваешься на нечто грандиозное, но не достигаешь успеха, игроки относятся к этому с пониманием, потому что ценят попытку создать нечто обалденное. И они уважают эту попытку, задерживаются, чтобы увидеть, что ты будешь делать дальше. А в случае с заскучавшей аудиторией, напротив — никто не простит вам очередного похода по тем же граблям, потому что это совсем не то, что набивание новых шишек. Когда вы утомляете своих игроков, они негодуют и иногда даже прекращают играть.

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

FR: Сколько раз лично я был на той же самой позиции… «Это слишком рискованно!», «Ты не знаешь всех подробностей, твой механизм не продуман и использовать его нельзя!». И всякий раз я думал: нет бы подумать в продолжение моей идеи, так они же все свои силы кладут на то, чтобы идею зарубить. Почему indie (самиздат) в игровой индустрии сперва стал нарицательным для фантазёров (людей, создающих потрясающую игру, живя при этом около черты бедности), а потом извратился и стал обозначать целый жанр игр, которые теперь делаются солидными компаниями и издаются солидными издательствами? Почему от анонсов AAA-тайтлов последние 10 лет мы не испытываем того вожделенного трепета, как раньше? Всё дело в риске. Indie-разработчики делали игры, потому что хотели сделать игры, потому что хотели реализовать придуманную ими механику. Им было не важно мнение сообщества. В пучине времени кануло очень много не совсем интересных indie проектов, но важно тут только то, что игра смогла встретить игроков в условиях экстремальных рисков для разработчика. Крупные компании, напротив, пошли по пути снижения рисков. Теперь созданием AAA управляет маркетинговое исследование. Картинка диктуется потребительскими исследованиями, геймплейные моменты спускаются оттуда же, игровые механики — так же. Со стороны это может выглядеть как: «Здраствуйте, я — Кирилл. Хотел бы чтобы вы сделали игру», только теперь не смешно, потому что это надо делать. Потому что в это будут играть. Желание снизить риски — это нормально. Только лично я считаю, что риски надо снижать детальной проработкой рискованных решений, а не борьбой с рискованными решениями. А человек, способный защищать свои рискованные решения в любых ситуациях — всегда достоин похвалы и уважения.

Урок №17

История этого урока начинается в 2005 году, во время разработки первого, оригинального блока Ravnica. Мы хотели тогда создать второй многоцветный блок, и очень важно было сделать так, чтобы он не выглядел как повторение первого, Invasion, с оглушительным успехом вышедшего пятью годами ранее. Я начал искать тему, которая подходила бы для мультиколора, и одновременно вела игру в совершенно ином направлении, чем Invasion.

Стартовал я с размышления о концепции Invasion. Она была такой — «играй как можно большим числом цветов». В этом блоке мы, действительно, довольно активно подталкивали игроков к созданию 4- или даже 5-цветных колод. Хорошо, подумал я — а что, если мы пойдём в ровно противоположном направлении? Что, если вместо максимального количества цветов мы сделаем минимальное? Иначе говоря, будем мотивировать игроков играть ровно двумя цветами.

Я постановил, что в этом блоке мы будем в равной степени использовать все десять двухцветных вариантов, чтобы максимизировать простор для дизайнерских задумок. Brady Dommermuth из креативного отдела взял эту идею, поработал над ней и вернулся с концепцией гильдий, которая, в свою очередь, стала фундаментом для реализации «мира-города». Гильдии мне очень понравились, и после недолгих раздумий я решил разделить их на три части, 4-3-3, так, чтобы каждая гильдия появлялась в определённом наборе блока.

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

Урок №17 — Не требуется много изменений, чтобы создать нечто принципиально новое

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

Мне кажется, что многие геймдизайнеры относятся к компонентам игры примерно так же, как я к этому проклятому горошку. Ты не уверен, что уже достаточно и всё подсыпаешь и подсыпаешь, до того момента, когда это становится источником проблем, делая игру чересчур сложной. Замыливая посыл игрокам. Тратя ресурсы, которые могли бы пойти на что-то более полезное.

Осознав всё это, я начал подходить к дизайну немного с другой стороны. Вместо того, чтобы задавать себе вопрос «Насколько много нужно добавить?», я начал спрашивать себя «Насколько мало можно добавить?». Смена точки зрения важна, потому что цель геймдизайнера (как и любого творца) — убирать всё лишнее, оставляя только минимум необходимого, чтобы ничего невозможно было изъять, не повлияв на работоспособность. Короче говоря — следите за количеством горошка в кастрюле, не переедайте.

FR: И вот это вот всё говорит человек, на секундочку, в игре которого уже более 20 тысяч уникальных карт, более сотни действующих механик и более пяти сотен разработанных механик. Марк, ты это серьезно? :) С моей точки зрения, Марк говорит о том, что механики для игрока надо вовремя интегрировать и правильно подавать. Моя точка зрения в этом вопросе такова, что на этапе закрытой разработки проекта тебе совершенно незачем реализовывать абсолютно сразу и абсолютно все желаемые механики. В инженерии широкого спектра есть термин MVP — Minimum Valuable Product. Причём, минимально-весомыми в игровом продукте являются именно его геймплейные функции. До момента раскрытия проекта для сообщества игроков, в проекте должен быть реализован минимальный набор механик, составляющий базовое конкурентное преимущество данного проекта перед другими. Только так проект и выйдет скоро, и будет востребованным у игроков. Далее проект можно с успехом расширять до бесконечности, прямо во время того, как игроки уже полноценно населяют игровое пространство. До релиза надо сосредоточиться на MVP проекта, это сэкономит силы и ресурсы в случае провала. После релиза проекта в процесс развития необходимо интегрировать сообщество игроков и на основе их отзывов формировать уже горизонт развития проекта. В этом случае проект можно долго и успешно развивать. При этом, к реализации каждого дополнения проекта тоже можно относиться с позиции MVP, это тоже полезно. Марк всё говорит правильно. Для выпуска проекта очень важно понимать, что из него можно убрать и не делать сейчас, чтобы проект остался конкурентоспособным. В то же время, для проекта очень важно не переборщить с объемами единоразовых изменений.

Урок №18

Каждую неделю я пишу небольшой текст (имеются в виду статьи для блога "Making Magic" — прим. пер). Некоторые недели являются тематическими, поэтому я пишу на заранее определённую тему. В остальное время — пишу всё, что захочется. Как вы думаете — какой из вариантов сложнее, тематика или полная свобода?

Второй вариант сложнее. Тематика диктует мне условия и тем самым открывает возможности, которые в противном случае я и не заметил бы. К примеру, моя любимая заметка, под названием "To Err Is Human" — первая из Topical Blend-заметок, когда я предлагал читателям выбрать одну тему, относящуюся к Magic, вторую — не относящуюся, с последующим купажированием их в рамках одного текста. В «To Err Is Human» магическая тема была — про мои самые ужасные ошибки в геймдизайне, а немагическая — про противоположный пол. Сам по себе, разумеется, я никогда не написал бы ничего подобного. Только внешнее воздействие позволило мне покинуть старые рамки и создать нечто новое.

Перейдём к следующему вопросу — что сложнее дизайнить, тематический набор или обычный? Ответ тот же, что и прежде — обычный сложнее. Тематический набор отправляет меня в неизведанные края, в то время, как обычный — ничего подобного не делает, оставляя в давно исследованных областях. Что приводит нас к следующему уроку:

Урок №18 — Ограничения порождают креативность

Из всех уроков — этот, пожалуй, самый часто мною используемый. Если вы достаточно долго читаете мои заметки, то наверняка уже не раз видели эту мысль, высказываемую в разных формах. Этот урок относится к одному из мифов, связанных с творчеством. Многие считают, что чем больше у творца свободы, пространства для манёвра — тем проще ему творить. Это совсем не так, потому что противоречит тому, как работает наш мозг. Человеческий мозг — удивительный орган. Он очень умный и ленивый (Марк использует тут только слово smart, но, имхо, в таком поведении больше лени и энергосбережения, чем мудрости — прим. пер.), и когда мы подкидываем ему какую-то задачку, мозг лезет в свои архивы с вопросом «Делали мы раньше нечто подобное?». Если ответ положительный — мозг, не утруждая себя, решает проблему тем же способом, что и в прошлый раз.

Чаще всего такой подход себя оправдывает, потому что позволяет избежать повторных раздумий, сразу переходя к решению. Но одновременно эта «оптимизация» вызывает проблемы с творческим мышлением. Когда в мозгу работают одни и те же нейроны, вы получаете один и тот же результат — а это совсем не то, чего хочется достичь в процессе творчества. Чтобы такого не происходило, я использую следующий трюк — если вы хотите, чтобы размышления привели вас в какое-то новое место, начните с новой точки отсчёта. Вот, почему я стараюсь начинать разработку каждого дополнения, сместив точку зрения. Это заставляет мой мозг думать по-другому, обнаруживать новые проблемы и пути их решения, а в результате — приходить к новым идеям. Говоря иначе, ограничения — это не препятствия, а полезный инструмент, который вы можете использовать для творчества.

FR: Многие люди думают, что начать всё с нуля просто. Многие люди просто не догадываются о «параличе(синдроме) чистого листа». Продолжать что-то всегда легче, чем начинать что-то. Но если требуется именно что-то начать, то лучше, действительно, поставить себя в узкие рамки. Так когнитивная деятельность будет собрана в одном направлении. Джон Кармак о магическом 0x5F3759DF как-то сказал: «Хорошо подобранные ограничения позволяют добиваться поразительных результатов» (пишу по памяти, т.к. не могу найти дословный источник этих слов). Буквально — хорошо проработанные рамки применения функции позволили разработчикам найти это удивительное сочетание байт и этим повысить производительность Q3 в десятки раз! Ещё есть очень действенная «теория малых усилий», в сути которой не надо чем-то прямо начинать заниматься, надо просто начать поднимать вопросы и фиксировать свои ответы на них. По набору критической массы вопросов лист уже не будет чистым, а новое дело уже будет начатым сразу со многих сторон. В целом, бездеятельность и прокрастинация характерна для всех людей, кто сталкивается с творческой работой или с чем-то, что он раньше не делал. Главное — не топтаться на месте. Главное — делать: или загонять себя в рамки, или идти малыми усилиями. Тогда успех для всех нас будет гарантирован!

Урок №19

Одна из моих многочисленных обязанностей заключается в том, что я выступаю в качестве представителя игры. Это выражается во взаимодействии с различными медиа-источниками, включая соцсети. Я активно общаюсь на многих платформах — Twitter, Tumblr, Instagram, где у меня более 80 тысяч подписчиков. Но наибольшее внимание я уделяю своему блогу на Tumblr, Blogatog`у. С момента начала ведения, то есть за четыре года, я ответил там примерно на 60 тысяч вопросов. Это огромный объём социальных взаимодействий, и благодаря ему я выучил вот такой урок:

Урок №19 — Игроки отлично распознают проблемы, но плохо их решают

Подходящая для этого урока метафора — посещение врача. Что врач обычно делает в самом начале? Он спрашивает — как вы себя чувствуете. Почему? Да потому что в этом вопросе — вы эксперт, никто лучше вас не знает, как вы себя чувствуете. Однако, на приёме врач довольно редко советуется с вами относительно лечения, потому что в этом — он эксперт и разбирается лучше вас. То же самое и с геймдизайном.

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

FR: Реакция игроков — это пульс жизни твоего проекта. Они действительно очень хорошо отзываются на изменения. Но, вот беда — игроки порой даже сформулировать своё мнение в понятную речь не могут. Обычно по отзывам можно понять только то, что кто-то просто недоволен. Может — недоволен твоей игрой, может — своей жизнью. И тут нам на помощь приходит сбор статистики! Когда-то давно я работал над сервером Ragnarok Online. В очередной версии Афины (eAthena — эмулятор сервера) разработчики оставили скрытую ошибку, приводящую к падению сервера. Кто-то из игроков нащупал эту ошибку и начал ее эксплуатировать, роняя сервер тогда, когда ему этого хотелось. И я не мог найти источник ошибки более месяца, т.к. она была в неправомерном доступе к памяти и сервер падал уже далеко после ошибочной ситуации. Некоторые игроки просто не хотят рассказывать о проблемах твоего проекта, надеясь как-то эти проблемы эксплуатировать. В результате мне написал другой игрок, который и рассказал о проблеме, после чего я её уже быстро исправил. Вот если бы в этот момент у меня уже была пользовательская статистика, я бы гораздо быстрее нашел закономерности и внёс нужные исправления в сервер. Сбор пользовательской статистики имеет очень большое значение для игрового проекта, т. к. он действительно даёт тебе обратную связь от пользователей в том виде, в котором тебе понятнее. Только это не значит, что с пользователями пора завязывать общаться напрямую. Это два взаимодополняющих метода изучения проблем твоего проекта.

Урок №20

Для подготовки к докладу, я выписал все мои уроки на доске.

Посмотрев на них как следует, я начал понимать нечто важное. На самом деле — уроки вовсе не обособлены друг от друга. Размышление об одном регулярно приводило меня к другому. Разве желание бросить вызов игрокам не увеличивает шанс того, что они полюбят игру? Или важные мелочи — неподходящий объект для исследования игроками? Если перестать путать «интересное» и «весёлое», разве не станет легче сделать забавную часть игры ведущей к победе? Чем дольше я смотрел, тем больше связей находил.

И тогда ко мне пришло осознание, отражённое в последнем уроке:

Урок №20 — Все уроки связаны друг с другом

Присматриваясь к каждому уроку, я понял, что они сильно взаимосвязаны, то есть в результате получились не отдельные уроки, а единая сеть с массой соединений. Я даже подумывал переименовать доклад в «20 лет, одна очень сложная взаимосвязанная целостная система взглядов на геймдизайн», но решил, что это недостаточно броско выглядит (нормально выглядит, берём! — прим. пер).

И это был последний урок: что все те вещи, которые я понял — часть единого целого.

FR: Я позволю себе оставить без комментария только один этот урок. В нём всё важное уже сказано :) Спасибо большое Марку за изложенные уроки! Все мы всегда чем-то увлечены и о чём-то забываем. Для каждого человека важно, чтобы где-то недалеко для него было оставлено несколько напоминаний о том, что он мог подзабыть в своей увлечённости. Каждый из уроков Марка можно отнести к подобным напоминаниям. И спасибо большое товарищу переводчику за его великолепный труд! (oh, stop it, you — прим. смущ. пер).