Estructura correcta de OOP para un jugador de Dominion AI

Question

He estado tratando de hacer un reproductor de IA para el popular juego de cartas, Dominion (http://www.boardgamegeek.com/boardgame/36218/dominion).

Si no está familiarizado con el juego, básicamente es un primo muy simplificado de Magic: The Gathering, donde hay una gran biblioteca de cartas con diferentes reglas sobre ellas. En el transcurso de un juego, los jugadores compran estas cartas y las incorporan a su mazo.

Me interesa este juego desde una perspectiva de aprendizaje automático: quiero enfrentar a bots entre sí, hacer que jueguen millones de juegos y tratar de extraer información que los haga jugar mejor.

No estoy seguro de cómo separar las reglas del juego (las instrucciones literales impresas en cada carta) de la lógica central de toma de decisiones de AI.

El camino obvio que he comenzado es crear una clase para cada tarjeta, y poner ambas reglas y cosas de AI en el mismo lugar. Esto es algo asqueroso, pero parece ser el camino de menor resistencia. Pero tal vez sea mejor que cada tarjeta admita algún tipo de interfaz y luego tenga un código de componentes AI contra estas.

¿Hay un diseño OOP "correcto" para esto? O varias posibilidades razonables?

Answer 1

Me inclino por encapsular el comportamiento de una tarjeta como su propia clase, lo que permite fácilmente tarjetas que tienen múltiples comportamientos (es decir, elecciones). También le permitirá escribir comportamientos parametrizables y mezclarlos y combinarlos con tarjetas.

Las tarjetas contendrían cosas como el costo de la tarjeta, cuándo se puede jugar, su nombre, etc. También contendría una lista de comportamientos que la tarjeta puede hacer.

Los comportamientos son vistos por los actores de IA como parte de las cartas. Solo otra propiedad de las tarjetas que puede pesarse junto con el costo.

La IA agente que es en realidad usando comportamiento el de la tarjeta tiene que ser capaz de interpretar los comportamientos, por lo que la clase del comportamiento podrían necesitan contener algunos consejos para la AI para entenderlo, pero ninguna lógica real de AI en sí deben ser contenido allí. Si las IA necesitan comportamientos específicos para cartas específicas, escribe ese tipo de cosas en el actor de IA, no el comportamiento de la tarjeta.

Si un actor de IA necesita saber que, por ejemplo, este comportamiento tiene un beneficio esperado de puntos de victoria de .2 puntos/ronda, eso podría ser una parte del comportamiento que actúa como una pista para la IA al elegir qué tarjetas para comprar/jugar.

Pero realmente no sé cómo te estás acercando al diseño de tu actor de IA, quizás esto no tenga sentido. Pero creo que pensar en el comportamiento como una propiedad de las cartas en lugar de una parte fundamental de las cartas en sí mismas podría ayudar.

Te ofrece la ventaja de encapsular las acciones predeterminadas de los actores AI (cosas que los actores pueden hacer sin necesidad de cartas) como comportamientos, para poder comparar esas acciones contra tarjetas sin ningún código de caso especial.

Answer 2

No estoy familiarizado con todas las variaciones de las tarjetas en Dominion, pero la idea de escribir una clase para cada una de ellas parece engorrosa. Lo ideal sería crear una clase de tarjeta general que encapsulara todas las variaciones de instrucciones en la tarjeta, y luego cargar los valores particulares para una carta dada en esa clase general.

Imagino que una clase que contiene conjuntos de poderes y restricciones podría ser una buena representación general. Algo así como:

• necesario de los recursos de juego para el juego
• Estado donde el juego está prohibido
• tipos de daño/valor
• salud/maná cambia
• Efectos sobre otras tarjetas (quizá un diccionario de la tarjeta ids y efectos)
• etc ...

Answer 3

he estado pensando acerca la lógica para una versión de Dominion que no es de IA, y todavía es un desastre averiguarlo.

Casi debe tener una clase para cada mazo de cartas y una interfaz para cada tipo de carta, teniendo en cuenta que las cartas pueden tener varios tipos (como Great Hall, que es a la vez Acción y Victoria).

Actualmente, todas las cartas de Ataque también son Acciones, por lo que es posible que desee realizar la acción de la subclase de la interfaz de Ataque. Para la mayoría de las cartas, la Acción simplemente llama al método de Ataque. Sin embargo, hay algunas cartas donde esto debería ser diferente, como Minion, donde tienes la opción de atacar o no.

Las cartas de reacción también son Acciones, pero también necesitarán un manejo especial, ya que pueden revelarse durante el turno de un oponente en respuesta a una carta de Ataque. A partir de Prosperity, también pueden revelarse en respuesta a otras cosas que no sean ataques ... Watchtower se puede revelar en cualquier momento en que ganarías una carta.

tarjetas Duración (lo que me he perdido en mi lista de 7 tipos de tarjetas anterior) son acciones que se quedan en juego para un turno extra ... y también cuentan para el coste de compra del vendedor ambulante en la prosperidad.

Editar: Vaya, no aborde el problema de la IA aquí ... probablemente porque mi propio desarrollo se había dirigido más a una versión de red para varios jugadores.

Answer 4

hay varios diseños "correctas" programación orientada a objetos para esto, dependiendo de cómo se desea modelar el proceso del juego y la IA del juego-juego-agente

personalmente, me gustaría tener el número mínimo de tarjetas de una ronda válida en el juego e implementarlas como instancias de una clase de Tarjeta e implementar los jugadores como instancias de una clase Agente e implementar algunas estrategias de juego simples como instancias de una clase de Estrategia (patrón), y luego ver lo que sucede

ejecutar a través de algunos t ests, tiene un jugador totalmente aleatorio como un florete, mira operadores de ganancia/pérdida a corto plazo máx/mín, intenta mutar las estrategias del agente usando un algoritmo genético, descarga un clasificador XCS y ve si es útil derivar estrategias ...

... la noción de un modelo correcto depende en gran medida de cómo se utilizará. Una vez que comprenda cómo necesita usar los elementos del juego y modelar/manipular las estrategias/tácticas del jugador, sabrá cuál es la estructura 'correcta' para su solución