Елегантний спосіб імітувати велику кількість сутностей у ігровому світі

Припустимо, у вас є гра, в якій є багато (багато багатьох) сутностей, які виконують деякі функції, не всі з яких постійно потрібні або потребують врахування в кожному кадрі. Конкретна проблема, над якою я працюю, в якій існує це питання, - детальне моделювання організму, включаючи його органи.

У грі у кожної істоти є своє тіло, яке розділено на менші частини (тулуб, ноги тощо), а іноді ці частини містять органи, які виконують певну функцію в організмі. Незалежно від того, незалежно від того, чи працює орган в даний час чи ні, він ніколи фактично не з'ясовується. Зрештою, тварина може мати порожній шлунок, тому не потрібно нічого перетравлювати. Було б досить смішно перевіряти або моделювати кожен об'єкт у кожному кадрі, і це дуже дорого, як тільки у вас є багато істот у світі. Тож я думав про спосіб розумно розмежувати об’єкти, які потрібно оновити, і ті, які не мають.

Те, що я придумав, здається принаймні нормальним рішенням. Він створює просту чергу / стек (важливо, щоб кожен елемент видалявся, як тільки його читали; порядок не має значення) називається "стеком уваги", де знаходяться об'єкти, які потрібно імітувати. Об'єкти, які потребують уваги, просто поставлять себе на стек або кладуть туди інші об’єкти. Ці об'єкти, ймовірно, реалізують простий інтерфейс із функцією simulate ().

Якщо застосувати до мого попереднього прикладу травлення, це означатиме:

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

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

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

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

У нас є номер повороту, який збільшується з кожним кроком. І ми підтримуємо карту майбутніх номерів поворотів, що вказують на набір об'єктів, про які потрібно повідомити в цьому ході.

Здається, схожа проблема, як у входів: у вас на клавіатурі 100 клавіш, але ви не хочете перевіряти кожну окрему клавішу на кожному кадрі, і що робити?

Дві відповіді: опитування або системні повідомлення.

Опитування = в будь-який момент, коли це насправді має значення в грі, запитайте про стан клавіш клавіатури (або об’єктів у вашому випадку). Решту часу ігноруйте їх.

Повідомлення = кожна клавіатура (об’єкт) кладе щось у чергу повідомлень під час натискання або відпуску (коли вона потребує уваги). На кожній ітерації циклу гри він проглядає чергу і вирішує всі повідомлення, перш ніж продовжувати.

Тож я збираюся зробити крок назад від реалізації та переглянути питання з точки зору дизайну. Чи є у вас чіткий план відображення всіх деталей, які ви хочете включити в це моделювання?

Наприклад:

• Чи може гравець сказати різницю між твариною з порожнім шлунком і твариною з повним?
• Чи важлива ця інформація для них будь-яким чином, коли вони роблять вибір взаємодії у вашій грі?
• Чи може гравець, який спостерігає за твариною, послідовно прогнозує результат ваших симульованих подій, чи вистачить випадкового числа?

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

Моделювання поведінки - це задоволення від роботи, але завжди майте на увазі кінцевих користувачів.

У мене була подібна проблема в грі, над якою я працював кілька років тому - моделювання об'єктів було складним і не могло реально виконати детально кожен об'єкт у світі.

Рішення полягало у використанні концепції LOD для моделювання. Об'єкти, що знаходяться в полі зору гравця, виконували б повне моделювання. Об'єкти, віддалені від гравця, періодично проводили сильно спрощене моделювання. По мірі того, як об’єкти потрапляють у поле зору гравця, вони переходять від курсу, періодичного оновлення моделювання до детального, регулярного оновлення.

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

Для цього є модель дизайну. Я думаю, це називається Об'єкти бази даних?

В основному ви зберігаєте одну "шаблонну" вівцю, яка може представляти всіх неспеціальних овець у ігровому світі, малювати їх все однаково, зберігаючи унікальні дані всередині об'єкта шаблону, скажімо, як таблицю розташування овець та / або час -нарізати. Тоді, коли вам потрібно зробити вівцю унікальною, ви можете створити конкретний екземпляр для відстеження цих унікальних овець.

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

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

Це за своєю природою схоже на використання делегата для анімації.

Чи працювала б державна машина? Тварина перебуває у напів сплячому стані, в їжі, у запущеному стані тощо. Для кожного стану ви пов'язуєте список діючих органів. Таким чином, кожен кадр, який ви відвідуєте кожну тварину, перемикає стан, шукає список органів для цього стану та виконує оновлення для кожного з органів.