RTS Game AI Thread

У меня есть проект, чтобы сделать стратегию в реальном времени с нуля. Я все еще на ранней стадии планирования, но я немного программировал, чтобы увидеть механику.

Я знаю, как программировать. У меня также есть хорошая идея о том, как я буду структурировать игровые классы и AI на основе правил (конечного автомата) для компьютерного игрока.

Я хочу разработать Доктрины, которые дадут определенное поведение определенному отряду (но могут быть использованы на многих отрядах одновременно), такие как Разведчик, Маршрут миссии, удержание позиции (атака на любого приближающегося врага или отступление, если разбито) , и т.д...

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

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

Я делаю это в C # с OpenGL.

Пока у меня не так много, только несколько вещей в тестах, прежде чем я начну свою основную концепцию. У меня есть игровой цикл, где происходит вся обработка игры (где я буду называть движение обновлений, бой, рендеринг и т. Д. Один за другим), он вызывается очень часто, если происходит событие Application.Idle.

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

Если я хочу, чтобы все было одновременно, Должен ли я создать отдельную тему для компьютерного ИИ? Или даже отдельный поток для каждого блока?

У меня нет большого опыта с многопоточностью. Что будет лучшим подходом для этого?

Что значит "с нуля"? Можете ли вы использовать что-то вроде XNA вместо DirectX?

Вы должны рендерить что-то между 30 и 60 кадрами в секунду, чтобы иметь плавное движение. Там действительно нет необходимости иметь больше кадров в секунду.

Если рендеринг + логика занимает меньше, чем 16 мс, которые дает вам 60fps, тогда не должно быть необходимости в потоке ИИ.

Если у вас не будет достаточно времени между рендерингом фреймов, вам придется очень тщательно подумать, что нужно обновлять каждый фрейм, а что нет.

Я предполагаю, что часть «доктрины» должна быть настолько простой и эффективной, насколько это возможно, чтобы ее можно было обновлять каждый кадр, по крайней мере, для видимых юнитов и других юнитов поблизости. Единицы, которые непосредственно не влияют на видимые единицы, могут обновляться реже (и, соответственно, с большей дельтой T).

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

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

Особенно, если у вас нет большого опыта, не делайте потоки, если вам это не нужно. Это будет сложно, поскольку это без дополнительной нагрузки. Вы можете научиться многопоточности как отдельному проекту или как его расширению, когда он будет в рабочем состоянии. Удачи!

Есть отдельная тема для AI. Но не для каждого устройства, поскольку оно потребляло бы слишком много ресурсов ОС, а синхронизация была бы кошмаром.

Убедитесь, что поток AI найдет возможность выполнить. Не принимайте это всерьез, если основной поток делает слишком много вещей, он может никогда не найти такую ​​возможность! Если вы просто отдадите более высокий приоритет потоку ИИ, то игра перестает отвечать на запросы, что недопустимо.

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

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

Остальные единицы проверяются в отдельном потоке, и у меня есть два приоритета: 1. Единицы, которые находятся в местах, которые видны пользователю, если он перемещает экран туда. 2. Юниты, которые находятся в скрытых областях (еще не исследованы и «туман войны»).

Для единиц с приоритетом в секундах, я запускаю цикл реже и компенсирую, перемещая их ретроспективно, когда это необходимо.

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

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

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

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

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