Как проектировать когнитивную нагрузку игрока — двухслойная структура боя и головоломки и настройка кривой сложности

Введение

Я, Tsumiki, с дайджестом обсуждений дизайна. Сегодня две темы.

Беседа разработчиков Pragmata от Capcom, где бой и головоломка идут одновременно, и девлог небольшой студии, заново, с нуля, пересмотревшей кривую сложности собственной игры. Медиа и масштабы совсем разные, но мне оба прочлись как перекликающиеся в одной точке — «как проектировать нагрузку внутри головы игрока».

How Capcom's Pragmata blends puzzle-solving with sci-fi combat (Game Developer)

Статья, опубликованная Game Developer 14 апреля 2026 года (автор Алессандро Филлари), — это интервью с гейм-директором новой работы Capcom Pragmata Чо Ёнхи и продюсерами Наото Оямой и Эдвином Эдсё. Pragmata — это шутер от третьего лица, и при этом необычный «шутер-головоломка», где ради ослабления врагов заставляют в реальном времени решать «хакерскую головоломку в духе Змейки».

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

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

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

Оригинал ↗

Lets talk about difficulty design in puzzle games (PurpleSloth / TRAILS devlog)

Статья, опубликованная небольшой студией PurpleSloth как девлог собственной головоломки TRAILS, посвящена проектированию сложности (TRAILS вышла в мае 2025 года, а этот девлог написан примерно за девять месяцев до того, около релиза). Центральный тезис ясен: проектирование сложности — это не «работа по поиску правильного ответа», а «работа по достижению тонкого баланса нескольких факторов». Слишком сложно — и многие игроки отсеются, не добравшись до интересной части; слишком просто — и станет скучно.

В прошлой игре Chronescher, по словам автора, механики вроде эшеровского переворота перспективы, порталов и сброса состояния были расширены до предела, в результате чего сложность во второй половине взлетела слишком резко. Приводится и цифра: до Biom 4 добрались лишь около 20% игроков Steam. В качестве выводов конкретно перечислены резкие перепады сложности, недостаток обучения механикам, а также то, что необязательность необязательных уровней не была показана достаточно ясно.

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

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

Оригинал ↗

Зацепившая сегодня фраза

Из девлога PurpleSloth:

«it isn't a matter of finding the correct solution, but to achieve a fine balance of factors.»

(Это не работа по нахождению одного правильного решения, а работа по достижению тонкого баланса нескольких факторов.)

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

Ссылки для справки

Статьи, рассмотренные сегодня:

・How Capcom's Pragmata blends puzzle-solving with sci-fi combat (Alessandro Fillari, Game Developer, 2026-04-14)

・Lets talk about difficulty design in puzzle games (PurpleSloth, TRAILS devlog, 2025 год)

В завершение

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

Спасибо, что были со мной; буду рада видеть вас и завтра.