Игровые движки и библиотеки для ИИ-агента: физика, навигация, анимация

Игровые движки давно не главная проблема: Godot, Three.js или Pygame агент берёт без вопросов. Проблема в том, что внутри игры. Физику, поиск пути и анимацию персонажа ИИ-агенту лучше не писать с нуля, а подключить готовые open-source библиотеки: Jolt или Box2D для физики, Recast & Detour для навигации, ozz-animation для скелетной анимации. Агент хорошо их подключает, если версия зафиксирована. Путается он там, где у библиотеки был крупный слом API.

Сразу оговорюсь, откуда я на это смотрю. Я пилю ДнД-бота с ИИ-мастером, почти весь код там пишут агенты, и физики в нём нет: это текстовая игра. Зато есть свои кубики, свой бой и свой рандом, то есть ровно та часть "движка", которую я написал сам и на которой агенты регулярно спотыкались. Поэтому ниже две части: чужие библиотеки по источникам (каждая цифра со ссылкой) и мой вывод, где проходит граница "своё или готовое".

Поводом стала подборка канала vibecoding_tg от 30 октября 2026: десять open-source репозиториев, "чтобы собрать игру уровня больших проектов". Список хороший, но он не отвечает на вопрос, который меня волнует: с чем из этого агент справится, а с чем начнёт фантазировать.

Какие open-source библиотеки взять для физики, навигации и анимации

Для физики берут Jolt Physics (3D) или Box2D v3 (2D), в браузере - Rapier. Для навигации и поиска пути - Recast & Detour. Для скелетной анимации - ozz-animation. Для оптимизации моделей - meshoptimizer, для процедурного шума - FastNoise2. Все они под пермиссивными лицензиями (MIT, Zlib, Apache-2.0), так что их можно тащить в коммерческую инди-игру.

Свёл в таблицу всё, что стоит рассматривать. Звёзды и версии проверены 03.11.2026 на GitHub.

Из подборки я не взял в таблицу Effekseer, Material Maker и The Forge. Первые два - это скорее инструменты для художника с визуальным редактором, агенту там почти нечего делать. The Forge - фундамент для своего движка, это история не про соло-разработчика с ИИ.

Зачем ИИ-агенту готовая физика, а не своя

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

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

С библиотекой расклад другой. Jolt работает в Horizon Forbidden West и Death Stranding 2 (так указано в репозитории), а Recast стоит под навигацией Unity, Unreal, Godot и O3DE (README Recast). Такие вещи прожили годы в продакшене. Если что-то не так, почти наверняка ошибка в клее, который написал агент, а не в самом солвере. Искать проще.

И второй плюс, менее очевидный: на популярные библиотеки у модели полно примеров в обучающих данных. Чем чаще код встречался в интернете, тем увереннее агент его пишет. Отсюда и обратная сторона, о ней ниже.

Физический движок для игры: Jolt, Box2D или Rapier?

Физический движок выбирается по стеку, а не по рейтингу. Игра на Godot 4.6 в 3D - уже Jolt, ничего подключать не надо. 2D-игра на C или C++ - Box2D v3. Браузерная игра на Three.js или любом JS-движке - Rapier через WASM. Свой C++ движок в 3D - Jolt напрямую.

Детали по каждому варианту:

• Jolt Physics. В Godot его добавили экспериментально в 4.4, а в Godot 4.6 (январь 2026) он стал физикой по умолчанию для новых 3D-проектов (Digital Production, 28.01.2026). Старые проекты остаются на GodotPhysics, пока не переключишь настройку руками. Нюанс для агента: отдельное расширение Godot Jolt ушло в режим поддержки, так что если агент тащит его в проект на 4.6 - это лишнее.
• Box2D v3. Переписан с C++ на C, вместо указателей теперь идентификаторы, добавлена многопоточность. Автор пишет, что в однопоточных тестах v3 "больше чем вдвое быстрее v2.4" (блог Box2D, 9.08.2024). Это оценка автора, а не независимый замер.
• Rapier. Физика на Rust, в браузер приезжает через WebAssembly (rapier.rs). Одна грабля для агента: перед первым вызовом API нужно дождаться асинхронной инициализации модуля, а в коротких примерах про это легко забыть.

Если у тебя 2D-платформер в Godot, не надо ничего из этого. Встроенной 2D-физики хватает с запасом.

Навигация и поиск пути в игре: что такое Recast & Detour

Recast & Detour - это библиотека навигации для игр: Recast строит навигационную сетку (навмеш) из геометрии уровня, Detour на ней ищет путь и ведёт толпу агентов с обходом друг друга. Именно её используют Unity, Unreal, Godot и O3DE, так что в этих движках ты пользуешься ей через встроенные ноды.

Отдельно подключать Recast стоит, только если пишешь свой движок или игру на голом C++. Тогда схема из документации простая: Recast живёт в инструменте сборки уровня, а в рантайм игры уходит один Detour (README). Ставится через vcpkg install recast.

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

С какими библиотеками ИИ-агент путается

ИИ-агент путается в библиотеках, которые пережили крупный слом API: в обучающих данных лежат обе версии, и модель смешивает их в одном файле. Самые частые случаи - Box2D v2.4 против v3.0 и Godot 3 против Godot 4. Новые и редкие библиотеки агент тоже знает хуже: примеров мало, и он додумывает сигнатуры.

Box2D - образцовый пример. В v2.4 тело создавалось методом мира, в v3.0 методов нет вовсе, только функции с идентификатором мира (гайд миграции Box2D):

// Box2D 2.4 (C++)
b2Body* body = world->CreateBody(&bodyDef);
 
// Box2D 3.x (C)
b2BodyDef bodyDef = b2DefaultBodyDef();
b2BodyId bodyId = b2CreateBody(worldId, &bodyDef);

Агент без подсказки легко пишет половину файла в стиле 2.4, а половину в стиле 3.x. Код не собирается, агент чинит ошибку, плодит обёртки. Вечер ушёл.

С Godot та же история, только тоньше. В интернете годы туториалов по Godot 3, поэтому модели пишут KinematicBody2D вместо CharacterBody2D, yield вместо await, передают аргументы в move_and_slide(), хотя в Godot 4 он берёт скорость из свойства velocity (DEV, 7 вызовов Godot 4, которые ИИ путает). yield хотя бы ломает парсинг, его видно сразу. А вот тихие ошибки, которые синтаксически корректны, агент пропустит.

И третий тип путаницы - статус интеграции. Про Voxel Tools в README одновременно написано "модуль/расширение", а в роадмапе висит "Make GDExtension work" (godot_voxel). Для человека это повод открыть инструкцию по установке. Агент же может уверенно предложить вариант, который требует собирать Godot из исходников. Это не катастрофа, но такие вещи надо проверять глазами до того, как агент начнёт.

Как у меня: что отдал агенту, а что держу в своём коде

У меня в ДнД-боте нет физики, но есть свой маленький "движок": кубики, проверки, бой, лут. И на нём я хорошо увидел, где ломается самописное ядро. Весь рандом я в сентябре 2026 свёл в один источник: три класса TurnRng, RecordingRng и ReplayRng, файл на 171 строку.

Инъекция этого генератора в бросок кубиков, проверки и бой затронула 6 файлов. Казалось бы, всё. А ревью первого PR нашло ещё три модуля, которые продолжали звать случайность мимо общего генератора. Вот дословно строка коммита, которым это закрывали:

fix(bot): current_rng() в encounter_balance/quest_rewards/basic_loot

Баланс встреч, награды за квесты и базовый лут. Агент писал этот код раньше, и писал его логично. Просто в моём собственном "движке" не было одного правильного способа сделать рандом, и каждый модуль сделал по-своему. У готовой библиотеки такой проблемы нет: у Jolt или Box2D один API, и агенту не из чего выбирать.

Второе, что я сделал, - вынес логику хода в чистые функции. В первом срезе рефакторинга это 113 функций, которые не трогают базу и сеть, и ещё 18 нечистых я сложил в отдельный модуль helpers. После этого реплей сошёлся 72 из 72. Это та же граница, что и в игре с физикой: солвер - чужой и проверенный, а правила игры - свои, чистые и покрытые тестами.

Подробно про сам трос из слепков я писал в разборе 66 слепков перед распилом pipeline.py. Если коротко, именно он ловил ошибки агентов раньше, чем я.

Отсюда моё правило, которого нет в подборке: библиотеке - всё, что считается одинаково в любой игре (коллизии, путь, сэмплинг анимации), своему коду - только то, что делает игру твоей (правила, баланс, экономика). Если агент пишет у тебя солвер столкновений, что-то пошло не так.

Как подключить библиотеку, чтобы агент не путался

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

1. Выбери библиотеку по стеку (таблица выше) и закрепи версию: тег в git-сабмодуле, версия в vcpkg, точная версия пакета в npm.
2. Запиши версию и запреты в CLAUDE.md или AGENTS.md. Пример блока, который я бы положил для 2D-игры на Box2D:

## Физика
- Box2D 3.2 (C API). Никаких b2World* и world->CreateBody - это 2.4.
- Тела создаём через b2DefaultBodyDef() + b2CreateBody(worldId, &def).
- Шаг: b2World_Step(worldId, dt, subSteps), subSteps = 4.
- Перед правкой физики открой docs/migration.md из сабмодуля.

3. Положи в репозиторий пример из документации нужной версии и попроси агента сначала собрать его без изменений. Если пример не собрался, дальше идти нет смысла.
4. Попроси отладочную отрисовку: коллайдеры, навмеш, путь NPC. Агенту это даёт глаза, тебе - быстрый способ понять, кто виноват.
5. Логику игры держи отдельно от библиотеки и покрывай тестами. Один сид на весь рандом, как в статье про сид и команды, иначе баг физики и баг логики сольются в один.
6. Только теперь проси фичу. И после каждой правки - запуск, а не "выглядит правильно".

Для Godot пункт 2 сводится к одной строке: "Godot 4.6, GDScript 2.0, не использовать API Godot 3". Это дешёвая страховка от KinematicBody2D.

Когда готовая библиотека не нужна

Готовая библиотека не нужна, если движок уже включает её или если механика проще самой библиотеки. 2D-платформер в Godot, головоломка на сетке, пошаговая игра, текстовая RPG - тут встроенного хватает, а лишняя зависимость только добавит агенту путаницы и сборки.

Граница у меня такая: если физику игры можно описать одной формулой (прыжок по параболе, движение по клеткам), пиши сам, это несколько десятков строк, и агент их не испортит. Если в игре больше пары десятков тел, которые сталкиваются друг с другом, или враги ищут путь по уровню со стенами, - бери библиотеку и не изобретай. Мой бот, кстати, по этой границе живёт без физики совсем, и это правильно.

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

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