Unity *

Жил-был разработчик. Работал на Unity. Любил свою работу.

Разработчик любил архитектуру. Поэтому подключил DI-контейнер. Потом второй, потому что в первом не было ScriptableObject-биндингов. Потом третий, потому что во втором не работали async scope. Везде была фабрика фабрик, IServiceProvider, который под капотом резолвил IServiceProviderFactory, и пять способов сконфигурировать один и тот же InventoryService.

Разработчик любил чистый код. Поэтому развёл IInventoryService, IInventoryRepository, IInventoryFacade, InventoryDTO, InventoryMapper, InventoryValidator и InventoryQueryHandler. Семь классов, чтобы положить в инвентарь меч. Меч был один.

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

Разработчик устал.

И написал свой фреймворк.

Это не статья про конкретные техники — они описаны в документации, ссылки в конце. Это статья про принципы, из которых эти техники следуют. И про то, почему именно такие принципы. Их пять.

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

Хороший заголовок, да? Ведь так? Тем более в нём нет ни слова неправды. И очень оптимистичный. Правда, это всего-навсего чистейший кликбейт (правдивый, но искажающий суть заголовок), и на самом деле статья будет посвящена рассказу о том, как я всё про… фукал (другое слово точнее передавало бы суть) за время фестиваля в Steam. Но обо всём по порядку.

ИИ врагов в Unity часто начинается с пары аккуратных if/else, а заканчивается кодом, где новое поведение ломает старое, приоритеты конфликтуют, а отладка превращается в раскопки.

В статье разберём, почему такая логика быстро перестаёт масштабироваться, где FSM тоже начинает буксовать, и как Behaviour Tree помогает собрать поведение врага из понятных, переиспользуемых узлов — на C#-примерах с Selector, Sequence, Decorator, Blackboard и типичными ошибками, которые всплывают уже в реальном проекте на Unity.

У архетипов в ECS есть неотъемлимое преимущество перед обычными sparse set'ами - локальность данных. Но есть и существенная проблема - хаотическое копирование данных при миграции из одного архетипа в другой. Что если попробовать избавиться от этого недостатка, оставив локальность данных? Предлагаю рассмотреть статический архетип, который требует явного вызова метода для миграции данных.

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

Как мы автоматизировали сборку Unity-проектов под несколько платформ: прошли через Jenkins, GitHub Actions с game-ci и сорокаминутные билды — и в итоге написали собственный инструмент.

В статье:

Почему Jenkins и GitHub Actions не подошли

Что такое Unity Builder и какую боль закрывает

Визуальный пайплайн, параллельные задачи, FTP-интеграция

За десятилетия существования ECS сложились два фундаментальных способа хранить компоненты: архетипы (Unity DOTS, Flecs, Bevy) и sparse sets (EnTT, LeoECS). Каждый из них несёт структурные ограничения, которые не устраняются оптимизацией реализации — они вытекают из самой модели данных.

StaticEcs — третья модель. Она основана на инвертированном иерархическом битовом индексе: не сущности хранят маски своих компонентов, а компоненты хранят битовые карты сущностей. Фильтрация запроса — это побитовое AND, обрабатывающее 64 сущности за одну инструкцию CPU. Добавление или удаление компонента меняет один бит и не перемещает никаких данных.

В статье разбираю, как устроена эта архитектура, чем она отличается от архетипов и sparse sets, и что даёт на практике.

Как одна модификация формулы превращает генератор карт в дизайнера уровней

Всем привет! Меня зовут Григорий Дядиченко, и я технический продюсер. Играли в Hades? Там дизайнер уровней не бросает кубики. Он точно знает, где игрок поймает дыхание после погони, где встретит соблазн свернуть с пути, где сундук стоит под прицелом элитника, а где — просто в углу за колонной. В простой случайной генерации таких решений нет: карты рождаются «равномерными» и драматургически мёртвыми. Сегодня хочется поговорить о том, как одной модификацией в формуле Wave Function Collapse вернуть в генератор жизнь. Разберём Entropy Bias, Entropy Cascade, Tile Probability Bias и семантические слои. Если вам интересна тема процедурной генерации и немножко математики — добро пожаловать под кат.

В жизни каждого программиста рано или поздно наступает момент, когда хочется вернуть из функции «либо то, либо это». Правильным языком это называется Discriminated Union (далее DU). Его суть проста: тип должен представлять одно значение из нескольких возможных (поэтому реализации называют «OneOf», т.е «один из»).

Казалось бы, что это довольно станадртная ситуация и нечего тут бухтеть, но именно c# кажется особенным в этом плане по сравнению с другими языками. Давайте разберёмся как устроены DU в других языках программирования.

Одним из самых простых примеров без «но» является Си. Действительно, язык просто содержит ключевое слово union, которое позволяет на один участок памяти наложить типы. эта возможность просто комбинируется с enum или int тегом, чтобы различать, что мы записали. Проблема заключается в том, что по большей части никто ничего не гарантирует: программист сам обязан проверять каждый из вариантов и следить, чтобы случайно не создать невалидное состояние.

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

Меня зовут Rok и в настоящее время я занимаюсь разработкой коллекционной карточной игры про танки в сеттинге Второй мировой войны — Tank General.

На данный момент мне 44 года. Я не являюсь профессиональным разработчиком и никогда раньше не имел отношения к геймдеву. По профессии я юрист и всю свою жизнь работал именно юристом. Разработчиком я решил стать полтора года назад.

Разрабатываемая мной игра уже имеет вполне рабочий билд. В нём реализованы около 200 карт техники и приказов, три играбельные нации, около 30 штабов со способностями, несколько PvE-режимов, а также сетевой режим, который является основным в моей игре.

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

Если вы недавно обновились до Unity 6 (или URP 17+) и попытались перенести свои старые пост-эффекты, то наверняка столкнулись с красной консолью и предупреждениями об устаревших методах.

Старые туториалы по созданию эффекта обводки (Outline) через ScriptableRendererFeature больше не работают "из коробки". Unity полностью изменила архитектуру рендера, внедрив Render Graph. Старый добрый метод Execute канул в Лету, а fullscreenMesh заменили на Blitter.

В этой статье мы не просто перепишем классический эффект Outline под новые реалии Unity 6. Мы решим две главные проблемы подобных шейдеров, о которых часто умалчивают в гайдах.

Ritualist — это isometric roguelike в стилистике low poly. В ранний доступ мы вышли 5 марта, а до этого участвовали в Steam Next Fest с демкой (об этом хочется выложить отдельную статью, там отдельный пласт проблем и неоправданных ожиданий). Команда за время разработки сильно менялась: сначала нас было много, потом люди уходили, и сейчас в проекте осталось пять человек. Сама игра была в разработке больше 2 лет, но плотно ей заниматься начали всего полгода назад: как раз когда команда сократилась до этого ядра.Почему так вышло? Потому что до этого мы толком не знали, как управлять продуктом, не умели договариваться и делали ставку не на те вещи. Рассказываем по порядку: что было до раннего доступа, что случилось после и с чем мы боремся сейчас.

Привет, уважаемые пользователи Хабра! Решил поделиться с вами историей своего пути в геймдев. Забегая вперед, скажу, что история еще не окончена и чем окончится никому не известно. Тем не менее, возможно она вдохновит тех, кто хочет изменить свою жизнь, но не решается это сделать, потому что считает, что в «40+ уже поздно» или опасается быть непонятым окружающими.

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

Всем привет! Меня зовут Григорий Дядиченко, и я разрабатываю разные проекты на заказ. Сталкивались ли вы с ситуацией, когда персонаж в вашей игре начинает немного дёргаться, если поиграть достаточно долго? Или пуля иногда пролетает сквозь тонкую стену, хотя коллайдер на месте? Если да — добро пожаловать в мир проблем float precision.

Сегодня хочется поговорить о том, почему тип float — при всей его повсеместности — может создавать тонкие и неочевидные баги в играх. Разберём, как он устроен, где именно он начинает врать, и что с этим делать.

Если вам интересна эта тема — добро пожаловать под кат!

Я разработал свою первую 3D-игру на Unity: подводный лабиринт в духе PacMan, где игрок управляет субмариной и взаимодействует с разными типами рыб. В какой-то момент, я столкнулся с вопросом: как сделать поведение агентов не просто рабочим, а живым и правдоподобным?

В статье разберем:

• что такое Steering Behaviors и в чем суть этого подхода
• основные типы поведения: seek, pursue, evade, wander, avoidance
• как из простых правил собрать более сложную модель поведения агента
• как этот подход был применен в моей игре

С 2022 года отечественная игровая индустрия получила, по разным оценкам, около 7–10 млрд рублей государственной поддержки. Цифры могут показаться огромными, но, сравнив их с мировыми, становится не так страшно. Например, разработка GTA V или Cyberpunk 2077 стоила порядка $300 млн — это около 20–25 млрд рублей. То есть весь объём государственной поддержки за несколько лет — это половина бюджета одной крупной игры.

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

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

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

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

Я всегда хотел играть в игры, где NPC ощущаются по-настоящему живыми — как в исекаях или фэнтези-историях.

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

В этой статье мы шаг за шагом соберём такую систему в Unity: от первого запроса к локальной LLM до персонажа, который слышит голос игрока, знает мир игры, помнит разговоры, делает выводы и отвечает голосом. В основе — архитектура Generative Agents от Stanford.

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

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

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

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