Форум: Проблемы искусственного интеллекта

Регистрация | Вход

Все темы | Новая тема  Стр.2 (4) << < Пред. | След. > >>    Поиск:
Автор	Тема: На: Проблемы отладки ИИ
гость 93.80.107.*	На: Проблемы отладки ИИ Добавлено: 31 авг 10 22:34 Цитата: Автор: daner В начале хотел описать визуализацию которую мы применяем при мониторинге принятия решений как отдельными роботами, так и группой сразу.... Но потом вы написали вот это А значит, вас интересует не таже самая визуализация, что и меня. Думаю, для вас наиболее полезным ответом будет ответ В.Царегородцева. Я написал про ИНС, т.к. это часто используемый термин, а я пока не очень представляю какую терминологию использовать для описания того что мне нужно. Ответ В.Царегородцева был полезен, спасибо ему. Но в основном, в плане общего развития, есть интересные материалы на его сайте. Мониторинг принятия решений роботом звучит более близко к моей задаче. Поэтому было бы интересно увидеть описание визуализации которую Вы применяете для этого. [Ответ][Цитата]
daner Сообщений: 4633	На: Проблемы отладки ИИ Добавлено: 01 сен 10 3:28 ну так... описали бы своими словами, то что вы делаете и где именно возникают проблемы, для которых необходима визуализация. Что касается моей работы, то мы используем несколько уровней мониторинга. 1. симуляция -- внешняя визуализация работы роботов. Звучит банально, но совершенно необходимая штука. Отлаживать сложную задачу просто на роботах -- не реально, поэтому намного удобнее делать это в вируальной среде и уже затем, дотачивать системы в реальных условиях. В основном используем готовые решения, но один раз пришлось писать свой вариант, так как готовые не подходили или требовали слишком много работы для их приспособления. Кстати, получилось удобное приложение состоящая из двух частей: движок тестирования/собственно симулярор, которых был встроен в саму системы и распределен по девайсам (т.е. для каждого девайса свой симулятор), для возможности тестирования отдельных девайсов не отходя от кассы и программа мониторинга, которя отображала положение роботов на карте и их состояние (только какие-то глобальные состояния, типа поломки, заправки и т.д.). Интересно то, что обе части в принципе не зависимые. Симуляция серьезным образом увеличивает частоту исправлений (цикл: исправление-тестирование-исправление-тестирование-....). Где то читал интервью капитана русской комманды победившей в футбольном соревновании (только вирт.среда и какая лиго была не помню). Он подчеркивал, что считает основной причиной их победы именно то, что они смогли больше чем все остальные сократить цикл исправления. Я с ним совершенно согласен (на основе моего опыта). 2. Визуализация состояний системы. Так как у нас система BDI групповых решений, то и визуализируем мы следующие вещи а. Состояние МоделиМира относительно текущего поведения каждого робота. б. Иерархическую FSM группавого распределения ролей. в. Иерархическую FSM индивидуальных поведенией. В первом пункте, мы просто предоставляем список переменных в данных момент (online) во время работы системы. В двух последних, мы рисуем сами FSM и цветами отмечаем какие из состояний активные и какие именно роботы выбрали то или иное состояние. Таким образом происходит мониторинг одновременно всей группы роботов. Этот уровень визуализации удобен не только для дебагинга самой системы, но и очень понравился нашим клиентам, которые используя систему составляют программы поведения для реальных роботов или виртуальных агентов. Тем более, когда в системе появилась возможность проигрывать лог файлы системы в обоих направлениях (т.е. как фильм). Вот какой-то ролик в YouTube, старой версии нашей системы: http://il.youtube.com/watch?v=6nz8RuE72Bw (надеюсь будет показывать). 3. Простая пошагавая отладка программы. Слышится банально но когда речь заходит о кучи параллельных процессов начинаются проблемы. Во-первых, мы отказались от написания спец. языков в пользу стандартного с++ ( на котором написана система и на которой пишут код (плагины) пользователи ), что бы дать возможность пользователям использовать привычные дебагеры. Во-вторых, мы распределяем текст в лог файлах (как опция) визуально, так что бы можно было отличить с какого потока, какого ровота каждая строчка лог файла. [Ответ][Цитата]
Welkin Сообщений: 50	На: Проблемы отладки ИИ Добавлено: 05 сен 10 1:04 Цитата: Автор: daner Вот какой-то ролик в YouTube, старой версии нашей системы подскажите, для управления персонажем у вас имитировалось нажатие клавиш на клавиатуре, или как-то иначе? [Ответ][Цитата]
daner Сообщений: 4633	На: Проблемы отладки ИИ Добавлено: 05 сен 10 10:21 Цитата: Автор: Welkin подскажите, для управления персонажем у вас имитировалось нажатие клавиш на клавиатуре, или как-то иначе? Конечно иначе. Почти во всех подобных играх есть возможность писать скрипты. но обычно языки таких скриптов до безобразия примитивны (так как на сегодня ИИ в играх -- это максимум автомат, плюс/минус). Мы пишем на этом скрипте только часть подключения системы к игре, т.е. трансляцию данных (в обе стороны). Есть другой вариант -- использовать сетевой протокол, который игра применяет для связи с удаленным клиентом (но это зависит от архитектуры игры, скажем в DOOM3 такое не пройдет, в нем клиент толстый, но там и не надо). [Ответ][Цитата]
NO. Сообщений: 10700	На: Проблемы отладки ИИ Добавлено: 05 сен 10 16:03 Я думаю в хороших играх карты компилируются, то есть прогоняется логика юнитов и результаты становятся частью карты, потом юниты бегая по карте просто берут готовые данные, а не выполняют скрипты. Скрипты пишутся в предполжении что мир не известен, а когда есть карта это предположение не верно. [Ответ][Цитата]
daner Сообщений: 4633	На: Проблемы отладки ИИ Добавлено: 05 сен 10 20:53 Цитата: Автор: NO. Я думаю в хороших играх карты компилируются, то есть прогоняется логика юнитов и результаты становятся частью карты, потом юниты бегая по карте просто берут готовые данные, а не выполняют скрипты. Скрипты пишутся в предполжении что мир не известен, а когда есть карта это предположение не верно. Вы ошибаетесь. 1. почитайте например как писался AI к игре Сталкер. Очень не плохой вариант, скажу я вам. 2. Многие игровые движки (а движков, вообще-то не так много, так как это самая сложная часть и на одном движке создается куча разных игр) имеют возможность добавление своей логики поведения различных элементов игры. Эта логика и называется скриптами (хотя иногда они даже компилируются в некую промежуточно-бинарную форму. Во всех вариантах скриптов, которые я видел, существует какое-то подобие функции "step", в которой можно получить сенсорные данные управляемого существа и определить его активаторы (обычно это образы, которые уже не нужно распознавать, да и шумов обычно тоже нет). 3. здесь разговор по любому ведется не столько об играх, сколько о симуляции на основе игр. Соответственно предполагается что мир не известен. 4. Как вы знаете, иногда алгоритм описываемый очень простой логикой для кучи мелких элементов приводит к поведению системы в целом такому, которое описывается очень сложным алгоритмом. 5. Кроме карты, есть еще и игроки, поведение которых конечно предсказуемо, но все-таки не известно (так как в хороших играх игроку отводится очень большая свобода действий и все варианты прописать нет возможности. экспоненциальный БУМ, знаете ли). Поэтому и логика игровых персонажей (в хороших играх) не должна быть совсем уж жестко прописанной. [Ответ][Цитата]
NO. Сообщений: 10700	На: Проблемы отладки ИИ Добавлено: 05 сен 10 21:15 мне больше нравятся стратегии, где юнитов много и думать им некогда [Ответ][Цитата]
daner Сообщений: 4633	На: Проблемы отладки ИИ Добавлено: 05 сен 10 22:39 Цитата: Автор: NO. мне больше нравятся стратегии, где юнитов много и думать им некогда Как игры -- мне тоже. Но это совсем другой тип игр. В них юниты -- не самостоятельны, они как пальцы одной руки. Впрочем, было бы интересно, если бы были игры-стратегии, где для каждого юнита можно было бы писать отдельные скрипты, и пусть с точки зрения перцепции и действий, вариантов будет на много меньше чем в 3Д шутере, все равно было бы полезно. но я про такие игры не слушал. [Ответ][Цитата]
NO. Сообщений: 10700	На: Проблемы отладки ИИ Добавлено: 06 сен 10 0:13 Отдельно управлять каждым это что называется "специального назначения", таких нужно не много. И если противник лечится, ремонтируется, реорганизует оборону, то стратегических выгод они не дают. мне не хватает - "менеджеров среднего звена", которых можно ставить цели, а они бы руководили действиями рядовыми - рисовать план операций на карте, тоже с условиями как выбирать варианты, типа программы - для экономики выставлять приоритеты и цели, какой-то план развития - можно юнитам добавить типа психологии, чтоб были не совсем машинки, обычно кроме здоровья никаких параметров нет, насколько я помню реальную армию там все далеко не ангелы, поговорка "свой дурак хуже врага" довольно актуальна - патроны можно оставить бесконечными, а то будет слишком сложно Но все равно думаю логика делится на генерацию событий, генерацию вариантов действий, координацию и принятие решений. Трудоемкое самое первое лучше делать это не опросом из скрипта унита, а из среды, только по её изменениям. Сложных игрушек наверно нет потому, что трудно устроить приятный геймплей. Когда автоматика работает правильно это как бы нормально, а если раз за разом идут одни и те же ошибки, это очень не приятно. [Ответ][Цитата]
daner Сообщений: 4633	На: Проблемы отладки ИИ Добавлено: 06 сен 10 1:31 вообще-то я рассуждал не сточки зрения игрока и не с точки зрения игровых интерфейсов. Я говорил о писания сторонних скриптов. А в них проблемы "менеджеров среднего звена" -- это ваши проблемы, т.е. как напишите -- так и будет. [Ответ][Цитата]
NO. Сообщений: 10700	На: Проблемы отладки ИИ Добавлено: 06 сен 10 2:06 Индивидуальные действия проще не писать, а показать, типа макросов. А группы самоорганизуются слишком медленно, для военных игр. Лучше иметь командира, так хотя бы свои между собой не передерутся. Отлаживать такие вещи трудно. Лучше именно простой язык, а доделывать компилятор. Чтобы "абстрактной интерпретацией", на этапе компиляции, выявлять разные возможные ситуации, не выполняя весь не относящийся к проблеме код. Если рассматривать всё слишком теоретически, такое очень не просто или даже невозможно. А частные вещи делаются, если язык позволяет. Это же проблемы среды выполнения. А в программе иногда прерывания некуда поставить. Много нитей и ошибка возникает когда они завязываются узлом, при этом каждая отдельная работает правильно. [Ответ][Цитата]
daner Сообщений: 4633	На: Проблемы отладки ИИ Добавлено: 06 сен 10 18:42 Цитата: Автор: NO. Индивидуальные действия проще не писать, а показать, типа макросов. Иногда показать -- это еще более сложная задача, чем объяснить (написать скрипт). Есть даже целая ветвь исследований, обучение через демонстрацию. Цитата: Автор: NO. А группы самоорганизуются слишком медленно, для военных игр. Лучше иметь командира, так хотя бы свои между собой не передерутся. Я про самоорганизацию не говорил. впрочем -- если рассуждать теоретически, то сохраняя данные индивидуальных состояний унитов от игры к игре -- можно устроить некое подобие эволюционного процесса, при котором со временем униты выработают некие стратегии и социальные механизмы их реализации. Вообще... я бы "поиграл" во что-то такое . Цитата: Отлаживать такие вещи трудно. Лучше именно простой язык, а доделывать компилятор. Чтобы "абстрактной интерпретацией", на этапе компиляции, выявлять разные возможные ситуации, не выполняя весь не относящийся к проблеме код. Если рассматривать всё слишком теоретически, такое очень не просто или даже невозможно. А частные вещи делаются, если язык позволяет. Это же проблемы среды выполнения. А в программе иногда прерывания некуда поставить. Много нитей и ошибка возникает когда они завязываются узлом, при этом каждая отдельная работает правильно. Согласен, со всем написанным. Собственно "спец. архитектуры" как раз этим и занимаются. Но если язык поддерживает только команды высокого уровня -- это создает проблемы в других местах, поэтому мы и стараемся, с одной стороны позволить программисту работать на привычном ему с++, и делать все что ему взбредет в голову, с другой стороны определяем рамки (в виде специально заданных классов, функций и прочих конструкций) придерживаясь которых его нити не завяжутся в узел. Скриптовые языки в играх обычно поступают проще (для них стабильность игры дороже дополнительных возможностей для программистов логики) -- они запрещают (не дают возможности создавать) любые опасные для них элементы (например потоки) и предоставляют возможность использовать различные предопределенные механизмы (типа автоматов). Проблема только в том, что механизмы эти пока весьма скудные. Так что, серьезное поведение писать на них очень сложно. [Ответ][Цитата]
NO. Сообщений: 10700	На: Проблемы отладки ИИ Добавлено: 06 сен 10 20:44 Так не надо писать вручную. Они может для того и скудные. Ну и вот. После экспериментов нужно посмотреть по новой и выявить в чем суть происходящего. Из тяп-ляп слепленных поправок и стихийно складывающихся процессов сделать явно прописанную программу. Типа как река иногда переходит в новое русло. Так часто делают, будет версия 2.0. Только нужно отличать насколько система детерминирована, иногда часть программы дается только потом в параметрах, тут отлаживать нечего. Ну и отличать ИИ-полные задачи, когда для создания ИИ нужен ИИ, это проблема постановки. [Ответ][Цитата]
daner Сообщений: 4633	На: Проблемы отладки ИИ Добавлено: 06 сен 10 22:53 >>> NO если честно -- ничего не понял . Что не надо писать в ручную? Поведения агентов? Ну даже если все поведение и не писать -- что-то писать придется (скажем программу планирования или обучения), а для этого иногда необходимо и сторонние библиотеки подключать и много чего еще. А дальше, вообще не знаю о чем вы. [Ответ][Цитата]
NO. Сообщений: 10700	На: Проблемы отладки ИИ Добавлено: 07 сен 10 15:47 Я думаю нужно всю написанную логику собирать в одну систему, Рете и прочая оптимизация. Поэтому язык чем проще тем лучше. Дальше - это по теме, что можно чередовать разработку сверху-вниз и снизу-вверх, и что когда написано много, нужно начинать моделировать и программировать уже и это, хотя оно само тоже модель чего-то. Снова разбирать что существенно что нет, что от чего зависит. Можно почитать Брукса, про разработку больших систем. Методология никуда не направляет, но помогает хоть как-то осознавать чего творится и какая в этом роль/вина программиста. [Ответ][Цитата]
Стр.2 (4): 1  [2]  3  4 << < Пред. | След. > >>