Гейм-Дизайн Каннибалы: Кто Съедает AAA Игры и Зачем?

I. Предисловие: «Сладкое сердце игры: История одной фразы»

Мысль об этой статье началась давно с простой, на первый взгляд, фразы. Я услышал её на одной из конференций несколько лет назад от разработчика мобильных игр — человека, который явно знал своё дело. Он говорил о процессе создания новых проектов, когда уже на секции Q&A кто-то из зала спросил:

— «Как придумать идею для мобильной игры?»

Ответ прозвучал так просто, что я даже не сразу понял его глубину:

— «Возьми AAA-проект, уберите всё лишнее и оставьте только самое сладкое — то, что заставляет людей играть снова и снова.»

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

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

Давайте честно: Успех, да именно успех, Diablo Immortal — это не просто случайность или пример «вырезания» механик ради «широкой» мобильной аудитории. Несмотря на знаменитую фразу «Do you guys not have phones?» с BlizzCon 2018, которая стала мемом и символом разочарования для многих поклонников серии, игра показала впечатляющие результаты. На момент релиза она собрала более 15 миллионов загрузок только за первую неделю, а ежемесячная аудитория продолжает оставаться на высоком уровне даже спустя годы после выхода. Почему? Осмелюсь заявить, что разработчики действительно поняли, как вытащить самое важное из оригинального опыта Diablo и адаптировать его под новую, для серии, платформу. Они оставили те самые «сладкие» элементы: Гринд, лут (и лутбоксы), механику убийства (закликивания) врагов и награды, но убрали всё лишнее, что могло отпугнуть новичков или создать проблемы с производительностью на мобильных устройствах.

А PUBG Mobile — это вообще особый случай. Когда корейская студия PUBG Corp решилась на портирование своего многопользовательского шутера на мобильные платформы, многие скептически относились к этой идее. Как можно адаптировать тактический шутер с долгими матчами и сложным управлением для телефонов? (Учитывая при этом, что средняя длительность игровой сессии рядового игрока в мобильные игры до 2019 года и ковида — это от 6 до 20 минут максимум.) Но разработчики сделали именно то, о чём говорил мой коллега по цеху с конференции: Они взяли самое главное — аркадную стрельбу, азарт от победы и динамику противостояния — и упростили всё остальное до предела. Матчи стали короче, управление — интуитивным (и даже с механиками типу авто-подбора предметов придумали), а интерфейс сделали максимально удобным для сенсорных экранов. И знаете что? Это сработало. PUBG Mobile не просто повторила успех своего PC-собрата — она превзошла его. По данным различных аналитических компаний, мобильная версия игры приносит примерно вчетверо больше дохода, чем оригинал, и имеет куда большую аудиторию. Фактически, «сердце игры» не просто продолжает биться — оно стало сильнее, когда было пересажено в новое тело.

Конечно, можно сказать, что это — адаптация под мобильный формат, что «нельзя сравнивать тёплое с мягким». Но ведь механики-то, вот они, на поверхности! Упрощённые, обрезанные, но всё ещё узнаваемые. Давайте начнём с самого начала.

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

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

Поэтому мы попробуем разобраться с двумя явлениями:

И ещё, для наглядности и лучшего понимания сути моего анализа специально была создана авторская диаграмма «Песочные часы Гейм-Дизайна». Она ОЧЕНЬ сильно постарается отразить не только суть описанного мной процесса, но и визуально представить, как именно происходит деконструкция и последующая конструкция игровых механик. Центральным звеном этой диаграммы будет являться то самое «Сладкое сердце» — ключевая механика, которая сохраняет привлекательность и вызывает желание игроков возвращаться к игре снова и снова. В процессе мы будем периодически возвращаться к этой диаграмме, чтобы дополнить её и четче представлять механизмы адаптации и трансформации.

Ну и в конце концов, каждая игра — это история, а истории можно пересказывать по-разному. Вот и я попробую.

II. Часть 1: «Как съесть слона? (По кусочкам)»

Во-первых, мне необходимо поставить любого читателя перед фактом: Создание мобильных игр — это не так просто, как может показаться на первый взгляд. Ну, а создание успешных мобильных игр ещё сложнее. Я часто натыкался на мнение, а иногда и советы, что успех в этой индустрии заключается в том, чтобы сделать игру максимально простой, быстрой и «вирусной», как те видео, которые мы видим в TikTok, Reals, Shorts, рекламных роликах ну и т. д. Но это — заблуждение, пусть и вызванное верным, но поверхностным наблюдением, ведь, по правде говоря, 70% игр на площадках — это как раз эти «вирусные» игры. Тем не менее важно в этом феномене другое, а именно, что большинство из них имеют драматически короткий жизненный цикл — иногда даже меньше недели. После этого они исчезают.

Однако «жалеть» данных разработчиков не нужно, потому что их стратегия изначально рассчитана на быструю отдачу, а не долгосрочное выживание. Эти игры создаются с одной целью: Собрать максимум прибыли за минимальное время, используя всплеск интереса от вирусного контента или агрессивной рекламы. Это своего рода «одноразовые» проекты, которые не стремятся к устойчивому успеху. Но если взглянуть на оставшиеся 30%, становится очевидно, что такие игры — лишь вершина айсберга. Под водой скрывается гораздо более интересный и сложный мир мобильных игр, где успех уже измеряется не днями или неделями, а годами.

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

Дело в том, что «долгоиграющие» мобильные хиты, как правило, обладают важным качеством: Они создают глубину, которая удерживает игроков месяцами, а то и годами. При этом глубина эта может быть не такой очевидной, как в AAA-играх, но она существует. Зачастую она выражается через аддиктивные системы, которые работают на подсознательном уровне, вызывая желание возвращаться снова и снова.

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

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

Простое портирование AAA-игр на мобильные устройства редко приводит к успеху. Возьмём, к примеру, Grand Theft Auto: San Andreas, Death Stranding или Resident Evil. Эти игры были встречены, мягко говоря, с большим интересом на своих основных платформах, но их попытки «переехать» на мобильные устройства оказались даже на четверть не столь успешными. По крайней мере я не знаю ни одного человека, который сказал бы «О, я прошел Death Stranding на iPhone, мне очень понравилось!», но почему так? Дело не только в технических ограничениях — хотя они, безусловно, играют свою роль. Основная проблема заключается в том, что эти игры сохраняют свои сложные системы и долгие игровые сессии, которые просто не подходят для мобильной аудитории.

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

Как происходит деконструкция?

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

Чтобы понять этот процесс, давайте представим Гейм-Дизайн как приготовление блюда. Представьте, что AAA-игра — это сложное, многослойное блюдо, приготовленное, скорее всего, в хорошем ресторане, пусть это будет, например, лазанья. В ней есть множество ингредиентов: Соус, сыр, тесто, фарш, специи — каждый из них играет свою роль, ровно так же как и оборудование и персонал, тем самым создавая уникальный вкус. Теперь представьте, что вам нужно приготовить что-то похожее, но для совершенно другой аудитории — скажем, для людей, которые предпочитают лёгкие закуски, стрит-фуд! Вы не можете просто подать им целую лазанью, потому что она слишком сытная, требует много времени для приготовления, дорогая, да и в конце концов сложная для такого случая — не переварить! Вместо этого вы берёте самые важные элементы — например, сыр и соус — и создаёте на их основе что-то новое, например, мини-пиццу или сырные палочки.

Ингредиенты одни и те же (сыр и соус) и результат ТОЖЕ один и тот же! (Приятное вкусное блюдо и сытный желудок.)

Точно так же происходит с мобильными играми. Разработчики берут сложные системы из AAA-проектов и вычленяют из них «основные ингредиенты» — те механики, которые действительно вызывают удовольствие и зависимость. Затем они перерабатывают эти механики, чтобы они работали в новом контексте. Это не просто упрощение — это переосмысление, которое без понимания или владения навыками кулинарии работать НЕ будет.

Прекрасно, теперь вы тоже владеете этим знанием! А потому прошу к столу. Теперь, когда у нас есть общее понимание инструментов и «кухни» этой части Гейм-Дизайна, мы можем перейти к самому интересному — увидеть процесс деконструкции в действии. Как говорится, «лучше один раз увидеть, чем сто раз услышать». Именно поэтому мы сейчас разберем конкретный пример, который, на мой взгляд, было бы грех не использовать — Genshin Impact.

Эта игра, одна из самых прибыльных мобильных игр в мире, начиналась с простого, но в то же время сложного вопроса:

— «Как перенести опыт полноценной RPG на мобильные устройства?»

Разработчики из miHoYo не стали изобретать велосипед. Они провели быстрый анализ мобильного железа на рынке, поняли, что Nintendo Switch использует железо примерно на том же уровне, что и средне-бюджетные телефоны (на момент 2020 года), а самый успешный пример в жанре с лучшим визуалом — это The Legend of Zelda: Breath of the Wild. 2+2 = БИНГО!

Именно эта игра стала отправной точкой для, мною предполагаемых, их исследований. miHoYo внимательно изучили Zelda: BOTW, разбирая её механики, визуальный стиль и подход к открытому миру. Но просто скопировать её было бы недостаточно — мобильные устройства имеют свои ограничения, а игроки свои предпочтения, что требует учёта и тщательной деконструкции ключевых элементов.

Прежде чем двигаться дальше, предлагаю вам сделать маленькую паузу. Попробуйте поставить себя на место разработчиков Genshin Impact, в частности Гейм-Дизайнера. Задайте себе вопрос:

— «Как бы ВЫ перенесли опыт игры из Zelda: BOTW на мобильные устройства?»

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

Пример #1: Открытый мир и исследование

Итак, в BOTW открытый мир представляет собой огромное, бесшовное пространство, где игрок может свободно перемещаться куда угодно с самого начала игры. Это создаёт обескураживающее чувство свободы, когда вы видите гору на горизонте и действительно можете на неё забраться. Исследование вознаграждается постоянно: Святилища, коруки, новое снаряжение — всё это разбросано по миру и мотивирует игрока постоянно двигаться дальше.

Проблема для мобильных устройств:

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

Наше Гейм-Дизайнерское решение:

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

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

Награды могут варьироваться от совсем незначительных (обычные расходники) до более ценных (сундуки с примогемами, уникальные предметы), но важен сам принцип: Любопытство всегда вознаграждается. Таким образом, игрок быстро усваивает правило: «Если я вижу что-то необычное — стоит проверить».

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

Почему это работает с точки зрения Гейм-Дизайна:

Мы создаём замкнутый цикл вознаграждения: Любопытство ведёт к исследованию, исследование приводит к награде, а награда усиливает любопытство.

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

Пример #2: Боевая система

BOTW, будучи в некотором смысле духовным предшественником соулс-подобных игр (о чём мы обязательно поговорим в какой-нибудь другой раз), предлагает довольно комплексную боевую систему, где успех игрока зависит от множества факторов. Это не просто реакция и нажатие кнопок — это маленькое, но приятное решение тактического пазла. Игрок должен следить за прочностью оружия, подбирать правильное снаряжение под конкретных врагов, искать материалы для улучшений и постоянно адаптироваться. Ключевая особенность: Весь сок от боевых ситуаций заключается в планировании и грамотном подборе инструментов для конкретной задачи.

Проблема для мобильных устройств:

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

Наше Гейм-Дизайнерское решение:

Нам необходимо сохранить сущность боевой системы BOTW — идею «тактического пазла», но реализовать её таким образом, чтобы она работала с простым управлением и была интуитивно понятна с первых минут. Решение:

Почему это работает с точки зрения Гейм-Дизайна:

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

Пример #3: Прогрессия и система наград

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

Проблема для мобильных устройств:

Мобильные free-to-play игры требуют более продолжительного жизненного цикла и постоянного возвращения игрока. Модель без ограничений, как в BOTW, может привести к тому, что игроки «выгорят», пройдя весь контент слишком быстро. Кроме того, должен быть баланс между бесплатной и платной прогрессией, нам же тоже кушать хочется, а не только кормить!

Наше Гейм-Дизайнерское решение:

Почему это работает с точки зрения Гейм-Дизайна:

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

Конец трапезы!

Фух! Это был, конечно, сытный слон. Но давайте честно: Даже такой анализ Genshin Impact — это лишь верхушка айсберга. Если бы мы разбирали все примеры деконструкции AAA-игр в мобильном формате, да даже просто самые интересные (коих много), пришлось бы съесть целое стадо слонов! У меня пока аппетит не настолько велик, поэтому остальные кейсы (например, как PUBG Mobile переработала механики PUBG: Battlegrounds, а Mobile Legends упростил League of Legends) оставим для комментариев или будущих статьях!

Ну и подведём итоги правил деконструкции: Чем мы можем подкрепить идею «Возьмём механику из игр А и Б и встроим в наш проект»?

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

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

Вторая ступень — «Фильтрация и упрощение». Это центральная и, возможно, самая важная часть деконструкции. Здесь происходит отсев элементов, которые не вписываются в новый формат или не соответствуют новым ограничениям. Мы выявляем «ключевые точки удовольствия», адаптируем механику под платформу и технические ограничения (упрощаем управление, сокращаем сессии), и избавляемся от того, что может перегрузить игрока или устройство. Если вернуться к нашим примерам — здесь из Zelda: BOTW убирается бесшовный мир, сложные тактические схемы боя и оставляются только чистые эмоции исследования и боя, теперь максимально адаптированные под мобильный формат.

Наконец, завершающая треть верхней части нашей диаграммы — это этап «Финальной выжимки». Здесь мы уже держим перед собой существенно упрощённую, но всё ещё узнаваемую структуру оригинала. Это этап, на котором проверяется эффективность деконструкции: Мы смотрим, удалось ли сохранить ядро игрового опыта (Core Loop), баланс между доступностью и увлекательностью и готова ли полученная выжимка стать основой дальнейшей работы.

Итак, как же сформулированные нами ранее три правила помогают нашей диаграмме? Если внимательно присмотреться, становится очевидно, что каждое правило чётко коррелирует с этапами деконструкции на диаграмме. Например, правило Key Core Extraction (выделения ядра) чётко отражает переход от «Изначальная комплексность» к «Фильтрация и упрощение». Правило Platform Alignment (платформенного соответствия) проявляется именно на этапе «Фильтрация и упрощение», когда мы адаптируем механики под новую платформу и её ограничения. А правило Multi-Layer Progression (многозадачной прогрессии) находит своё применение уже ближе к этапу «Финальной выжимки», где мы формируем систему прогрессии, которая не просто удерживает игрока, но и создаёт мотивацию возвращаться в игру вновь и вновь.

Итак, мы разобрались, как съесть слона, превратить лазанью в сырные палочки, деконструировать игру и в чём мы только не разобрались… Но что, если теперь попробовать наоборот? Взять рецепт простой закуски и создать из него полноценное блюдо? Например, взять механику бега из Subway Surfers и добавить к ней рогалик-элементы, процедурную генерацию и сюжет, который заставит игрока возвращаться не за «быстрым перекусом», а за полноценным погружением.

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

III. Часть 2: «Как построить дом? (Из кирпичей)»

Эта часть статьи — самая личная для меня. Потому скажу честно: Не будь у меня проф-деформации Гейм-Дизайнера и необъяснимого, почти мазохистского желания участвовать во всевозможных бета-тестах и закрытых показах, этой статьи, вероятно, никогда бы и не было. Вся его задумка, весь этот, с позволения сказать, «дерзкий анализ» родился именно благодаря одной моей проф-привычке — совать свой любопытный нос буквально в каждую хоть немного любопытную разработку.

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

Бета-тесты для меня обычно — это просто любопытный опыт и пища для размышлений, но HASTE: Broken World давно витал в поле моего зрения. Желание «пощупать» игру было довольно сильным, не только потому, что игра сама по себе выглядела интригующе, но и потому, что я просто-напросто люблю LandFall и их подход к разработке (ребята, огромный привет!). Поэтому, когда появилась возможность поучаствовать в закрытом бета-тестировании, я мгновенно её ухватила. И вот во время очередного тестового забега, когда я механически пробегал через процедурно генерируемые локации, мозг начал задавать вопросы: «Что я сейчас чувствую? Почему такая простая механика затягивает? Что конкретно в ней цепляет?» И именно тогда я разглядел не только то, как простота может складываться в нечто большее, но и другую сторону монеты: Не просто деконструкцию сложных механик, но и обратный процесс — конструкцию. Вот и ответ, вот и вторая сторона медали, вот и тема для моей статьи!

(К слову, если вы ещё не опробовали недавно вышедшую демку HASTE в Steam, то бегом исправляйте это упущение!)

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

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

Как происходит конструкция?

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

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

Условно говоря, мобильная (или казуальная) игра зачастую сплошь состоит из сахарных кубиков: В ней полно положительного подкрепления, быстрых наград и максимально понятных правил. У тебя есть только «коробка», внутри которой всё, кроме самой основы — это чистое наслаждение для игрока. Однако если ты хочешь превратить эту «коробку» во что-то большое, надёжное и разнообразное, необходимо добавить «кирпичи» более глубоких, осмысленных механик. А это, в свою очередь, требует последовательного и вдумчивого планирования — точно так же, как при деконструкции мы ищем скрытые слои и удаляем всё лишнее, тут мы можем столкнуться с проблемой избытка «сладости», которую нужно разбавить «текстурой» осмысленных механик, систем, рогалик-элементов, процедурных генераций и прочего.

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

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

Если прямо сейчас открыть футаж Subway Surfers слева и поставить рядом HASTE: Broken World справа, то даже беглого взгляда будет достаточно, чтобы увидеть сходство — примерно такое же, как между Genshin Impact и Zelda: BOTW, о которых мы говорили ранее. Это опять же не значит, что кто-то у кого-то «ворует» идеи (мы-то прекрасно знаем, что LandFall пришли к своей концепции совсем другим путём, через внутренние тесты совершенно другого проекта, по очень тернистой трёхлетней дороге). Но представьте на секунду, что именно вам пришла бы такая безумная и в то же время гениальная идея:

— «А почему бы не взять Subway Surfers и не расширить его до уровня полноценного, большого проекта?»

С какими трудностями вы бы столкнулись? Как бы вообще выглядел процесс такого мышления?

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

И вот здесь-то наш мозг и начинает буксовать. Первая ловушка, в которую мы рискуем попасться — это начать опираться на уже существующие референсы и примеры. Например, Sonic — «Ну там же персонаж тоже бежит, и вроде тоже быстро, давайте сделаем как там!» Но постойте, мы же здесь не за тем, чтобы просто скопировать мобильный Subway Surfers и превратить его в «ещё одного Соника»? Это явно не наш путь.

Следовательно, на этом этапе Гейм-Дизайнеру нужно максимально чётко понимать, по каким именно правилам и принципам он будет строить новую игру вокруг существующей простой механики. И вот тут мы с вами в очередной раз погрузимся в самую аналитическую часть статьи — представим себя теми самыми Гейм-Дизайнерами, которые получили неожиданное ТЗ:

— «Вот вам мобильный раннер Subway Surfers — ваша задача расширить эту механику до уровня полноценной игры, глубокой и комплексной, при этом сохранить её базовую привлекательность, но не превращать всё это в Sonic».

Забудем на секунду, что LandFall уже сделали нечто похожее (ведь у них всё равно был другой подход). Забудем, что существует HASTE: Broken World. Попробуем просто решить эту задачу с чистого листа, опираясь лишь на фундаментальные Гейм-Дизайнерские принципы и логику, о которых мы уже говорили ранее.

Итак, засучим рукава и начнём «cтроить дом».

Пример #1: От «трёх полос» к осмысленным приземлениям

Если в классическом Subway Surfers игрок свайпает влево-вправо, перепрыгивает барьеры и собирает монетки на трёх зафиксированных полосах, то при расширении данной механики нам хочется добавить больше вариативности и умелого контроля. Ведь базовый раннер не предполагает никаких тонкостей — ты либо перепрыгнул преграду, либо врезался. А что, если ввести дополнительный параметр качества приземлений, напрямую влияющий на результаты забега?

Проблема, которую мы решаем:

В типичном «бесконечном раннере» (Subway Surfers, Temple Run, Minion Rush) бег со временем может казаться слегка монотонным: У игрока нет глубоких инструментов для выражения мастерства, кроме как быстрых свайпов или реакций на препятствия. Хочется, чтобы каждый прыжок или скольжение имел чуть более стратегическое измерение, пусть и в рамках всё той же динамичной механики «беги и не останавливайся».

Наше Гейм-Дизайнерское решение:

Добавляем систему «приземлений» — своего рода мини-проверку мастерства каждый раз, когда персонаж возвращается на землю после прыжка или падения. Представьте, что у нас есть шкала «точности» или «тайминга», и в зависимости от того, насколько умело (или неумело) игрок приземляется, он получает разные бонусы (или штрафы).

Почему это работает с точки зрения гейм-дизайна:

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

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

В-третьих, за счёт системы бонусов и штрафов мы подталкиваем игроков пересматривать свою тактику по мере роста навыка. Чем лучше ты приземляешься, тем быстрее копишь ресурсы и тем более рискованные приёмы можешь себе позволить.

Доп: Лёгкое упоминание о «Доске» и похожих бустерах

Кроме того, в Subway Surfers есть «доска» — бустер, позволяющий временно избегать поражения и получать бонусы. Такая простая вспомогательная механика идеально решает проблему монотонности. В HASTE: Broken World существует похожая реализация — «Surfboard», однако здесь это не просто пассивный бустер, а полноценная активируемая способность, потребляющая ресурс (энергию), который игрок зарабатывает через успешные приземления. Это снова добавляет слой тактического принятия решений: Игрок должен не просто использовать способность по кулдауну, но и решать, когда именно и как её применить, учитывая своё текущее состояние и уровень накопленной энергии.

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

Пример #2: От скучной повторяемости к управляемому росту сложности

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

Проблема, которую мы решаем:

В классических мобильных раннерах через некоторое время наступает «плато сложности». Да, скорость продолжает расти, но истинного разнообразия нет: Всё упирается в повторяющиеся комбинации препятствий, которые можно заучить. Игрок, освоив паттерны, утыкается в тупик, где-либо умирает только из-за высокой скорости (а не из-за нового интересного челленджа), либо теряет интерес, потому что «всё уже видел».

Наше Гейм-Дизайнерское решение:

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

Почему это работает с точки зрения гейм-дизайна:

Процедурная (или гибридная) генерация с «бюджетом сложности» не даёт игроку заскучать: Трасса постоянно меняется, и привычные паттерны могут комбинироваться неожиданными способами. Кривая сложности регулируется плавно, соответствуя мастерству игрока, и поддерживает так называемый Flow — когда челлендж кажется трудным, но не безнадёжным. А система вознаграждений делает каждый успешный забег ценным, мотивируя развивать навыки. Позволяя динамической генерации «настраивать» уровень препятствий по мере роста мастерства игрока, в итоге каждая сессия ощущается свежей, оставаясь при этом в рамках изначальной формулы «просто беги».

Пример #3: Сводка коротких решений

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

Почему это работает с точки зрения Гейм-Дизайна

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

Дом который построил Дж… Гейм-Дизайнер!

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

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

Итак, какие важные правила мы можем вывести из всего вышеизложенного, чтобы максимально грамотно использовать «Конструктивный» подход?

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

Первая ступень — «Стартовое ядро». Здесь у нас есть чистая, адаптированная под формат механика, которая должна быть максимально интуитивной и отзывчивой. Это некая «базовая коробка», вокруг которой мы собираемся строить всю дальнейшую сложность. На этом этапе крайне важно удостовериться, что основа действительно увлекательна сама по себе. Если стартовое ядро не доставляет удовольствия, никакие дополнительные системы не спасут проект.

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

Третья ступень — «Итоговая комплексность». На заключительной стадии у нас формируется многослойная, осмысленная структура. Каждая новая система обретает своё логичное место, а мотивационные циклы становятся более глубокими и разнообразными. Здесь мы проверяем, удалось ли нам сохранить баланс: Не потонул ли проект в бесконечных механиках и остаётся ли он всё таким же доступным, как в самом начале? Именно на этом этапе становится ясно, достигли мы желаемой глубины, когда игра способна удержать игрока надолго, не перегружая или наоборот не давая ему достаточно фидбека.

Опять же, если приглядеться, то те правила, которые мы сформулировали для конструктивного подхода, соответствуют каждому из этих этапов. Например, правило Core-Driven Expansion (опора на ядро) напрямую отражает важность «Стартового ядра». Правило Modular Layering (модульная надстройка) отсылает нас к «Модульному расширению», когда каждая новая система аккуратно наслаивается на предыдущую. А такие принципы, как Meaningful Complexity (значимая сложность) и Motivation Loop (мотивационный цикл), помогают нам грамотно достроить финальную стадию, формируя сбалансированный игровой опыт, где глубина не убивает доступность, а игроки возвращаются вновь и вновь.

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

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

А пока — считайте, что наш дом закончен. Пора открывать шампанское, запускать праздничные фейерверки и заканчивать это всё!

IV. Заключение: «Сладкое сердце Гейм-Дизайна»

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

Теперь, когда перед нами развернулись обе части нашей диаграммы «Песочных часов Гейм-Дизайна», можно сказать, что она стала своеобразной универсальной «линзой»: Переверните её — и вы смотрите на процесс деконструкции; оставьте в исходном положении — и вы наблюдаете, как простое ядро обрастает системами. Данная схема не претендует на абсолютную универсальность и требует доработок под конкретный проект, однако уже сейчас, по моему мнению, хорошо иллюстрирует некоторые ключевые константы Гейм-Дизайна. Мы можем одинаково успешно применять её для анализа больших игр, которые нужно упростить, и для расширения скромных базовых механик до более глубокой структуры.

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

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

Если вы когда-либо задавались вопросом, как сделать вашу игру одновременно глубокой и доступной, то я призываю вас не бояться экспериментов с конструкцией и деконструкцией. Возьмите механику из любимой игры, упростите до основы и попробуйте вновь «вырастить» её, добавляя слои значимых и интересных систем. По крайней мере теперь вы можете это сделать на бумаге! Так что вперед к своим Гейм-Дизайн Документам!

P.S:

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

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

Увидимся там, где секретов больше → t.me/slepokNT

— Конец —