Unity *

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

Дисклеймер по традиции: я не профильный разработчик, пишу свой симулятор школы по вечерам, и вполне допускаю, что местами мои решения покажутся вам наивными или кривыми (или вообще НЕВЕРНЫМИ). Я просто рассказываю про проблему, в которую упёрся сам, и про то, как из неё выбирался. Если знаете, как лучше --- буду рад в комментариях.

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

Это еще одна статья из цикла про разработку игр без прикладного опыта. Если вам интересна эта и подобные темы - подписывайтесь на мой ТГ-канал Homemade Gamedev, где посты выходят чаще, и я пишу про текущие задачи в проекте.

Каждый игровой инженер сталкивался с этим. У вас есть 16.67 мс на кадр (60 FPS). В сцене 10 000+ объектов: враги, частицы, тени, декали, постыффекты. Нужно решить: на что потратить бюджет, чтобы игрок видел самое важное в максимальном качестве, а FPS не проседал?

Типичные подходы и их недостатки

1. Дистанционный LOD (расстояние до камеры)

или “Страшная сказка: продолжение-3”

В предыдущих разборах серии («О бедном луддите замолвите слово…», «Об Open-source — спасителе человечества…», и в исходной «Страшной сказке») я разбирал, кого, что и почему мы теряем в ходе AI-кризиса: воронку джуниоров, цикл воспроизводства экспертизы, frontier-фронт, наработанные в OSS анклавы. Каждый раз картина была про минусы и проблемы.

В этой статье — про другую сторону медали. Потому что у того же самого процесса, помимо потерь, есть некоторое количество “трофеев”. И стоит их упомянуть, чтобы картина была полной и честной.

Для этого я расскажу “байку”…

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

Вы когда-нибудь заполняли json-конфигов на 20 000 - 25 0000 строк вручную перед выпуском релиза? А боль в глазах геймдизайнеров от этого процесса видели?

Вы TechLead/Менеджер и к вам часто подходят дизайнеры с просьбой написать парсер данных, а свободных рук нет? А после изменений в фиче приходится выделять человека для правок схемы парсинга под новую разметку?

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

Привет! Меня зовут Игорь, я занимаюсь разработкой на Unity c 2018 года. В статье рассказываю о тулзе, с помощью которой можно выгружать данные из Google Sheets и Excel в json без привлечения программистов.

P.S. в конце статьи есть видосик с процессом настройки и экспорта одной фичи.

Жил-был разработчик. Работал на 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
• как из простых правил собрать более сложную модель поведения агента
• как этот подход был применен в моей игре