Этот проект, состоящий из трех частей, направлен на моделирование матчей League of Legends в процессах принятия решений Маркова, а затем применение обучения с подкреплением для поиска оптимального решения, которое также учитывает предпочтения игрока и выходит за рамки простой статистики «табло».

Я сделал каждую часть доступной на Kaggle, чтобы лучше понять, как обрабатываются данные и кодируется модель. Я включил первые две части, чтобы внести некоторую ясность в обоснование моих окончательных решений о том, как моделируется среда.

Часть 1: https://www.kaggle.com/osbornep/lol-ai-model-part-1-initial-eda-and-first-mdp

Часть 2: https://www.kaggle.com/osbornep/lol-ai-model-part-2-redesign-mdp-with-gold-diff

Часть 3: https://www.kaggle.com/osbornep/lol-ai-model-part-3-final-output

Это очень большая работа, и она предназначена только для ознакомления с идеей того, чего можно достичь, если в игру будут введены более сложные методы машинного обучения, которые выходят за рамки простой сводной статистики, как показано на изображении ниже.

Мотивы и цели

League of Legends - это командная видеоигра, в которой две командные команды (по 5 игроков в каждой) соревнуются за цели и убийства. Получение преимущества позволяет игрокам стать сильнее (получать лучшие предметы и повышать уровень быстрее), чем их противники, и, по мере увеличения их преимущества, вероятность выигрыша в игре также увеличивается. Следовательно, у нас есть последовательность событий, зависящих от предыдущих событий, которые приводят к тому, что одна команда разрушает базу другой и выигрывает игру.

Статистическое моделирование подобных последовательностей не является чем-то новым; в течение многих лет исследователи рассматривали, как это применяется в спорте, таком как баскетбол (https://arxiv.org/pdf/1507.01816.pdf), где последовательность пасов, дриблинга и грубой игры приводит к тому, что команда получает или потеря очков. Цель исследования, такого как это упомянутое, состоит в том, чтобы предоставить более подробное представление, помимо простого подсчета очков (количество очков или убийств, набранных игроком в баскетболе или видеоиграх соответственно), и рассмотреть, как команды работают, когда моделируются как последовательность событий, связанных между собой. время.

Подобное моделирование событий еще более важно в таких играх, как League of Legends, поскольку выполнение целей и убийство ведет к как предмету, так и повышению уровня. Например, игрок, совершивший первое убийство в игре, приносит ему золото, которое можно использовать для покупки более мощных предметов. С этим предметом они становятся достаточно сильными, чтобы получить больше убийств и так далее, пока они не приведут свою команду к победе. Содействие подобному лидерству часто называют «снежным комом», поскольку игроки в совокупности получают преимущества, но часто игры не являются односторонними, а цели и командные игры более важны.

Цель этого проекта проста; можем ли мы рассчитать следующее лучшее событие с учетом того, что произошло ранее в игре, чтобы вероятность в конечном итоге привести к победе увеличилась на основе реальной статистики матча?

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

Что делает нашу модель «искусственным интеллектом»?

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

Есть два компонента, которые make выводят наш проект за рамки простой статистики в AI:

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

То, как мы определяем наш Марковский процесс принятия решений и собираем предпочтения игроков, будет определять, что наша модель изучает и, следовательно, выводит.

Предварительная обработка и создание марковского процесса принятия решения из статистики матчей

Модель искусственного интеллекта II: введение в разницу в золоте

Затем я понял из результатов наших первых попыток моделирования, что нам нечего принимать во внимание кумулятивное влияние негативных и позитивных событий на вероятность в более поздних состояниях. Другими словами, текущие вероятности MDP так же вероятны, независимо от того, опережаете вы или отстаете в данный момент времени. В игре это просто неправда; если вы отстаете, то убийства, постройки и другие цели получить намного сложнее, и мы должны это учитывать. Поэтому мы вводим разницу в золоте между командами, чтобы изменить наши состояния. Теперь мы стремимся к тому, чтобы MDP определял состояния, которые должны быть как событиями порядка, так и тем, отстает ли команда, даже или впереди по золоту. Мы разделили разницу в золоте на следующие категории:

  • Четный: разница в золоте 0–999 (в среднем 0–200 на игрока)
  • Слегка отстает / впереди: разница в 1000–2 499 золота (в среднем 200–500 на игрока).
  • Позади / Впереди: разница в 2,500–4,999 золота (в среднем 500–1000 на игрока).
  • Очень позади / впереди: разница в 5000 золотых (в среднем 1000+ на игрока)

Мы также теперь считаем, что никакие события не представляют интереса, и включаем это событие как «НЕТ», чтобы в каждую минуту приходилось хотя бы одно событие. Это событие «НЕТ» показывает, решила ли команда попробовать игру с задержкой, и помогает дифференцировать команды, которые лучше добиваются золотого преимущества в начале игры без убийств или целей (через убийства миньонов). Тем не менее, выполнение этого также значительно растягивает наши данные, поскольку теперь мы добавили 7 категорий, чтобы подогнать доступные совпадения, но если бы у нас был доступ к более обычным совпадениям, количества данных было бы достаточно. Как и раньше, мы можем описать каждый шаг следующим образом:

Предварительная обработка

  1. Импортируйте данные об убийствах, структурах, монстрах и разнице в золоте.
  2. Преобразуйте «Адрес» в функцию идентификатора.
  3. Удалите все игры со старым драконом.
  4. Начните с данных о разнице в золоте и агрегируйте их по минутам события, идентификатору матча и команде, которая выполнила событие, как и раньше.
  5. Добавьте (сложите) данные об убийствах, монстрах и структурах в конце этого, создав строку для каждого события и отсортируйте по времени, когда событие произошло (среднее для убийств).
  6. Функция добавления и «номера события», которая показывает порядок событий в каждом из матчей.
  7. Создайте объединенную функцию «Событие» с убийствами, строениями, монстрами или «НЕТ» для каждого события в строке.
  8. Преобразуйте это в одну строку для каждого матча со столбцами, теперь обозначающими каждое событие.
  9. Учитывайте только перспективу красной команды, чтобы объединить столбцы, и где усиление синего становится отрицательным приростом красного. Также добавьте продолжительность игры и результат для красной команды.
  10. Замените все пустые значения (т. Е. Игра закончилась на предыдущем шаге) результатом игры для матча, чтобы последнее событие во всех строках было результатом матча.
  11. Преобразуйте в MDP, где у нас есть P (X_t | X_t-1) для всех типов событий между каждым номером события и состоянием, определяемым разницей в золоте.

Модель v6 Псевдокод на простом английском языке

Самую окончательную версию нашей модели можно кратко описать следующим образом:

  1. Введите параметры
  2. Инициализировать состояние запуска, событие запуска и действие запуска
  3. Выбирать действия на основе либо на основании предоставленных первыми, либо случайным образом по сравнению с вероятностью их совершения, как определено в MDP.
  4. Когда действие достигает выигрыша / проигрыша, завершайте эпизод.
  5. Отслеживайте действия, предпринятые в эпизоде, и конечный результат (победа / поражение)
  6. Обновить значение предпринятых действий на основе окончательного результата с помощью правила обновления
  7. Повторить для x серий

Представляем предпочтения с наградами

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

В нашем первом примере мы показываем, что произойдет, если мы положительно оценим действие, а затем, во втором, если мы оценим действие отрицательно.

Более реалистичные предпочтения игроков

Итак, давайте попробуем приблизительно смоделировать реальные предпочтения игрока. В этом случае я случайным образом распределил некоторые награды, чтобы следовать двум правилам:

  1. Игрок не хочет отказываться от целей
  2. Игрок отдает предпочтение достижению целей, а не убийствам.

Следовательно, наша награда за убийства и потерю объектов составляет минимум -0,05, тогда как другие действия рандомизированы между -0,05 и 0,05.

Заключение и сбор отзывов игроков о наградах

Я сильно упростил некоторые функции (например, «убийства», не отображающие фактическое количество убийств), и данные, вероятно, не соответствуют нормальным совпадениям. Однако я надеюсь, что это наглядно демонстрирует интересную концепцию и побуждает начать обсуждение того, как ее можно развить дальше.

Во-первых, я перечислю основные улучшения, которые необходимо сделать, прежде чем это станет жизнеспособным для реализации:

  1. Рассчитайте MDP, используя больше данных, которые представляют всю популяцию игроков, а не только соревновательные матчи.
  2. Повысьте эффективность модели, чтобы она могла рассчитывать за более приемлемое время. Монте-Карло известен тем, что требует много времени, поэтому следует изучить более эффективные по времени алгоритмы.
  3. Примените более продвинутую оптимизацию параметров для дальнейшего улучшения результатов.
  4. Прототип обратной связи с игроком и отображение на карту для более реалистичного сигнала награды.

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

Это становится все более и более сложным, и я не буду здесь останавливаться на достигнутом, но, короче говоря, мы хотели бы сопоставить процесс принятия решения игроком, при котором оптимальное следующее решение зависит от того, что только что произошло. Например, если команда убивает всех игроков вражеской команды, они могут нажать, чтобы получить Барона. Наша модель уже учитывает вероятность событий, происходящих в последовательности, поэтому мы также должны учитывать принятие решений игроком таким же образом. Эта идея взята из следующего исследования, в котором более подробно объясняется, как можно отобразить обратную связь (https://www.researchgate.net/publication/259624959_DJ-MC_A_Reinforcement-Learning_Agent_for_Music_Playlist_Recommendation).

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

Конечно, такая идея может вызвать затруднения из-за несогласия товарищей по команде и, возможно, исключить из игры элемент, который сделает ее захватывающей. Но я думаю, что что-то подобное могло бы принести большую пользу игрокам с более низким или нормальным уровнем навыков, когда принятие решений между игроками трудно четко передать. Это также может помочь выявить игроков, которые являются `` токсичными '' своими действиями, поскольку команды будут стремиться согласовать игру с помощью системы голосования, и тогда можно будет увидеть, постоянно ли токсичный игрок игнорирует своих товарищей по команде своими движениями вместо того, чтобы следовать согласованному планы.