Sthrad 

Квестовая система настольных да и компьютерных игр обладает как несомненно полезными заимствованиями из альтернативных индустрий и личного опыта, так и недостатками, формирующими искаженный опыт, получая который, хочется встать на стульчик и кричать знаменитую фразу Станиславского: «Не верю!». Появляется это недоверие, когда внимательно понаблюдаешь за игрой современного игрока в различных играх. Чаще всего вне линейного повествования задания или квесты воспринимаются как что-то происходящее на фоне. Игрок исследует мир, общается с кем-то, убивает каких-то монстров и собирает квесты с наградами. В лучшем случае параллельно смотрит на маркеры и ходит по ним, как по меткам на интерактивной или бумажной карте. Исследовательская деятельность в такие моменты доминирует над сюжетной, поскольку мир на него реагирует либо позитивно, либо негативно, а чаще всего вообще игнорирует его деятельность. Из этой реакции довольно быстро рождается вопрос: а нужна ли в этом случае сюжетная часть и в чем вообще задача квестовой системы, если с постановкой целей она справляется неправдоподобно. Перечень схожих вопросов можно продолжать долгое время, а если начать на них отвечать объективно, то получается, что ты как дизайнер/ведущий что-то не то делаешь. Игроку для взаимодействия с миром, где подразумевается сюжет, нужны другие методы взаимодействия, либо дизайнить как-то иначе предложенные квестовые системы. При этом, оставляя широко используемые схемы квестов, остается ощущение, что они избыточны. Пусть задания выполняются автоматически, мы не будем мучать игроков лишней для него информацией, лишь выдавать награды за какие-то заранее проговоренные достижения. Зачем стремиться к выполнению целей, если выбор оных и скорость достижения ни на что не влияют. Являются ли они вообще игровой частью, либо это инструмент словесного или визуализированного сопровождения?

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

Поехали.

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

Почему же на эти вопросы важно ответить до получения ответов на такие стандартные вопросы как: кто живет в этом мире, как он называется или какая у него география... Важность этих вопросов связана с потребностью преодоления ассоциативного ряда, позволяющего отделить себя от своего творения. Автор столкнется с этой проблемой и потребностью опираться на опыт своих игроков, чтобы объяснять, как что-либо выглядит, социальные или физические процессы, а также уточнять на уровне личностного восприятия героев, почему то или иное событие важно или не имеет значения для них. Каждый раз отделяя от себя детали вашей придумки, придется преодолевать призму восприятия между собой и потребителем вашего мира. Если максимально упростить описание этого процесса – описывая мир, вы используете собственную систему ассоциативных образов, которая прошла закалку пережитого опыта, полученных знаний или субъективное восприятие окружающей реальности в другую не менее индивидуальную реальность. Не удивительно, что в результате, когда вы попросите игрока передать мир через детализированный текст или изображение, то с большой вероятностью не узнаете собственное творение. Рано или поздно автор, обнаруживший эту проблему, начинает тратить время и энергию, чтобы её ликвидировать, используя общепонятийные описания, общепринятые ассоциации или наполняя своё творение более детальными описаниями или изображениями. Однако, в каком-то смысле это Сизифов труд, который отнимает огромное количество времени и не всегда согласуется с изначальной целью или потребностью.

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

Как же не допустить этот конфликт и учитывать его, начиная препродакшен?

Давайте для начала разберемся, какие основные бизнес-модели используются рынком, и как это отражается на дизайне. На сегодняшний момент работающие модели (названия моделей не официальны, на место в Олимпе терминов не претендуют) следующие:

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

Кажущаяся простота продукта тем не менее вносит нюансы в зависимости от принятой модели дистрибуции:

1. Shelves (полка в магазине) – распространяя продукт через магазины, учитывайте потребность в пострелизной поддержке. Заложите возможность обновления продукта с помощью интернета. При этом делайте это модульно - печально смотреть на размер обновления, равный изначальному размеру игры.

2. Shareware – продается за первый час игры, а потому требует концентрации игрового процесса вначале. Дизайнеру необходимо продумать, как гарантировать получение игроком сконцентрированный обещанный игровой опыт, при этом не перегрузить новой информацией, сохраняя контент игры развлекательным. Сегодня этот метод скорее мертв, чем жив, а потому вероятно вы с ним можете не столкнуться на практике.

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

В ходе становления игровой индустрии команды разработки игр, начинавшиеся с одного - двух человек, по мере усложнения логики игрового процесса и качества игрового контента потребовали наращивать как размеры самих команд, так и разновидности экспертиз, ответственных за конечный результат. За последние двадцать лет только из гейм-дизайнера выделились следующие профессии: технический гейм-дизайнер; дизайнер уровней; дизайнер игровой экономики; дизайнер генералист; нарративный дизайнер; дизайнер UI/UX и т.д. Тенденция к распределению экспертиз по отдельным специальностям только нарастает, поскольку каждая студия обнаруживает, что какой-то аспект их проектов уступает конкурентам, и в попытках заполнить эти пробелы создает вакансии с узкой экспертизой. 

Подобный процесс, как вероятно, и во множестве творческих индустрий породил ряд побочных эффектов:

1. Размытая ответственность за конечный результат, распределенная между такими ролями как: продюсер, ведущий гейм-дизайнер, маркетолог или хозяин студии, в экстремальных случаях и вовсе не выделена в отдельного человека. Подобные перегибы видны и в киноиндустрии, где автор сценария временами с большим удивлением смотрит на конечный результат монтажа, однако там хотя бы ответственность ролей, на различных этапах производства, изначальна понятна: сценарист пишет сценарий, продюсер ищет деньги, занимается организацией съемок и т.д. В создании игр же получается наслоение из основной деятельности каждого специалиста, самодостаточной и требующей траты большей части рабочего времени. Удержание разработчиков в едином фокусе стало либо командным факультативом, либо отмазкой в стиле: посмотри, как сделано у конкурента. Я уверен, что в команде нужно выделить отдельную роль, деятельность которой будет сосредоточена на ответственности за получившийся продукт. Это должно стать основной обязанностью этого специалиста, в идеале он же должен инициировать как минимум проект, который контролирует, а возможно и другие проекты студии, используя свой опыт и остальные отделы бизнеса как инструменты проверки собственных гипотез. В противном случае команда, да и компания, которая платит за это деньги, становится заложником интерпретации множества людей чьей-то идеи, зачастую с неизвестным итоговым результатом. На мой личный взгляд, наиболее подходящая роль для этого: гейм-дизайнер или гейм-директор, если смотреть на успешный опыт западного производства.