RTS на Rust с ИИ-агентами: архитектура, ошибки и 400+ тестов

Один разработчик создает классическую RTS про Марс, используя Rust, wgpu и ИИ-агентов. К середине проекта уже 400+ тестов, но вскрылись неожиданные проблемы: GPU-ожидания, скрытый сетевой лаг и неработающие красивые решения.

Можно ли одному человеку собрать не демо, а работающую классическую RTS, если почти весь код пишут несколько ИИ-агентов? Автор статьи на Хабре проверяет это на неудобной задаче: Марс 1:1, Rust + wgpu, камера от орбиты до ног робота, отдельная детерминированная симуляция, единая шина команд для человека, сети и ИИ. К середине проекта у него уже 400+ тестов, но вскрылись неожиданные проблемы: GPU-ожидания, скрытый сетевой лаг и неработающие красивые решения.

Архитектура проекта: Марс 1:1, Rust и wgpu

Проект представляет собой классическую стратегию в реальном времени, действие которой разворачивается на Марсе, воссозданном в масштабе 1:1. Технический стек выбран не случайно: Rust обеспечивает производительность и надежность, а wgpu — современный графический API, работающий на Vulkan, Metal и DX12. Камера позволяет приближаться от орбиты планеты до уровня ног робота, что требует гибкой системы уровней детализации и эффективной отрисовки.

Симуляция отделена от рендеринга и является детерминированной — это критично для многопользовательской игры, где все игроки должны видеть одинаковое состояние мира. Для обмена командами между человеком, сетью и ИИ используется единая шина команд (BUS), что упрощает архитектуру и позволяет легко добавлять новых участников.

Проблема с 15 мс в API: ожидание GPU

Одной из первых серьезных проблем стала задержка в 15 мс, которая обнаружилась при замерах. Разработчик предположил, что это связано с сетевыми вызовами или логикой симуляции, но после профилирования выяснилось: 15 мс — это ожидание GPU. Отрисовка кадра занимала больше времени, чем предполагалось, и это создавало узкое место. Пришлось оптимизировать рендеринг, сократить количество draw call'ов и пересмотреть использование ресурсов.

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

Сетевой лаг, скрытый тестами на одном ПК

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

Красивые решения, которые пришлось выбросить

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

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

Научные карты и BUS: как устроена симуляция

Карты в игре строятся на основе реальных данных о Марсе: высоты, температура, наличие полезных ископаемых. Это добавляет глубину геймплею и требует от симуляции учёта множества факторов. Шина команд (BUS) централизует все действия: игрок отдаёт приказ через интерфейс, он попадает в BUS, откуда его забирают симуляция и другие модули. Это позволяет легко реализовать многопользовательский режим и управление через ИИ.

Кого затронет и как

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

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

Что будет дальше

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

Итог

Проект демонстрирует, что один разработчик с помощью ИИ-агентов может создать сложную RTS, но путь к рабочему продукту усеян техническими проблемами, которые требуют глубокого понимания платформы. Главный вывод: не верьте красивым архитектурным решениям, пока не измерите их в реальных условиях. Следите за развитием проекта — он обещает быть интересным.