РАЗРЫВАЕМ СВЯЗАННЫЙ КОД: КАК СООБЩИТЬ ВИЗУАЛУ ОБ ИЗМЕНЕНИЯХ 🛠

⌨️ Давно у нас не было постов на техническую тему, пора исправлять. Сегодня разберем Event Bus (Шину событий). Если вы когда-нибудь пытались напрямую из логики меча вызвать скрипт UI-полоски здоровья — вы создали «жесткую связь». Стоит удалить врага из сцены, как ваш код посыплется с ошибками NullReferenceException.

🧠 Решается это через аналогию с почтальоном. Издательство просто отдает газеты на почту, а почтальон разносит их подписчикам. В нашей игре это работает так: когда командир бафает отряд, симуляция на C# меняет статы и просто создает объект события — например, new StatChangedEvent { UnitId = 10, NewVal = 15f }.

🧠 Сама шина это по сути «умный» словарь Dictionary<Type, List<Action<IEvent>>>. Когда мы хотим, чтобы Unity узнала об изменениях, мы вызываем метод EventBus.Raise(IEvent ev). Он берет тип пришедшего события через ev.GetType() и пробегает циклом по всем функциям, которые на него подписались через Subscribe.

😠 Визуальная часть игры при старте делает EventBus.Subscribe<StatChangedEvent>(OnStatChanged). Теперь, как только в недрах математического движка изменится хоть одна цифра, Unity мгновенно получит уведомление и запустит нужную анимацию свечения или звуковой эффект.

🤨 Главный плюс то что симуляция и визуал живут в разных мирах. Логика расчёта бафов вообще не знает, есть ли у нас в проекте Unity, частицы или камера. Если завтра я решу добавить тряску камеры при бафе, мне не придется менять ни строчки в коде статов, я просто добавлю нового подписчика в визуальный слой.

👇 Кстати, внимательный разработчик заметит в моем коде одну потенциальную проблему, кто догадался?

Сразу вдогонку к шине событий разберем еще одного кита архитектуры Dependency Injection (DI). Те, кто пришел из бэкенда (особенно из .NET/ASP.NET), сейчас сразу поймут, о чем речь: мы тащим в геймдев классические DI-контейнеры.

❌ Проблема: Чем больше проект, тем сложнее объектам находить друг друга. Юниту нужен CombatEngine, движку нужен SoundManager, менеджеру нужны GameSettings. Если каждый будет искать соседа через FindObjectOfType или стучаться в глобальные синглтоны, ваш проект превратится в карточный домик: тронул одно — посыпалось всё.

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

🏗 Наш выбор это VContainer. Это быстрый и легкий DI-контейнер. Мы выбрали его за производительность и минимализм. Суть проста, есть единая точка сборки LifetimeScope, где мы регистрируем всё через builder.Register<IBattleSim, BattleSim>(Lifetime.Singleton). Теперь контейнер сам знает, кому и что нужно доставить.

👩‍💻 Для чистых C# классов (наша логика) всё работает через классический constructor injection. Контейнер видит, что классу нужен интерфейс, и сам его подставляет: public BattleProcessor(ICombatData data) { ... }. Весь граф объектов собирается автоматически.
Нюанс есть с монобехами. У компонентов Unity нет конструктора, их создает сам движок. Чтобы прокинуть в них зависимости, используется метод с атрибутом [Inject]

👌 В итоге вся архитектура становится прозрачной. Мы просто описываем связи в коде: builder.RegisterEntryPoint<GameLoop>(), и VContainer сам «склеивает» логику, визуал и данные. Это позволяет менять системы (например, подменить реальную сеть на моки для тестов) одной строчкой в одном файле, не бегая по префабам.

Нужно ли в следующий раз разобрать больше подробностей с конкретными примерами кода?

ЭКЗИСТЕНЦИАЛЬНЫЙ КРИЗИС ОТМЕНЯЕТСЯ: ПАЗЛ MVP СЛОЖИЛСЯ 🧩

🕺 Превосходное утро! Сегодня я официально заявляю: MVP быть меньше чем через месяц. Я наконец-то победил самую сложную архитектурную задачу в проекте, над которой мы ломали голову последние несколько дней.

❌ Проблема: У нас есть командиры. Они должны влиять на игру при любых событиях, при любых условиях, да еще и сами прокачиваться от этих же условий. Когда сущностей становится много, начинается хаос: как гарантировать, что баф сработает раньше дебафа? А что, если игрок сам должен выбрать очередность срабатывания способностей из своей «руки»?

⚙️ Решение: Сначала мы думали, что каждый командир будет сам слушать «свои» события. Но это путь в ад зависимостей и непредсказуемых багов. И тут осенило.

⚙️ Commander Sequencer: Мы выделили вышестоящего управляющего. Вместо того чтобы сотня командиров «орала» одновременно, на шину событий подписан один Секвенсор. Он перехватывает сигнал, смотрит на текущую руку игрока и выстраивает очередь исполнения.

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

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

А у вас бывали моменты в разработке, когда одна удачная идея спасала недели работы? 👇

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

🎸 Вспомните Prince of Persia: Warrior Within. Уверен, у многих, кто её проходил, музыка вызывает трепет до сих пор. Тот дерзкий переход от восточных мотивов первой части к агрессивному хеви-металу в погонях от Дахаки это был риск, который окупился на 200%. Звук превратил сказку в мрачный триллер, добавив игре той самой «мясной» тяжести.

⚙️ Хороший саунд-дизайн в геймдеве строится на трех столпах, которые работают в связке с кодом:

🔹 Аудио-фидбек (Juiciness). Игрок должен «чувствовать» действие ушами. Если меч ударяет по щиту, звук должен содержать «тело» (низкие частоты) и «клик» (высокие частоты в момент соприкосновения). Если звук опаздывает хотя бы на 50мс или не соответствует материалу то мозг считывает это как фальшь, и магия рушится.

🔹 Динамическое микширование. В хорошей игре звук это живая система. Например, использование Low Pass Filter, когда у персонажа мало здоровья, или изменение реверберации в зависимости от размера помещения. Это чистая техничка: код должен постоянно отдавать параметры окружения в аудио-движок.

🔹 Звуковой приоритет: В пылу битвы одновременно могут звучать 50 клипов. Если воспроизвести всё получится каша. Требуется система приоритетов, которая приглушает фоновые звуки (эмбиент), чтобы выделить критически важный сигнал (например, звук готовности ульты или замах врага из-за спины).

🎨 Эстетика и контекст: Важно не просто найти «красивый» звук, а найти звук, соответствующий эпохе и настроению. Синтетические звуки в средневековом сеттинге будут резать слух, если это не осознанный стилистический выбор (как в Hades). Звук это клей, который соединяет абстрактную математику симуляции с эмоциями игрока.

📈 Без внятной аудио-стратегии даже самая топовая графика будет ощущаться «пластиковой». Звук дает объектам вес, миру объем, а игроку понимание того, что его действия имеют значение.

👇 А какая игра для вас является эталоном саунд-дизайна?

Не поздно ли вкатываться в моделинг?

Решил понемногу пробовать моделить. В инди-разработке всё просто либо есть бюджет на аутсорс, либо делаешь сам. Чтобы не сливать лишние деньги на простые задачи, выбрал второй вариант. Жаль что уже не помню как делал комнаты в детстве через 3dMax или лепил лица в ZBrush.

Понимаю, что на старте в качестве точно потеряю и буду выдавать кривые меши. Но план такой, открываю Blender на 30 минут в день. Без фанатизма, просто чтобы набить руку. Как раз к моменту, когда для проекта понадобится массовый моделинг, я уже буду понимать базу и смогу сам собрать простые пропы или поправить чужую топологию.

👇 Как считаете, нормальная стратегия так добирать скилл по чуть-чуть или лучше не тратить время и копить на профессионалов?

Неделя выдалась насыщенная, да и пятница 13 принесла свои новости 🗓️

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

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

🎥 Про девлог
Завтра в планах записать девлог. Хочу наконец довести это дело до конца, а не просто забросить из-за того что стесняюсь или лень монтировать. Если справлюсь, то видео выйдет в воскресенье вечером. Хочу вести такие отчеты и для памяти в виде дневника, и чтобы показывать текущий прогресс.

🚀 Про расширение
Пора потихоньку выходить в соцсети и набирать более широкую аудиторию. Скоро наступит время демок, так что будем искать вектор развития игры вместе.

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

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

В геймдеве есть такой забавный показатель StFB или Seconds to First Box. Это буквально количество секунд которое проходит с момента запуска игры до того как игрок встретит первую коробку.

Почему именно коробка? Потому что это самый ленивый и универсальный способ геймдизайнера заполнить пустоту в кадре. Коробки это идеальные укрытия, отличные объекты для разрушения и просто удобный способ закрыть дырку в углу уровня.

О чем говорит эта метрика 🤨

Считается что чем меньше секунд до первой коробки, тем меньше у разработчиков было времени (или желания) придумывать что-то оригинальное для окружения. Если ты идешь по космическому кораблю будущего и через 5 секунд видишь обычный деревянный ящик кажется у нас проблемы с креативом.

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

Присмотритесь сегодня в какой-нибудь игре сколько времени вам понадобится чтобы найти первую коробку.