Спасибо. Альфа-бета отсечения, это оптимизация для алгоритма Минимакс, который используется в пошаговых играх, где соперники делают ход поочередно. Данная задача не относится к такому типу игр.
А почему так? Ведь это же 1 единица прочности, но 2 единицы урона!
Совершенно верно! Когда пытался учесть не только суммарное hp, но и колличество юнитов — внезапно начал выходить за лимит времени. Поэтому бросил эту затею. Похоже текущая боевая система оказалась хорошим компромиссом между быстродействием и точностью, и позволила выделить больше времени на другие вещи.
Интересно, а как выбирается очередность?
В финальной версии есть стратегия управление истребителями c высоким приоритетом, и одно из её заданий — это погоня за вражескими вертолетами, которые в данном конкурсе пресдтавляли наибольшую опасность.
Термин искусственный интеллект — довольно многогранен. Написание игровых ботов, это одна из граней. Вы наверно путаете с машинным обучением, которого тут действительно нет.
Если выбирать из двух — то второе конечно лучше. Т.к. доступ к кешу реализован в отдельной абстракции.
Но все таки мне кажется не совсем правильно выделать абстрактный класс BaseUseCacheStoredService только ради простоты переиспользования удобных методов работы с кешем. Я бы тут наследование, заменил композицией — методы из этого сервиса перенес в IShorttemStore и дергал бы их напрямую. А IShorttemStore инжектил бы только в тот сервис где оно нужно. Это решает проблему, что если нужно несколько видов кешей в одном сервисе, или разные виды кеша в зависимости от окружения, для одного и того же сервиса. Наследование в данном случае не гибко т.к. предполагает только один вид кеша. С реализациями методов в IShorttemStore можно допустим для консольного приложения поднять один и тот же сервис с реализацией кеша в памяти, а в веб приложении, с реализацией кеша в сессии и за счет полиморфизма реализации сервиса будет все равно с каким кешем она работает.
Зависит от того как вы понимаете термин AI. Многие его понимают как нечто что обязательно должно самообучаться, но это не всего так. Если посмотреть статью на вики то там видим такое определение:
Major AI researchers and textbooks define this field as «the study and design of intelligent agents»,where an intelligent agent is a system that perceives its environment and takes actions that maximize its chances of success.
Intelligent agent — хоккеисты.
environement — поле, шайба, правила игры, хоккеисты соперника, физика мира.
actions — действия хоккеистов.
Так что формально это и есть AI.
Вот как значит оказывается, кого-то физика отпугивает, а кого-то наоборот привлекает.
Я вот (GreenTea) из-за необходимости реверс инжиниринга физики вообще решил не участвовать… Как-то этот класс задач не особо интересен.
Но за статью все равно спасибо, было интересно почитать.
Если действительно на все это ушло в сумме по времени только несколько дней — то ты мегамонстр! :)
Спасибо, очень интересно было почитать.
Я к сожалению начал не с того конца: а именно с перебора минимаксом ходов в бою. А именно, перебирались не шаги в рамках отдельного хода, а полные ходы. Т.е. например для соладата генерируем 10 возможных продолжений в бою. Грубо говоря:
1) атака одного
2) атака другого
3) атаки с низкой стойки,
4) атаковать и убежать,
5) атаковать присесть за укрытие
и тд.
Потом для следующего бойца. и тд. расширяя дерево поиска.
В итоге бот отлично воевал если все враги видимы — т.к. можно достаточно точно просчитать. но если враг предпочитал прятаться в тени, и атаковать изподтижка — то тут проблемы. Бойцы слишком опрометчиво бросались в атаку видя только одного врага. Приходилось вставлять всякие костыли.
В небоевом режиме перебор появился слишком поздно. Не успел его развить как следует :)
Трудно живется .NET программистам без OSGi :)
Недостатки текущей реализации которых не было бы в OSGi:
— общие ресусры
— общее пространство имен с базовым сайтом.
— недостаточный контроль зависимостей между плагинами (можно ли сделать один плагин зависящим от другого?)
— не понятно как реализовать взаимодействие плагинов между собой.
— необходимость перезапуска приложения для установки / удаления плагина.
Проверил на скорую руку, что для рассматриваемой задачи, если дерево представляет собой вырожденный случай списка, глубиной скажем 1 миллион, то приведенный код выбрасывает StackOverflowError. Немного обидно получается. Нельзя ли как то справить ситуацию?
В теории да, но на практике, юнит тесты на трансляторы, особенно если сущности большие и сложные — будут по коду в несколько раз сложнее самого транслятора (того самого тупого кода). Т.к. нужно проверить много вариантов: если большая вложнность getA().getB().getC() — 1) проверить если есть A B C, потом что A B есть, а C — null, и т.д. Да, безусловно надежность будте повышаться, но ценой долгого выпиливания юнит тестов. И если сроки поджимают будет скорее всего не до юнит тестов.
Спасибо! Не забудьте обновится до версии 0.8.1. Насчет туториала да, буду что-то думать… Если будут какие-то проблеммы или вопросы, пишите в Discussions на страничке проекта. Возможно туториал будет там же в Wiki.
Да можно же запилить интеграцию иде под конкретную либу. Расширить Find Usages.
Согласен.
Чисто мое имхо — использовать нечто, не умеющее интеграцию с иде (или иде, не умеющее интеграцию с этим) — не буду, пока интеграция не появится либо я не прикручу ее самостоятельно.
Идея вас разбаловала я вижу :) А как же написание исходного кода в блокноте, как же хардкор? :)
Кстати, это навеяло добавить в java-object-merger функцию типа testMapping, которая проделате все вышеперечисленное. и выругается если какое-то поле в целевом объекте (или одном из его чайлдов) осталось незамапленное…
Приходилось писать большое число тестов для мепперов (а написание теста по трудоемкости в 2 раза превышает написание самого меппера)
Мы слишком ленивые чтобы писать юнит тесты в текущем проекте =) Но есть одна идея как можно было бы простестить весь маппинг особо не напрягаясь… По сути, при автоматическом маппинге декларативно описывается, что куда мапить Значит будет достаточно проверить чтобы все поля замапились. И вот как это можно сделать. Допустим есть DTO и есть VO на которую мапим. 1) Заполняем все поля DTO, а так же ее чайлдов — случайными данными. Это можно сделать рефлешеном, используя тот же common-beanutils. 2) Мапим. 3) Проверям что на VO — все поля заполнены, тем же common-beanutils. Таким тестом проверим самую распространенную ошибуку, когда поля в DTO и VO случаной назвали по разному, и автоматический маппинг не сработал (ошибки он тоже не выдаст в этом случае). Если же присутствует аннотация @Mapping и поля на корое она ссылается нет — то будет ошибка во время маппинга. Таким образом можно обойтись одним (хотя и сложным) тестом.
Совершенно верно! Когда пытался учесть не только суммарное hp, но и колличество юнитов — внезапно начал выходить за лимит времени. Поэтому бросил эту затею. Похоже текущая боевая система оказалась хорошим компромиссом между быстродействием и точностью, и позволила выделить больше времени на другие вещи.
В финальной версии есть стратегия управление истребителями c высоким приоритетом, и одно из её заданий — это погоня за вражескими вертолетами, которые в данном конкурсе пресдтавляли наибольшую опасность.
Но все таки мне кажется не совсем правильно выделать абстрактный класс BaseUseCacheStoredService только ради простоты переиспользования удобных методов работы с кешем. Я бы тут наследование, заменил композицией — методы из этого сервиса перенес в IShorttemStore и дергал бы их напрямую. А IShorttemStore инжектил бы только в тот сервис где оно нужно. Это решает проблему, что если нужно несколько видов кешей в одном сервисе, или разные виды кеша в зависимости от окружения, для одного и того же сервиса. Наследование в данном случае не гибко т.к. предполагает только один вид кеша. С реализациями методов в IShorttemStore можно допустим для консольного приложения поднять один и тот же сервис с реализацией кеша в памяти, а в веб приложении, с реализацией кеша в сессии и за счет полиморфизма реализации сервиса будет все равно с каким кешем она работает.
Intelligent agent — хоккеисты.
environement — поле, шайба, правила игры, хоккеисты соперника, физика мира.
actions — действия хоккеистов.
Так что формально это и есть AI.
Я вот (GreenTea) из-за необходимости реверс инжиниринга физики вообще решил не участвовать… Как-то этот класс задач не особо интересен.
Но за статью все равно спасибо, было интересно почитать.
Если действительно на все это ушло в сумме по времени только несколько дней — то ты мегамонстр! :)
Я к сожалению начал не с того конца: а именно с перебора минимаксом ходов в бою. А именно, перебирались не шаги в рамках отдельного хода, а полные ходы. Т.е. например для соладата генерируем 10 возможных продолжений в бою. Грубо говоря:
1) атака одного
2) атака другого
3) атаки с низкой стойки,
4) атаковать и убежать,
5) атаковать присесть за укрытие
и тд.
Потом для следующего бойца. и тд. расширяя дерево поиска.
В итоге бот отлично воевал если все враги видимы — т.к. можно достаточно точно просчитать. но если враг предпочитал прятаться в тени, и атаковать изподтижка — то тут проблемы. Бойцы слишком опрометчиво бросались в атаку видя только одного врага. Приходилось вставлять всякие костыли.
В небоевом режиме перебор появился слишком поздно. Не успел его развить как следует :)
Недостатки текущей реализации которых не было бы в OSGi:
— общие ресусры
— общее пространство имен с базовым сайтом.
— недостаточный контроль зависимостей между плагинами (можно ли сделать один плагин зависящим от другого?)
— не понятно как реализовать взаимодействие плагинов между собой.
— необходимость перезапуска приложения для установки / удаления плагина.
Согласен.
Идея вас разбаловала я вижу :) А как же написание исходного кода в блокноте, как же хардкор? :)
Мы слишком ленивые чтобы писать юнит тесты в текущем проекте =) Но есть одна идея как можно было бы простестить весь маппинг особо не напрягаясь… По сути, при автоматическом маппинге декларативно описывается, что куда мапить Значит будет достаточно проверить чтобы все поля замапились. И вот как это можно сделать. Допустим есть DTO и есть VO на которую мапим. 1) Заполняем все поля DTO, а так же ее чайлдов — случайными данными. Это можно сделать рефлешеном, используя тот же common-beanutils. 2) Мапим. 3) Проверям что на VO — все поля заполнены, тем же common-beanutils. Таким тестом проверим самую распространенную ошибуку, когда поля в DTO и VO случаной назвали по разному, и автоматический маппинг не сработал (ошибки он тоже не выдаст в этом случае). Если же присутствует аннотация
@Mappingи поля на корое она ссылается нет — то будет ошибка во время маппинга. Таким образом можно обойтись одним (хотя и сложным) тестом.