Gamedev LectureФорум

Лекция #12. AI. Подходы, тимплей, взаимодействие с миром, оптимизации для большого мира. [Лектор - roman_p] (комментарии)

#0
17:08, 7 фев 2006

Лекция #12. AI. Подходы, тимплей, взаимодействие с миром, оптимизации для большого мира. [Лектор - roman_p] (комментарии)

Это сообщение сгенерировано автоматически.

#1
17:08, 7 фев 2006

Хорошая лекция.
Жалко про  transport мало, но идея понятна. Только как реализовать сложные варианты типа передачи информации дымом костров.
А со столом вроде есть более простое решение - мастером становится тот кто первый бросил стол.
И книгу "ИИ Современный подход" я уже прочитал:) Рекомендую.

#2
1:30, 2 мар 2006

Привет Роман !

Спасибо за лекцию. Мне интересна эта тема, буду рад услышать ответы на некоторые вопросы:

Реализация и производительность системы восприятия (Perception).

Сколько сенсоров в большинстве случаев приходилось на юнит? Наверняка были случаи "несколько глаз, ушей на одного юнита" например, как бы выглядело решение следующей задачи "юнит видит всех на расстоянии 10 метров, а на расстоянии 20 метров только тех юнитов на которых нет шапок-невидимок"?

Был один общий список всех воспринимаемых юнитов или у каждого сенсора свой ? Кэшировался ли он (т.е обновлялся периодически у всех обладающих восприятием), или составлялись каждый раз при запросе ?

Система восприятия работала всегда или отключалась(замедлялась) при каких либо условиях, например у юнитов появлялась возможность воспринимать окр. среду только когда рядом находился г. Герой или камера ?

Что использовала система восприятия для непосредственного поиска юнитов в мире, квадродерево какое-нибудь:) ?

Что кроме юнитов на практике обладало восприятием (т.е. работало через систему), области-триггеры (т.е. на полу кнопка, она лежит и видит всех кто на неё наступил...) ?

#3
16:59, 2 мар 2006

> Жалко про transport мало, но идея понятна.
> Только как реализовать сложные варианты типа передачи информации дымом костров.

Примерно так:

class BonfireTransport : public Transport
{
public:
   virtual bool SendEvent ( const Event & event, Time delay )
   {
      if ( event == EVENT_DANGER )
      {
         // отсылаем только сообщение об опасности, другие сообщения отсылать костер не умеет
         m_event = event;
         m_delay = delay;
         return true;
      }     
      else
        return false;
   }

   virtual void DoWork ()
   {
      // поищем костер вокруг
      Bonfire * bonfire = me->PerceptionFind ( BONFIRE );
      if ( ! bonfire )
      {
         // идем к нему
         if ( me->Go ( bonfire->position ) )
         {
            // когда пришли - зажигаем и отсылаем сообщение с задержкой в BONFIRE_DELAY сек
            bonfire->FireAndForget ();
            Transport::SendEvent ( m_event, BONFIRE_DELAY + m_delay );
            StopWork ( SUCCESS );
         }
      }
      else
         StopWork ( FAILED );
   }

   // и т.д.
}
#4
17:41, 2 мар 2006

> Реализация и производительность системы восприятия (Perception).

Так как я описывал все абстрактно - точно также и буду отвечать на вопросы.

> Реализация

Как получиться.
Общие принципы - я описал, а дальше - полет фантазии.

> Производительность

Тут все просто.
1. Оптимизировать только рабочий код.
2. Profiler.
3. LOD.
4. Batch.
5. Сначала оптимизировать алгоритм, а потом уже настраивать Intel Compiler.

> Сколько сенсоров в большинстве случаев приходилось на юнит?

Столько сколько задаст геймдизайнер в редакторе персонажей.

> как бы выглядело решение следующей задачи "юнит видит всех на расстоянии 10 метров, а на
> расстоянии 20 метров только тех юнитов на которых нет шапок-невидимок"?

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

> Был один общий список всех воспринимаемых юнитов или у каждого сенсора свой
> Кэшировался ли он (т.е обновлялся периодически у всех обладающих восприятием),
> или составлялись каждый раз при запросе ?

Скорее всего - лучше делать у каждого сенсора свой список.
Список - и есть кеш. С кешем - в разы быстрее. У кеша может быть свой LOD периода обновлений.
Т.е. мозг персонажа обсчитываем со своей частотой, perception с другой, а pathfinder с третьей.
И все это на LOD завязано, чем дальше - тем реже.

> Система восприятия работала всегда или отключалась(замедлялась) при каких либо условиях, например у
> юнитов появлялась возможность воспринимать окр. среду только когда рядом находился г. Герой или камера ?

LOD. Unit далеко - считаем реже, совсем далеко - вообще не считаем или убиваем нафиг этот unit.

> Что использовала система восприятия для непосредственного поиска юнитов в мире,
> квадродерево какое-нибудь:) ?

Да, все что угодно.
Поиск объекта в мире - базовая функция двигала.

> Что кроме юнитов на практике обладало восприятием (т.е. работало через систему),
> области-триггеры (т.е. на полу кнопка, она лежит и видит всех кто на неё наступил...) ?

Треггеры - это всем другая система, не AI ни разу.
Лучше делать отдельно, а не через систему perception-ов.

#5
20:56, 2 мар 2006

Кстати, книжка Artifical Intelligence: A Modern Approach на английском есть в осле. 32 или 36 метров.

#6
21:13, 2 мар 2006

Тутвсепросто.
1.Оптимизироватьтолькорабочийкод.
2.Profiler.
3.LOD.
4.Batch.
5. Сначала оптимизировать алгоритм, а потом уже настраивать Intel Compiler.

что такое batch? Это для того чтобы размазать вычисления по времени?

Скорее всего - лучше делать у каждого сенсора свой список.
Список - и есть кеш. С кешем - в разы быстрее. У кеша может быть свой LOD периода обновлений.
Т.е. мозг персонажа обсчитываем со своей частотой, perception с другой, а pathfinder с третьей.
И все это на LOD завязано, чем дальше - тем реже.

Понятно, значит, список пересчитывается не по запросу а по таймеру..

Треггеры - это всем другая система, не AI ни разу.
Лучше делать отдельно, а не через систему perception-ов.

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

Интересны цифры, персепшн скольки юнитов расчитывался одновременно ( 20 - 30 ? ) сколько персепшенов в среднем было на один юнит ( 2 -3 ?) как часто обновляются списки в персепшенах ?

#7
21:15, 2 мар 2006

Кстати, книжка Artifical Intelligence: A Modern Approach на английском есть в осле. 32 или 36 метров.

кто-нибудь знает, применимы ли знания из этой книги к игровому ИИ ? Или там глубокая теория, которая далека от реального применения в игровом ИИ ?

#8
12:13, 3 мар 2006

LSL
> что такое batch?

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

Ещё, например, есть несколько 3д объектов с небольшим количеством треугольников в геометрии, если у них совпадает шейдер, текстура, материал, вершинный формат, то можно их всех объединить в один меш и отрендерить за один раз, что поднимет производительность. Это тоже batch, то есть сбор нескольких объектов для общей операции.

#9
13:32, 3 мар 2006

wat

понятно.. У меня наоборот необходимо вычисления рассредоточить по времени, чтобы не было скачков фпс.

#10
23:24, 3 мар 2006

> что такое batch? Это для того чтобы размазать вычисления по времени?

batch - группа, объединение, партия, содружество.
Приминительно к AI - это в самом простом случае - объединение юнитов в группы, для которых некоторые (или все) вычисления одинаковые.

> Понятно, значит, список пересчитывается не по запросу а по таймеру..

1. Можно по таймеру, через K msec (в зависимости от LOD) рассчитывать что-нибудь. Для всех объектов.
2. Можно по запросу, но если не прошло K msec от предыдущего запроса, то ничего не считаем, а возвращяем предыдущий (старый) результам. Таким образом не все объекты будут обсчитываться, а только нужные.

Обычно 1 вариант применят для NPC и Brain - так как обычно их все надо обсчитать.
А 2 вариант - для всего остального.

Из сложного:
Есть еще slicing (расщепление) - это когда какие-то вычисления длятся K msec, а потом прерываются.
Возможно возвращять неполный результат или флаг указывающий что еще не расчитано.
Алгоритм вычислений становиться нетривиальным, требования к памяти могут вырасти - из-за того что алгоритм может быть прерван в любой момент (ну или не совсем в любой момент, а например в одном определенном месте в первом цикле), а потом еще надо уметь восстановить вычисления с определенного момента. Для pathfinding-а такое точно можно сделать.

> Почему бы не через персепшн сделать? Например, лежит змея, если на неё наступить сработает
> персепшен прикосновения, внесёт жертву в список или оповестит кого надо...
> то же самое с кнопкой - ловушкой...

Если триггер - это NPC - тогда можно и так ;)

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

Т.е. в самом максимальном случае:

struct Trigger
{
  Vector min, max;     // область действия триггера

  void (* enter) ();    // когда зашли, вызывается 1 раз
  void (* leave) ();    // когда вышли, вызывается 1 раз
  void (* inside) ();   // когда внутри, высызывается постоянно
}

> Интересны цифры, персепшн скольки юнитов расчитывался одновременно ( 20 - 30 ? )
> сколько персепшенов в среднем было на один юнит ( 2 -3 ?) как часто обновляются списки в персепшенах ?

Точные цифры зависят от многих факторов.
Примерно все так - как ты и сказал.

#11
23:50, 3 мар 2006

RomanPshenichny

Спасибо ! Интересная информация... :)

#12
17:57, 4 мар 2006

RomanPshenichny Спасибо за ответ, по коду мне удобнее.  Я только думал о передаче информацией азбукой морзе, типа прерывистого дыма костров, машущих птиц во Франции эпохи Графа Монте-Кристо, прожекторов и флажков на флоте. Но уже понятно:) Надо просто память добавить.

Пошёл покупать "Магию крови". Это мой стиль игр, надеюсь получить удовольствие:)


LSL Я до того, что написано в статье дошёл только благодаря "ИИ Современный подход". Различие в терминологии только одно: DoWork - Action,
+ показаны разные варианты построения внутренностей агента и как сделать подбор коэф.
- нет командного взаимодействия и сжато восприятие
- ну и естественно нет вопросов как реализовать игровые оптимизации.

Gamedev LectureФорум

Тема в архиве.