Matthew Fisher из Стэнфордского Университета написал интересную статью о реализации бота на основе перехвата потока API библиотеки D3D9 (Microsoft Direct 3D, являющуюся частью библиотеки DirectX).
Как пишет сам автор, бот играет в Starcraft 2 (SC2) перехватывая, понимая и реагируя на поток сообщений D3D9, посылая нажатия клавиш и движения мыши обратно игре. Он не похож на других ботов, сделанных на основе редактора SC2 и использующих скриптовый язык, или проектов наподобии BWAPI (работает только с оригинальным StarCraft), который внедряется в адресное пространство игры. Боты, основанные на этих методах зачастую имеют возможность обойти ограничения, с которыми сталкивется человек при игре; например, они могут одновременно отдавать разные приказы разным юнитам, они могут видеть происходящее вне экрана в любое время, им не составляет труда добраться до наземного юнита, закрытого летающим.
В статье довольно много технических подробностей и выложены исходники кода, которые реализуют бота. Основная задача статьи – показать простую программу, которая работает как перехватчик и интерпретатор команд D3D9. Преимущество такого подхода к реализации бота по сравнению с другими методами (внедрение в адресное пространство, написание бота на скриптовом языке SC2) очевидны – метод универсален и его можно применять к другим программам, создание бота по этому методу должно быть легче и доступнее. Недостатки метода тоже довольно очевидны: на разбор сцены уходит довольно много времени и сил и достичь APM (количество действий в минуту) сравнимых с другими методами скорее всего не получится.
Бот разделен на три компонента:
1. Mirror Driver – хранилище базовых объектов, которые отрисовываются на карте. Объекты представляют собой текстуры, шейдеры, пиксели и другую базовую графическую информацию.
2. Scene Understanding – данные, полученные Mirror Driver поступают на вход этому компоненту, который преобразовывает их в сущности, которые присутствуют в игре. То есть переводит базовую информацию на более высокий уровень, с которой уже можно строить стратегию управления игрой.
3. Decision Making – компонент, отвечающий за принятие решения, или по-простому – мозги бота.
Так как поток вызовов рендеринга сцены последователен, результат разбора сцены представляет собой таблицу (много трафика), которую необходимо преобразовать в информацию, на основе которой можно принимать решения и управлять игрой. После принятия решения на основе опять же графической информации посылается то или иное нажатие мыши или клавиши клавиатуры.
Бот хранит информацию о всех доступных параметрах игры: количестве юнитов под его управлением, замеченных врагах и т.д. и принимает решение на основе этой информации. Всю информацию о своих действиях бот выводит в консоль, что позволяет легко производить отладку.
Алгоритм принятия решения очень похож на действия человека. Дается та или определенная команда, бот ее пытается выполнить. Например: построить здание, добавить юнита в группу, атаковать врага и т.д.
Самой интересной частью конечно же является наблюдение за игрой бота и его действий. Автор статьи записал видео игры под управление бота:
По результатам анализа игры SC2 показал, что в “спокойное” время APM бота находится в пределах 500 действий, в режиме битвы от 1000 до 2000. Не все эти действия полезны и микроуправление сложно реализовывать; команды бота могут быть бесполезны или даже вредны, по сравнению с поведением юнита по умолчанию.
Учитывая что автор ставил целью статьи именно показать, какие инструменты можно использовать для написания “базы” бота, а не реализацию самого бота, это довольно хороший результат. Ведь для улучшения показателей бота, можно менять компонент принятия решений, особых технических ограничений для построения бота такая реализация не накладывает.
Как пишет сам автор, бот играет в Starcraft 2 (SC2) перехватывая, понимая и реагируя на поток сообщений D3D9, посылая нажатия клавиш и движения мыши обратно игре. Он не похож на других ботов, сделанных на основе редактора SC2 и использующих скриптовый язык, или проектов наподобии BWAPI (работает только с оригинальным StarCraft), который внедряется в адресное пространство игры. Боты, основанные на этих методах зачастую имеют возможность обойти ограничения, с которыми сталкивется человек при игре; например, они могут одновременно отдавать разные приказы разным юнитам, они могут видеть происходящее вне экрана в любое время, им не составляет труда добраться до наземного юнита, закрытого летающим.
В статье довольно много технических подробностей и выложены исходники кода, которые реализуют бота. Основная задача статьи – показать простую программу, которая работает как перехватчик и интерпретатор команд D3D9. Преимущество такого подхода к реализации бота по сравнению с другими методами (внедрение в адресное пространство, написание бота на скриптовом языке SC2) очевидны – метод универсален и его можно применять к другим программам, создание бота по этому методу должно быть легче и доступнее. Недостатки метода тоже довольно очевидны: на разбор сцены уходит довольно много времени и сил и достичь APM (количество действий в минуту) сравнимых с другими методами скорее всего не получится.
Бот разделен на три компонента:
1. Mirror Driver – хранилище базовых объектов, которые отрисовываются на карте. Объекты представляют собой текстуры, шейдеры, пиксели и другую базовую графическую информацию.
2. Scene Understanding – данные, полученные Mirror Driver поступают на вход этому компоненту, который преобразовывает их в сущности, которые присутствуют в игре. То есть переводит базовую информацию на более высокий уровень, с которой уже можно строить стратегию управления игрой.
3. Decision Making – компонент, отвечающий за принятие решения, или по-простому – мозги бота.
Так как поток вызовов рендеринга сцены последователен, результат разбора сцены представляет собой таблицу (много трафика), которую необходимо преобразовать в информацию, на основе которой можно принимать решения и управлять игрой. После принятия решения на основе опять же графической информации посылается то или иное нажатие мыши или клавиши клавиатуры.
Бот хранит информацию о всех доступных параметрах игры: количестве юнитов под его управлением, замеченных врагах и т.д. и принимает решение на основе этой информации. Всю информацию о своих действиях бот выводит в консоль, что позволяет легко производить отладку.
Алгоритм принятия решения очень похож на действия человека. Дается та или определенная команда, бот ее пытается выполнить. Например: построить здание, добавить юнита в группу, атаковать врага и т.д.
Самой интересной частью конечно же является наблюдение за игрой бота и его действий. Автор статьи записал видео игры под управление бота:
По результатам анализа игры SC2 показал, что в “спокойное” время APM бота находится в пределах 500 действий, в режиме битвы от 1000 до 2000. Не все эти действия полезны и микроуправление сложно реализовывать; команды бота могут быть бесполезны или даже вредны, по сравнению с поведением юнита по умолчанию.
Учитывая что автор ставил целью статьи именно показать, какие инструменты можно использовать для написания “базы” бота, а не реализацию самого бота, это довольно хороший результат. Ведь для улучшения показателей бота, можно менять компонент принятия решений, особых технических ограничений для построения бота такая реализация не накладывает.