Правильная структура ООП для игрока AI Dominion

Я тренировался, пытаясь сделать AI-плеер для популярной карточной игры, Dominion (http://www.boardgamegeek.com/boardgame/36218/dominion).

Если вы не знакомы с игрой, это в основном очень оптимизированный кузен Magic: The Gathering, где есть большая библиотека карт с разными правилами. В течение игры игроки покупают эти карты и включают их в свою колоду.

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

Я не уверен, как отделить правила игры (стенографические инструкции, напечатанные на каждой карте) от основной логики принятия решений AI.

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

Есть ли для этого "правильный" проект ООП? Или несколько разумных возможностей?

Ответ 1

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

Таким образом, карты будут содержать такие вещи, как стоимость карты, когда она может быть воспроизведена, ее имя и т.д. Он также будет содержать список действий, которые может делать карта.

Поведение проявляется актерами AI как часть карт. Просто еще одно свойство, которое карты могут быть взвешены вместе со стоимостью.

Актер AI, который фактически использует поведение карты, должен уметь интерпретировать поведение, поэтому классу поведения может потребоваться содержать некоторые намеки для ИИ, чтобы понять это, но в нем не должно содержаться сама логика ИИ. Если ИИ нуждаются в конкретном поведении для определенных карточек, напишите это в актерском искусстве, а не в поведении карты.

Если персонаж AI должен знать, что, например, это поведение имеет ожидаемый выигрыш в выигрыше в 0,2 балла/раунд, это может быть частью поведения, которое действует как подсказка к ИИ при выборе карт покупать/играть.

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

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

Ответ 2

для этого существует несколько "правильных" схем ООП, в зависимости от того, как вы хотите смоделировать игровой процесс и игровой агент AI

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

пройдите через некоторые тесты, у вас есть абсолютно случайный игрок в качестве фольги, посмотрите на краткосрочные операторы увеличения/потери макс/мин, попробуйте изменить стратегии агента с использованием генетического алгоритма, загрузить классификатор XCS и посмотреть, полезен ли он для выработки стратегий...

... понятие правильной модели сильно зависит от того, как она будет использоваться. Как только вы поймете, как вам нужно использовать элементы игры и моделировать/манипулировать стратегиями/тактикой игрока, тогда вы будете знать, какая "правильная" структура для вашего решения

Ответ 3

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

Я могу представить, что класс, содержащий множества степеней и ограничений, может быть хорошим общим представлением. Что-то вроде:

Требуется в игровых ресурсах для воспроизведения.
Состояние, в котором игра запрещена.
Типы/значение повреждений
Изменения состояния здоровья/маны
Эффекты на других картах (возможно, словарь идентификаторов и эффектов карты)
и т.д...

Ответ 4

Я размышлял о логике для версии, отличной от AI, и все еще беспорядок, чтобы понять.

У вас почти должен быть класс для каждой колоды карт и интерфейс для каждого типа карты, имея в виду, что карты могут иметь несколько типов (например, Большой зал, который является одновременно действием и победой).

В настоящее время все карты Attack также являются действиями, поэтому вы можете сделать действие подкласса интерфейса Attack. Для большинства карт Action просто вызовет метод Attack. Тем не менее, есть несколько карт, где это должно быть разным, например, для Minion, где у вас есть выбор, нападать или нет.

Реакционные карты также являются действиями, но также нуждаются в специальной обработке, поскольку они могут быть обнаружены во время поворота противника в ответ на карту атаки. Что касается процветания, они также могут быть раскрыты в ответ на другие вещи, кроме атак... Сторожевая башня может быть обнаружена в любое время, когда вы получите карту.

Карты продолжительности (которые я пропустил в моем списке из 7 типов карт ранее) - это действия, которые остаются в игре за дополнительный оборот... и также рассчитывают на стоимость покупки Peddler в Prosperity.

Изменить: Упс, я вообще не рассматривал проблему с ИИ... вероятно, потому, что моя собственная разработка была нацелена больше на сетевую сетевую версию.