ИИ врагов в Unity: почему if/else быстро превращается в болото

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

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

Если ваш enemy AI уже трещит от новых фич, стоит разобрать подход. В деталях хорошо видно, где FSM ещё помогает, а где дерево поведения становится честнее к задаче.

@make_game (теперь в VK и Max)

Ничего необычного, просто эксперименты с анимацией бега, пробегаем проходим мимо

Как Michael Abrash удвоил FPS в Quake вручную

В 1999 году id Software выложила исходники Quake, и John Carmack предупредил в readme.txt: если собрать движок только на C, софтверный рендер потеряет почти половину скорости. Автор материала проверил это на Pentium MMX 233 МГц.

Стоковый WinQuake выдал 42,2 fps. После отключения ASM-оптимизаций и сборки чистого C-кода результат упал до 22,7 fps. Разница — ровно в два раза, как и говорил Carmack.

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

@make_game (теперь в VK и Max)

Нашёл тут ещё один тред с нашим любимым форматом, где разработчик с 10+ годами опыта рассказывает что-то полезное. Автор делает игры в Roblox, зарабатывает этим на жизнь и управляет небольшой командой. Самое полезное там не про Roblox, а про реальность современного инди-геймдева.

Главный вывод: игру мало просто сделать. Её нужно довести до релиза, измерять поведение игроков и адаптировать под интернет 2026 года.

Кратко:

1. Смотрите на метрики. Где игроки выходят? Где застревают? После какого экрана падает retention? Это реально помогает находить проблемы в дизайне, если не относиться к задаче как к скучной и мешающей писать код.

2. Контент-криэйторы уже не работают как в 2015. Раньше случайный летсплей мог вытащить игру. Сейчас чаще наоборот: сначала нужна живая комьюнити и понятный крючок, потом к вам приходят ролики.

3. Движок не спасает проект. Unity, Unreal, Godot, Roblox — всё может сработать. Важнее scope, цикл обновлений, понимание аудитории и умение доводить игру до состояния, где в неё реально играют.

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

5. Игроки не читают. Если механика держится на том, что игрок внимательно прочитает текст, дизайн уже в зоне риска. Лучше учить через интерфейс, уровень, визуальные подсказки и первые действия.

Отдельно понравился совет про баги: делите их на три уровня. Ломает игру, мешает играть, косметика. Третий список всегда будет непустым, и он не должен останавливать релиз.

@make_game (теперь в VK и Max)

Попался отличный майский дев-дневник Prehistoric Kingdom — это зоопарк-симулятор с динозаврами, команда из 7 фултайм и 5 парттайм разработчиков. В Update 17 они делают боевую систему и расписали, как устроено поведение животных. Тот самый формат, который я люблю: без маркетинга, просто как оно работает внутри.

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

Драка не всегда до смерти. Хищник может сдаться или убежать, если получил слишком много урона. Травоядные по-разному: территориальные преследуют обидчика, другие сами разбегаются, как только агрессор отстал.

Отдельно пишут про раны. Чем больше урона получил зверь, тем больше ран на теле, а если выжил, они со временем зарастают в шрамы. У каждой особи свой процедурный offset, поэтому одинаковых шрамов не будет ни у кого. А после смерти хищники могут есть труп, получается какая-никакая поддержка экосистемы, хотя специально под самоподдерживающийся баланс игру не точат.

По мелочи подтянули и движение: животные резче разворачиваются, когда убегают, повороты стали плавнее, добавили banking, наклон в сторону движения. Для зоосима выглядит непривычно свежо.

Кайф, когда команда так открыто показывает кухню. Трейлер U17 обещают в июне, ждём :)

@make_game

Нашёл прекласное, называется SAM3DBody-cpp. Берёшь обычное видео с одной камеры, на выходе получаешь готовый BVH-мокап, который без танцев перетаскивается в Blender или Unity. Никакого костюма, никаких маркеров, никакого Python в рантайме, только чистый C++ поверх ONNX Runtime и ggml.

Мне нравится, что видно, как оно работает внутри. Пайплайн прямо в README расписан по слоям: yolo.onnx находит людей и боксы, backbone (DINOv3-ViT-H, около 630 миллионов параметров) гонит фичемапу, decoder выдаёт pose-токен, а две маленькие головы на ggml-матмулах раскладывают его в 519 параметров позы и сдвиг камеры. На выходе скелет на 70 суставов вместе с кистями рук.

Про железо: backbone на 630 миллионов параметров для риалтайма хочет CUDA-видеокарту, на ней оно идёт почти в реальном времени. Для CPU автор выложил отдельный float32-бэкбон, но один прогон на ноутбучном процессоре будет ощутимо медленнее — это для оффлайн-обработки клипа, а не для вебки.

Лицензия MIT, репо живое: только вчера, 4 июня, завезли нативные Windows-сборки и поправили синхронизацию по кадрам для live-режима.

https://github.com/AmmarkoV/SAM3DBody-cpp

@make_game

Всех с началом выходных! Что успели сделать за прошедшие две недели? Скрины и демки из ваших игр в студию!

Можно со ссылками на ваши каналы.

@make_game

Наткнулся на демку, которая бьёт прямо по ностальгии — Defrag Incremental. Помните ту самую полоску дефрагментации в старых Windows, за которой можно было залипать часами? Кто-то взял ровно это чувство и собрал из него incremental-игру.

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

Дальше классическая петля жанра. За успешные джобы капают внутренние очки, на них качаешь апгрейды текущего билда, а когда упираешься в потолок — делаешь reboot в перманентные BIOS-улучшения, которые перекраивают все будущие забеги. Поверх этого тонкий слой выживания: работаешь за деньги и балансируешь риск против выплаты, чтобы просто остаться на плаву.

Выглядит всё в чистой DOS-эстетике, пиксельный UI, который приятно читать. Мне нравится, как взяли скучную системную рутину из детства и превратили её в напряжённый луп с принятием решений на каждом заказе.

Демо уже доступно в Steam, полный релиз обещают в Q3 2026.

https://store.steampowered.com/app/4286660/Defrag_Incremental/

Залип бы в такое на вечер, чисто чтобы снова посмотреть, как ползут эти квадратики :)

@make_game

Короткий полезный разбор от Рубена с TheGameDev.Guru про те самые фризы на секунду в современном Unity, когда игрок заходит в новую зону, меняет графику или надевает косметику, и игра замирает ровно настолько, чтобы он пошёл за рефандом.

Старый рецепт «соберём шейдеры и прогреем заранее» на Vulkan, DX12 и Metal не работает. Теперь прогреваешь не шейдер, а PSO т.е. шейдер плюс весь стейт рендера вокруг: MSAA, формат таргета, blend, depth, вариант материала, уровень качества. Поменял одну настройку, и нужен новый PSO, которого в твоём трейсе не было. Отсюда и фриз.

Unity 6.5 добавил cache miss collection: движок ловит непрогретые стейты и даёт доклеить их в кеш. Удобно, но штука лишь сообщает, что ты пропустил, уже постфактум. Корень всё равно в покрытии — трейсить надо реальные геймплейные маршруты и настройки игроков, а не чистое демо.

Подробнее в самой статье: https://thegamedev.guru/all/your-pso-cache-is-only-as-good-as-your-playthrough/

@make_game

Завтра, 13 июня, стартует GBAJam 2026 — большой джем по созданию игр для Game Boy Advance, приуроченный к 25-летию консоли. На игру дают целых три месяца: дедлайн 13 сентября, потом до 30 сентября голосование.

Формат честный олдскул: сдаёшь .gba-файл, который судьи гоняют на реальном железе через флешкарты и на эмуляторах mGBA и NanoBoyAdvance. Правила в этом году ужесточили: GB Studio запрещён (джем именно про GBA), ромхаки нельзя, ИИ-контент запрещён полностью — ни графики, ни кода, ни музыки. Порты и ремейки с нуля с других платформ можно, доделывать проект, над которым сидел месяцами, нельзя. Допускается заход с почти нулевым заделом вроде тайтлскрина или мокапа.

Призы тоже в духе: денежный пул, который пополняют донатами, плюс железо и картриджи от спонсоров — дамперы GBxCart RW, GB Operator, физические копии Xeno Crisis для GBA. За открытые исходники под OSI-лицензией дают дополнительные призы. Права на игру остаются у вас, после джема можно спокойно коммерциализировать.

Если давно хотелось пощупать программирование под настоящее ретро-железо, где 16 МГц и 384 КБ памяти заставляют думать о каждом спрайте — лучшего повода не придумать. Комьюнити живёт на gbadev.net, там же документация и поиск команды.

Подробнее: https://itch.io/jam/gbajam26

@make_game

Что успели сделать за неделю? Скрины, гифки и демки из ваших игр в студию!

Можно со ссылками на ваши каналы.

@make_game

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

Топовый комментарий (217 апвоутов) формулирует суть точнее самого поста: ИИ отлично пишет гладкий корпоративный текст, но он не умеет определять, что в твоей игре уникального и особенного. Рядом ещё формулировка, которая запомнилась: «Когда ИИ рассказывает мне о твоей игре, я слышу только то, что она средняя и посредственная» — модель по своей природе выдаёт среднее по всем играм сразу. И совсем короткое: «Если тебе было лень это писать, мне лень это читать».

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

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

@make_game

Любопытная визуализация попалась: половина всего онлайна Roblox сидит в сотне игр. При том что игр на платформе 8,5 миллионов. Сотня — это 0,0012% каталога. Если расширить до тысячи игр, наберётся около 79% всех одновременных игроков.

Автор собирает данные сам: берёт живой счётчик одновременных игроков по каждой отслеживаемой игре из публичного API Roblox, ранжирует и складывает доли. Это его собственный подсчёт по отслеживаемым играм, официальной статистики Roblox тут нет, но покрытие почти всей платформы.

В комментариях самое интересное — сравнение с другими магазинами. Знакомое правило Парето 80/20 здесь сломано в хлам: получается 80/0,001. Но Steam, по словам комментаторов, концентрирован ещё сильнее: топ-5 игр держат 40-50% активных игроков. А хвост из миллионов Roblox-игр — это в основном детские поделки, клоны популярного и заглушки для донатов.

Для разработчика вывод двоякий. С одной стороны, пробиться в живую сотню почти нереально. С другой — в треде описывают, как бывшие Flash-разработчики переезжают именно на Roblox: порог входа низкий, игру не нужно покупать и устанавливать, и шанс быть найденным у маленькой студии там выше, чем в перенасыщенном Steam.

@make_game

Godot 4.7 на финишной прямой: команда выкатила третий релиз-кандидат, до стабильной версии остаются считаные недели.

RC3 — это уже не про новые фичи, а про вылавливание регрессий, которые всплыли в бете. В этот раз чинили анимацию и AssetLib, пул рабочих потоков, виджеты с правосторонней раскладкой текста, частицы, физику на Jolt и XR. По такому списку видно, в каких узлах движок штормит перед релизом и что стоит перепроверить в своём проекте, если вы уже сидите на ветке 4.7.

@make_game

Наткнулся на разбор для тех, кто упирался в CPU на толпах людей в разработке игр. Техарт Yeonju Cho собрала стадион на 6072 зрителя, и весь этот муравейник стоит игровому потоку 0,66 миллисекунды. До оптимизации те же агенты ели 34,15 мс — в 50 раз больше.

Рецепт такой: Houdini процедурно расставляет места и запекает анимации в VAT (vertex animation textures), а в Unreal вся толпа рисуется через HISM, и шейдер целиком гоняет анимацию на GPU. Процессор больше не трогает скелеты вообще: ни скиннинга, ни тиков анимации. Draw calls упали с 21369 до 276, FPS вырос вдвое.

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

Подход переносится на любые массовые сцены: стадионы, баталии, городские NPC в опенворлде. Если в вашем проекте толпа пока что десяток скелетал-мешей с LOD'ами — вот направление, куда копать.

Полная статья: https://80.lv/articles/6-000-agents-on-one-game-thread-novel-high-performance-framework-for-gpu-driven-crowd-systems

@make_game

Mirza Beig показал приём с частицами: шейдер, при котором частицы видно только там, где на них падает свет. В темноте облако частиц невидимо, но стоит провести по нему источником света — проявляются клубы дыма, пыль, туман.

Идея простая: яркость освещения в точке частицы переводится в её прозрачность (luminance-to-alpha). Нет света — альфа в ноль, частица не рисуется; есть свет — проявляется тем сильнее, чем ярче её освещают. Стандартный lit-шейдер частиц так не умеет: там частицы просто затеняются, но видны всегда.

Где пригодится: волюметрик-туман и пыль, реагирующие на фонарик или вспышку, лучи света с пылинками, дым, подсвеченный взрывом. На видео в посте видно, как луч вылепляет дым из темноты.

@make_game

Двое разработчиков выложили годовой постмортем: их игра Bathhouse Creatures выросла из десятидневного геймджема в коммерческий релиз на Godot, и они приложили цифры.

Итог за год: продано 2017 копий, выручка 8983 доллара до вычетов, 8241 вишлист и 98% положительных отзывов (58 штук) при цене 4,99 доллара. Делали вдвоём около десяти месяцев в свободное время: один на коде и аналитике, второй впервые рисовал арт в Aseprite.

Что, по словам авторов, двигало игру: больше всего игроков дали фестивали, стримеры и пресса. Steam Next Fest поднял вишлисты примерно с 350 до тысячи с лишним за неделю. Отдельно сработала стримерша из cozy-ниши: взяла демо и продолжила играть после релиза.

Их выводы: похвала на геймджеме не равна спросу на Steam, аудиторию и жанр стоит понимать заранее, а первое впечатление делает визуал. Маркетинг за год стало делать тяжелее: для следующей игры авторы сместили баланс с 90% разработки на 50 на 50 с маркетингом и получили меньше отдачи.

@make_game

Хочу напомнить про книгу, которая лечит типичную болезнь растущего проекта: игра работает, но код уже страшно открывать. Game Programming Patterns Роберта Нистрома — полная веб-версия лежит бесплатно, и это до сих пор лучший мост между «как-то слепил» и «могу спокойно расширять».

Нистром писал её после восьми лет в Electronic Arts. Каждая из 20 глав начинается с реальной игровой проблемы: как сделать отмену хода (Command), как не дать тысяче частиц убить производительность (Object Pool и Data Locality), почему герой из связки наследований превращается в кошмар и как его пересобрать из компонентов (Component), как развязать достижения и игровую логику (Event Queue).

Примеры на простом C++, который без боли переносится на C#, GDScript или что угодно. Глава про игровой цикл вообще обязательна к прочтению каждому, кто хоть раз спорил про deltaTime.

Читается легко, иллюстрации автор рисовал от руки. Если в вашем проекте Update-метод главного персонажа перевалил за пятьсот строк — вы знаете, что делать на выходных.

https://gameprogrammingpatterns.com/

@make_game