Гра RTS AI Нитка


14

У мене є проект, щоб зробити стратегічну гру в реальному часі з нуля. Я ще на стадії раннього планування, але я трохи програмував, щоб побачити механіку.

Я знаю, як програмувати. Я також добре уявляю, як буду структурувати ігрові класи та AI на основі правил для комп'ютерного гравця.

Я хочу розробити доктрини, які даватимуть конкретній поведінці певному підрозділу (але можуть використовуватися в багатьох підрозділах одночасно), таких як «Розвідник», «Дотримуйтесь маршруту місії», «Утримуйте позицію» (атакуйте будь-якого наближеного противника або відступайте, якщо переможете) тощо.

Доктрини застосовуватимуться лише до одиниць, тож вони матимуть одиничну перспективу та не будуть усвідомлюватись у цілому на карті.

Комп'ютерний ШІ проаналізує всю видиму карту і вирішить, яку доктрину призначити кожному блоку залежно від іншого набору правил.

Я роблю це в C # з OpenGL.

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

Тепер мені було цікаво. Оскільки в ігровому циклі буде багато що обробити, чи повинен AI Computer і Units вибрати свої дії в цьому циклі чи це буде занадто повільно?

Якщо я хочу, щоб усі речі були одночасними, чи слід створити окрему нитку для комп'ютерного інтелекту? Або навіть окрема нитка для кожної одиниці?

Я не маю великого досвіду роботи з багатопотоковою нарізкою. Який був би найкращий підхід для цього?


Непов'язане - вважається Ogre3D замість OpenGL?

Власне, ні, я ніколи про це не чув. Я використовую OpenGL, тому що саме цього мене навчали на своїх заняттях. Чи може Ogre3D зробити також 2D? Я думаю, це може, але ми ніколи не знаємо ...

Так, це можливо, у нього навіть є власний інструментарій GUI (cegui). Наприклад, TorchLight побудований з ним. Це може заощадити ваш час, тому що воно прекрасно обгортає ВСЕ OpenGL. ogre3d.org/tikiwiki/MOGRE

"Або навіть окрема нитка для кожної одиниці" Пекло ні. Накладні нитки набагато завеликі. Для одного є зарезервована пам'ять для стека потоку (1 МБ за замовчуванням). І різьбові вимикачі теж дорогі.

Відповіді:


3

Що означає "з нуля"? Чи можете ви використовувати щось на зразок XNA замість DirectX?

Вам слід робити щось від 30 до 60 кадрів в секунду, щоб мати рух рідини. Дійсно не потрібно мати більше кадрів в секунду.

Якщо візуалізація + логіка займає менше, ніж 16 мс, яку дає 60 кадрів в секунду, то в потоці AI не повинно бути необхідності.

Якщо у вас не буде достатньо часу між візуалізацією кадрів, тоді вам доведеться подумати дуже ретельно над тим, що потрібно оновлювати кожен кадр, а що ні.

Я б здогадався, що частина "доктрин" повинна бути максимально простою та ефективною, щоб її можна було оновлювати кожен кадр, принаймні для видимих ​​одиниць та інших одиниць, що знаходяться поруч. Одиниці, які не впливають безпосередньо на видимі одиниці, можуть оновлюватися рідше (і, відповідно, з більшою дельтою T).

Основний AI повинен виконати більше роботи, оскільки він повинен обробити всі одиниці на карті та розробити стратегію, тому це потребує більшої частини часу на обчислення. Це перший кандидат на окрему тему.

Зауважте, що ви можете додати ще один шар між цими двома, чимось на зразок AI рівня загону. В основному, AI кожного підрозділу повинен переконатися, що підрозділ "розумно" реагує на негайну ситуацію, тому він повинен бути швидким та чуйним. Загін AI відповідає за "розумні" дії декількох підрозділів, поширювані на кілька секунд, як пошук мосту, якщо загін повинен перетнути річку. І головний ШІ повинен керувати діями багатьох загонів протягом тривалого періоду часу.

Особливо, якщо ви не маєте багато досвіду, не займайтеся ниткою, якщо не потрібно. Це буде складним, оскільки без зайвого навантаження. Ви можете вивчити багатопотоковість як окремий проект, або як розширення цього, як тільки він перебуває у робочому стані. Удачі!


0

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

Переконайтесь, що нитка AI знайде можливість виконати. Не сприймайте це легко, якщо головна нитка робить занадто багато речей, вона ніколи не знайде такої можливості! Якщо ви просто надаєте більш високий пріоритет AI-потоку, то гра стає невідповідною, що неприпустимо.

Отже, обережно виберіть точки синхронізації та / або події в головному циклі і дозвольте потоку AI завершити свої обчислення, поки основний потік зупиняється. Наприклад, якщо користувацький блок бачить інший AI-блок, синхронізуйте його, тож ваш пристрій бачить оновлений блок навпаки.


0

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

Інші блоки перевіряються окремим потоком, і я маю два пріоритети: 1. Одиниці, які знаходяться у місцях, які видно користувачеві, якщо він переміщує екран там. 2. Підрозділи, які знаходяться у прихованих районах (ще не досліджені та "туман війни").

Для одиниць у пріоритеті секунд я запускаю цикл рідше і компенсую, переміщуючи їх заднім числом, коли потрібно.


1
Звучить дуже складно.

Ваша ідея звучить чудово, за винятком першої частини про переміщення одиниць в основний цикл гри. Усі AI повинні бути виконані у власному циклі, де ви можете пропустити цикл усіх xітерацій на одиницях з низьким пріоритетом.
Ольховський

0

Незалежно від того, чи потрібно багатопотокове чи ні, може бути хорошою ідеєю підготувати AI до багатопотокового.

Ваш головний потік оновив би світ, поставив галочку фізики тощо, а потім заповнив структуру даних, що представляє погляд АІ на світ: положення одиниць, стан ресурсів тощо. Ця структура даних кешуватиме основні системи, а не ніж просто тримати покажчики на них. Іноді це називається точкою синхронізації.

Передайте цю структуру даних AI і дозволяйте лише міркувати про вміст цієї структури. Якщо ви виявите, що AI потребує додаткової інформації, додайте його до структури. Шляхом мови AI це часто називають дошкою, але його також можна називати кешем. Ніколи не дозволяйте AI записувати в кеш, вихід повинен надходити через окрему структуру даних.

Ця настройка дозволить вам паралелізувати гру, оскільки AI більше не має прямої залежності від інших ігрових систем. Ці системи не повинні бути безпечними для потоків, і ви ніколи не повинні мати замки. Ви можете сміливо запускати візуалізатора чи щось таке, поки AI кружляє.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.