Услуги по геймдизайну и проектированию механик

Геймдизайн: проектирование механик

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

Механики: что мы проектируем

Движение и управление

Character controller — первое, что игрок трогает, и последнее, к чему привыкает. Ощущение от движения задаётся не скоростью персонажа, а acceleration и deceleration curves. В Unity это кривые в AnimationCurve или параметры в CharacterController. Мы не ставим линейное ускорение: в большинстве жанров правильный feel достигается через ease-in на старте движения и резкое торможение при отпускании кнопки.

Coyote time (150–200 мс после схода с платформы, во время которых прыжок всё ещё срабатывает) и jump buffering (прыжок регистрируется за 100–150 мс до касания земли) — это не «фичи», это стандарт платформеров. Их отсутствие пользователь не формулирует словами, но чувствует как «управление дубовое».

Инвентарь

Система инвентаря с виду простая, на практике — источник бесконечных edge cases. Stackable/non-stackable предметы, ограничения по весу vs. по слотам, drag-and-drop с валидацией, сохранение состояния между сессиями, серверная верификация в мультиплеере.

Мы проектируем инвентарь через данные: каждый предмет — ScriptableObject с набором параметров, слоты инвентаря — контейнеры, которые принимают или отклоняют предмет по набору правил (тип, класс персонажа, количество). Это позволяет добавлять новые предметы без изменения кода.

Боевая система: глубокий разбор

Боевая система — это та часть геймдизайна, где разрыв между «выглядит просто» и «сделано правильно» максимален. Возьмём melee combat как пример.

Hit detection

Два основных подхода: hitbox-based и raycast/spherecast-based.

Hitbox — коллайдеры на оружии и персонажах, пересечение = попадание. Работает хорошо в замедленных играх. При быстрых атаках появляется tunneling: за один кадр оружие пролетает насквозь, не зафиксировав пересечение. Решается через sweep test или через включение Physics.CCD (Continuous Collision Detection) — но это дорого по производительности.

Raycast/spherecast — каждый кадр во время активного окна атаки кастуем лучи или сферы вдоль траектории оружия. Точнее, меньше зависит от framerate, легче контролировать зону поражения. Мы предпочитаем этот подход для большинства action-игр.

Окна атаки (Attack Windows)

Каждая атака разбита на фазы:

• Startup — анимация замаха, персонаж уязвим, действие ещё не началось
• Active — активное окно хита, попадания засчитываются
• Recovery — анимация возврата, персонаж уязвим, отменить действие нельзя

Эти тайминги — не просто числа для аниматора. Они определяют ощущение боя. Длинный startup создаёт «тяжёлые» удары. Короткий recovery позволяет агрессивный стиль игры. В Souls-like длинный recovery — основной источник наказания за ошибку.

В Unity это реализуется через Animation Events: аниматор кидает событие в определённый кадр, код активирует/деактивирует hitbox или включает/выключает spherecast loop.

State Machine для персонажа

Боевой персонаж — это конечный автомат. В Unity мы используем Animator Controller как основу state machine, но бизнес-логику выносим в код, не в Animator. Animator управляет переходами анимаций, C#-код управляет переходами состояний персонажа.

Базовые состояния: Idle, Moving, Jumping, Falling, Attacking, Hurt, Dead, Blocking, Dodging. Каждый переход — явное условие. Переход из Attacking в Hurt происходит только если атака прерываема (некоторые атаки имеют iframes или super armor).

Иерархические state machines (через Override Animator Controller в Unity или Hierarchical State Machine в собственной реализации) позволяют делать вложенные состояния: например, Moving содержит подсостояния Walking, Running, Crouching, не дублируя переходы.

Экономика: математическая модель

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

Базовая модель прогрессии

Прогрессия в большинстве игр строится на одной из трёх математических моделей:

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

Экспоненциальная — XP(n) = base * multiplier^n. Стандарт для RPG. multiplier обычно от 1.5 до 2.0. При 1.5 — ранние уровни быстрые, поздние — долгие. При 2.0 — резкий рост сложности.

Полиномиальная — XP(n) = a * n^b. Более мягкий рост, чем экспонента. b от 1.5 до 2.5 для большинства игр.

Мы строим таблицы прогрессии в Google Sheets, прежде чем имплементировать в движок. Это позволяет за минуты проверить, сколько часов игрок потратит на каждый уровень при разных параметрах.

Игровая экономика: валюты и потоки

Базовый принцип: каждая валюта должна иметь явный источник (tap) и явный сток (sink). Если золото можно только получать, но не тратить на что-то ценное — оно обесценивается, инфляция убивает экономику.

Пример простой двухвалютной системы (характерна для мобильных f2p):

Однонаправленная конвертация (твёрдая → мягкая, но не обратно) защищает монетизацию.

Баланс через расчёт DPS и TTK

В экшн-играх баланс оружия строится на двух метриках:

DPS (Damage Per Second) — урон в единицу времени с учётом полного цикла атаки (включая recovery). TTK (Time To Kill) — время убийства противника с полным HP. TTK = HP_enemy / DPS.

Разные виды оружия должны иметь сопоставимый TTK против стандартного противника, но разные профили применения: пистолет быстро вытаскивается, снайперская винтовка высокий разовый урон, дробовик эффективен на близкой дистанции.

Дисбаланс легко обнаружить: если TTK какого-то оружия в два раза ниже остальных — это meta-оружие, и все будут использовать только его.

Нарратив и левел-дизайн

Нарратив не обязан быть текстовым. Environmental storytelling — расположение объектов, следы событий на уровне, звуковой дизайн — часто эффективнее диалогов.

Для диалоговых систем мы используем Ink (язык нарратива от Inkle) в интеграции с Unity. Ink позволяет писать разветвлённые диалоги с переменными и условиями в человекочитаемом формате, который редактирует нарративный дизайнер без участия программиста.

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

Инструменты геймдизайнера в нашем процессе

Итерация и плейтестинг

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

Мы проводим внутренний плейтест каждые две недели. После плейтеста — конкретный список изменений с приоритетами. Мнение «что-то не так с боем» — не задача. Задача — «startup-время атаки 400 мс, это слишком долго, сокращаем до 250 мс и тестируем снова».

Цифры меняются. Ощущения фиксируются. Цикл повторяется.