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

Question

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

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

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

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

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

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

Answer 1

Есть несколько «правильных» ООП-схем для этого, в зависимости от того, как вы хотите смоделировать игровой процесс и от ИИ игрового агента

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

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

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

Answer 2

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

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

Поведения ИИ рассматриваются как часть карт.Еще одно свойство, которое имеют карты, которое можно взвесить вместе со стоимостью.

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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