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

Заодно попробую объяснить, что это за зверь такой GDD (Game Design Document). Тем, кто пришел из продуктовой разработки, всё это максимально знакомо. Геймдизайнер здесь совмещает роли системного и бизнес-аналитика. Представьте привычный Confluence с требованиями, вот тут то же самое.

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

🔹 Системная аналитика: Как связаны между собой механики. Если мы меняем логику урона, как это ударит по экономике и способностям командиров?

🔹 Бизнес-логика: Core Loop игры. Зачем игрок это делает, какая у него мотивация и как удерживается внимание.

🔹 Техническое задание: Конкретные условия срабатывания событий, приоритеты и формулы, которые программист потом просто переносит в код.

Но есть важный нюанс!
В геймдеве документ никогда не бывает финальным, он постоянно меняется. Важно быть к этому готовым:

🔹 После первого же теста механика может оказаться скучной и половину доки пускаем под нож.

🔹 Технические ограничения могут заставить упростить систему.

🔹 В процессе разработки приходят идеи получше, и это нормально.

Без этого документа проект превращается в бесконечные созвоны и выяснения "а как мы договаривались?".

Для инди-команды важно не уйти в бюрократию, а сделать короткую и понятную доку, которая будет отвечать на вопрос "как это работает?".

👇 А как вы ведете документацию? Пишете подробные спеки в Notion или всё держится на паре заметок и честном слове?

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

🌍 Я сразу вспомнил как днями и ночами залипал в Цивилизацию. Сидел и в деталях додумывал сюжеты. Мол сосед по карте расставляет армию по моему периметру потому что затаил на меня обиду и вот-вот нападет. На деле же никаких предпосылок не было. Это просто алгоритм так юниты передвинул, а всё остальное про личную неприязнь и коварные планы я себе сам нафантазировал.

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

Это работает по простым причинам

🔹 Это дешево. Не надо писать тысячи строк диалогов, система событий сама генерирует драму.

🔹 Это личное. История которую ты додумал сам всегда задевает сильнее чем то, что тебе навязал сценарист.

🔹 Это реиграбельно. Каждый раз мозг будет сшивать события по-новому.

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

🧐 А у вас бывало такое что вы видели в игре глубокий сюжет там, где на самом деле просто криво сработал рандом?

🎥 Я сделал это. Первый девлог готов!

Долго собирался с духом, боролся с перфекционизмом, но всё-таки решился. Я наконец-то записал первый видеоотчет о том, как продвигается разработка моей игры.

Это видео честный рассказ о том, как всё начиналось. Внутри про то, как затея «потыкать движок 2 часа в неделю» переросла в команду «Deckart», и почему мы потратили целый месяц на изучение Unity и джемы, прежде чем всерьез взяться за проект.

В этом выпуске я не спойлерю геймплей (всему свое время!), но подробно рассказываю про нашу «внутреннюю кухню» и то, какой путь мы уже прошли.

Посмотреть видео можно тут:
👉 https://youtu.be/sqq2tcUgasA

🚀 Мы теперь и в ВК

Чтобы проект рос, пора выходить на новые площадки. Я запустил сообщество в ВК, где буду собирать базу знаний по игре, писать лонгриды и делиться мыслями, которые не всегда помещаются в формат Телеграма.

Если вы сидите в ВК — залетайте поддержать проект на старте:

👉 https://vk.com/devchef

Спасибо всем за поддержку, это реально дает сил делать дальше. 🤝

Видосики это конечно здорово, но пора за работу 🛠

За сегодня и завтра план минимум сделать раздачу руки и привести старт игры в порядок. Работы еще гора и немного лихо от мысли, что уже через две недели нужно что-то показать.

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

Весь стиль и мякотка будут нарастать позже. Сейчас задача проверить, что этот скелет вообще может ходить и не разваливается на части при первом клике 🦴

Работаем дальше. Главное сейчас собрать рабочую базу, а лоск наведем, когда механика начнет приносить фан.

Сегодня поймал себя на одной мысли, пока ковырял код. Наш MVP, который я сейчас собираю, не даст никакого вау эффекта. И это нормально, к этому надо быть готовым. 🛠

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

Например:

🎯 Чувство, что ты гений, когда размотал монстра чисто на тактике.

🏰 Ощущение величия, когда твой замок реально процветает и растет.

🏆 Успех, когда твоя стратегия спустя час забега наконец-то дала плоды.

Но прикол в том, что в MVP этого опыта еще нет. Глупо ждать, что сухие цифры без звука, нормального визуала и баланса сразу подарят кому-то чувство триумфа.

Так что не ждите сейчас какой-то магии и атмосферы. Сначала заставим эту телегу ехать, а уже потом будем превращать её в феррари. Погнали дальше работать. 📈🚀

Разбираю сейчас стейт-машину в домене и хочу показать, почему обычный свитч это путь в никуда.

🐢 Обычно все начинают с процедурного подхода и создают огромный метод void Update(), внутри которого живет монструозный switch (currentState). И там начинается: если мы в GameState.Battle, то делай вот это на 500 строк, а если в GameState.Shop, то делай то еще на 300. В итоге файл пухнет, логика боя перемешивается с логикой магазина, становится тяжело вносить правки чтобы не развалилось всё остальное.

🧱 Я же использую паттерн, где каждый стейт это отдельный класс, реализующий интерфейс IState. Весь смысл в том, что логика разложена по полочкам.

🧬 Внутри домена это выглядит максимально чисто. Когда стейт-машина делает переход, она вызывает у текущего стейта, скажем BattleState, метод public void Enter(). В этот момент домен создает батл-контекст, инициирует врагов и делает ту самую раздачу карт в руку. Нам не нужно проверять, в бою мы или нет — если мы в этом методе, значит бой начался.

🧹 Когда игрок побеждает, вызывается public void Exit(). Здесь мы подметаем за собой: схлопываем временные данные боя и сохраняем остаток ХП.

🎯 Главный кайф здесь в инкапсуляции. Всё, что касается сражений, заперто внутри class BattleState, и магазин про это ничего не знает. Домен просто переключает классы и дергает события, а UI сидит на подписке и просто перерисовывает экран, когда видит, что активный класс сменился.

📦 Вместо одного монстра на 2000 строк у меня пачка маленьких и понятных скриптов. В них легко искать баги и еще легче добавлять новые механики.

Что думаете? Надо подробно расписывать паттерн или и так ясно зачем, как и почему?

Вчера в проекте появились первые враги, а это значит пора поговорить о том, как будет расти сложность. Точнее, обсудим ту самую «кривую сложности», которая либо заставляет игрока сидеть до ночи, либо удалять игру после второго боя.

📈 Суть кривой сложности не в том, чтобы просто накидывать врагам ХП и урон. Это путь в никуда. Если цифры растут линейно, игра превращается в скучную рутину. Настоящий азарт это когда сложность растет ступенями. Игрок только что освоил новую карту или механику, он чувствует себя крутым (состояние потока), и тут мы подкидываем ему новую задачку, которая заставляет мозг снова шевелиться.

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

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

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

Вам как больше нравится - попроще или посложнее?

Сегодняшнее утро в Москве чистый SnowRunner. Кто то помнит такую игру?

❄️ Снега навалило столько, что обычный выезд из двора превратился в квест на выживание. Пока буксовал в каше, всерьез задумался, стоило ли вообще сегодня заводить машину.

Кстати, о физике этого процесса. SnowRunner (как и MudRunner до него) работает на движке Swarm Engine, который написал наш разработчик Павел Загребельный. Вы спросите "почему не взяли какой-нибудь популярный Unity или Unreal Engine?" Ответ прост, эти движки из коробки не умеют так круто работать с «мягкой» поверхностью. Swarm Engine изначально затачивали именно под тяжелую технику и суровое бездорожье, чтобы земля под колесами была живой.

Если коротко, как это устроено:

🔹 В основе старый добрый C++ и скрипты на Lua.

🔹 Главная фишка в том, что поверхность в игре это не просто твердая текстура, а динамическая сетка. Она в реальном времени просчитывает, как колеса мнут снег или грязь, образуя колею.

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

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

Кстати, сделать гайд о том, как реализовать подобное проминание снега в Unity?

🚦 СТОЙ!

Продолжим тему авто и поговорим про светофоры. А вернее про блокировку потока.

Не думали никогда, почему ожидание зелёного бесит, а ожидание открытия двери в игре почти никогда? Хотя по сути это одно и то же. Вас искусственно останавливают. Разница не во времени ожидания. Разница в ощущении контроля.

В книге Designing Games Тайнан Сильвестер разбирает важную мысль - игрока можно задерживать, но нельзя лишать его ощущения участия.

Светофор это жёсткий стоп. Ты не влияешь ни на что.
Поток обрывается. В игре хороший дизайнер почти никогда не говорит “подожди 5 секунд”. Он маскирует задержку под действие.

Вот несколько элегантных способов:

🔹 Через усилие
Тяжёлая дверь открывается медленно. Ты держишь кнопку. Персонаж упирается плечом. Формально это пауза, но по ощущениям, процесс.

🔹 Через напряжение
Лифт едет долго. Но ты слышишь странные звуки. Это уже не загрузка уровня, это саспенс.

🔹 Через планирование
Перед боем дают время на расстановку. Тебя замедлили, но мозг работает. Поток не прерывается.

🔹 Через предвкушение
Анимация открытия сундука длится дольше, чем нужно технически. Но эта задержка усиливает награду.

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

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

🚦 А какая игровая “задержка” вас раздражает сильнее всего? Катсцены без скипа, медленные лифты, долгие анимации убийства босса или ещё что-то?

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

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

🎯 Все ради контроля и очередности. Теперь каждому событию на экране можно добавить значимости, настроить тайминги и акценты. Игра сразу начала чувствоваться иначе, появился вес у каждого действия.

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

Шаг за шагом к первой версии. 🃏🛠

— Артур, ну что там?

(Ветер бьет в лицо, снег забивается под куртку, но впереди наконец виднеются очертания строений)

— Я нашел место, где можно укрыться!
Старый шахтерский городок. Заброшенный. Недалеко отсюда.

***

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

Чтобы понять, как снег должен продавливаться под весом персонажа, пришлось самому поработать тестером и провалиться по пояс.

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

Разбор какой еще механики вам интересен? Сделаем из этого серию постов. 👇

Есть игры, которые не устаревают.
Они просто ждут, пока ты до них дорастёшь.
Сегодня в руках снова PlayStation Portable. Та самая, с легким люфтом кнопок и звуком загрузки, который мгновенно переносит в 2008-й.

И я запускаю God of War: Ghost of Sparta.

⚔️ И вот что интересно сейчас я смотрю на неё уже не как игрок. А как разработчик.
Через призму геймдизайна.

Первое, что бросается в глаза это контроль ритма.
PSP слабая по железу. Никаких масштабных арен, толп NPC и «живых» миров.

Значит, каждое столкновение это сконцентрированная сцена.

Небольшая арена.
Четкий заход врагов волнами.
Пауза.
Новый тип противника.

Это не хаос. Это дирижирование вниманием.

🎯 Враги появляются не просто так. Каждый новый юнит это микро-урок.

Щитоносец - учит ломать защиту.
Быстрый враг - учит таймингам.
Тяжёлый - контролю дистанции.

Игра не повышает сложность цифрами. Она повышает когнитивную нагрузку.

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

И вот сидишь с этой маленькой консолью и понимаешь: хорошие ограничения рождают чистый дизайн.

Иногда полезно взять старую игру и разобрать её не на ностальгию, а на механики.
Очень отрезвляет.

Векторная ярость или как научить моба преследовать цель 🏹

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

Сегодня моим полигоном стал спавн врагов и логика преследования игрока.

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

direction = target.position - transform.position
(Помните пост про операции над векторами?)

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

🕹 Еще один важный апгрейд сегодня переход на CharacterController. Раньше я мог просто двигать объект через transform.position, но это путь костылей. В таком случае объект превращается в привидение, которое проходит сквозь стены и игнорирует гравитацию. CharacterController это специальный компонент, который берет на себя всю грязную работу: он сам обрабатывает столкновения с препятствиями, позволяет персонажу заходить на ступеньки и не дает ему проваливаться сквозь землю.

Завтра попробую усложнить систему и добавить врагам немного мозгов, чтобы они не просто шли в лоб, а пытались окружить игрока.

КОНТРОЛЬ ИЛИ ИЛЛЮЗИЯ, ПОЧЕМУ ЧЕСТНАЯ ФИЗИКА ЭТО ЛОВУШКА 🕹🧱

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

Под прошлым постом закинули мысль, что Rigidbody — это фигня для управления. И в этом есть доля правды, если мы говорим о чувстве персонажа. Давайте по порядку.

⚙️ Rigidbody - симуляция физики.

Когда ты вешаешь на игрока Rigidbody, ты применяешь к объекту физику. Теперь у персонаж есть масса, трение и инерция.

Но вот в чем проблема - инерция превращает героя в корову на льду. Ты отпустил кнопку, а он всё ещё скользит к пропасти. Трение заставляет его буквально липнуть к стенам при прыжке.

Физический движок считает мир в своем ритме (FixedUpdate), и это часто создает микро-лаги между нажатием и движением.

📐CharacterController дело другое, тут не физика, тут кинематика. Это не физический объект, это математическая абстракция.

🔹 Нулевая дистанция. Ты диктуешь каждый миллиметр движения.
Хочешь мгновенную остановку? Пожалуйста.
Хочешь резкий рывок? Никаких проблем.

🔹 Умная геометрия. Он из коробки знает, как заходить на ступеньки и как скользить вдоль стен, не застревая в коллайдерах. В параметрах инспектора есть флажки.

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

Так что же выбрать?

Все зависит от того, какое ощущение от игры вам нужно.

CharacterController это стандарт для FPS, TPS и платформеров. Выбирайте если вам нужно, чтобы персонаж был резким, послушным и предсказуемым.

Rigidbody незаменим там, где физика и есть геймплей. Машины в GTA, тела в Gang Beasts или разрушаемое окружение. Здесь хаос и непредсказуемость это фича, а не баг.

🎯 Вердикт

Инструмент не должен мешать.
Говорить, что Rigidbody это фигня, это как ругать молоток за то, что им неудобно резать хлеб.
Если ты делаешь Human: Fall Flat или гонки, где физика — это и есть фан, Rigidbody твой единственный путь.

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

🗺 Свобода. Которой нет.

Люблю открытые миры. Огромная карта, можно идти куда угодно, делать что угодно. Но если чуть остановиться и посмотреть трезво, то в 80% случаев нас очень аккуратно ведут за руку.
Это иллюзия свободы.

Вроде бы перед тобой весь мир, но:
🔹 Горы расставлены так, чтобы ты шёл по нужной долине.
🔹 Разрушенные мосты мягко ограничивают ранний доступ к локациям.
🔹 Враги “случайно” слишком сильные, если ты пошёл не туда.
🔹 Точки интереса стоят так, чтобы ты видел следующую с предыдущей.

Ты выбираешь направление.
Но варианты уже заранее спроектированы.

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

С инженерной точки зрения это вообще отдельная магия. Навмеши режутся по уровням прогрессии. Триггеры подгружают события в нужной последовательности. Спавн противников контролирует темп. Даже камера иногда чуть-чуть корректирует угол, чтобы ты смотрел “туда куда надо”. Замечали такое, да?

И вот парадокс. Если игрок замечает ограничения то магия рушится, а если нет то мир кажется живым.

Вопрос к вам. Вам важнее реальная свобода с хаосом или хорошо поставленная иллюзия, но с сильным ритмом и историей?