Escribo un póker en C# y no me gusta el diseño que tengo actualmente. Mi objetivo es tener un motor de juego que pueda jugar múltiples agentes de IA uno contra el otro en modo por lotes muy rápidamente, y jugar múltiples agentes de IA contra múltiples humanos (probablemente a través de un cliente de Silverlight). Me gustaría mantener la eficiencia alta pero mantener la flexibilidad, por ejemplo, debería poder jugar juegos como Limit Hold'em, No-Limit Hold'em, Límite de 7 cartas Stud, etc.A Better C# Poker Framework Design?
Mi diseño actual es más bien torpe e inflexible:
- HandHistory: contiene toda la información sobre la mano actual (jugadores en, las apuestas realizadas, etc.)
- iPlayer: Cada jugador define un método getAction (historia HandHistory).
- GameEngine: define un método Play (HandInfo info) que devuelve un objeto HandHistory.
- PotManager: Administra el pozo y determina cuánto debe igualar cada jugador y cuánto puede ganar (por ejemplo, si tienen stacks desiguales y están all-in).
- BetManager: Administra las apuestas y determina cuándo termina una ronda de apuestas.
La clase HandInfo contiene toda la información sobre cómo configurar la mano. El método de reproducción a continuación, se ve algo como esto:
HandHistory Play(HandInfo info)
{
PotManager pots = new PotManager(info);
BetManager bets = new BetManager(info);
HandHistory history = CreateHistory(info);
bets.CollectBlinds();
if(!bets.GameOver)
{
DealHoleCards();
if(bets.PlayersThatCanStillBet > 1)
bets.CollectBets();
if(!bets.GameOver)
{
DealFlop();
... and on and on
}
}
return history;
}
Los problemas surgen porque hay tantas pequeñas cosas a considerar como la recogida de las persianas, etc. Las clases de administrador Pot y la apuesta se convierten en una pesadilla y son invariablemente plagados de errores . Además, el diseño de mi motor solo admite un tipo de juego (Hold'em) en comparación con otros.
Mi clasificación principal es la primera por eficiencia, ya que el motor se usa principalmente como un simulador de AI sobre miles de millones de manos. Sin embargo, me gustaría pensar que hay una forma más elegante de hacerlo.
Además de la publicación de @ Lachlan, sugeriría la optimización por falta de redundancia. –
Estoy de acuerdo con "primero haz que funcione, luego hazlo rápido" en general. Sin embargo, si el rendimiento es una parte importante (como en muchas simulaciones), generalmente es útil hacer algunas estimaciones (¿qué se necesitará con qué frecuencia?) Y quizás escribir un prototipo para obtener una primera estimación sobre el tiempo que tardan algunas cosas. Porque a veces se escucha un buen diseño OO para obtener REALMENTE rápido. Y, me temo, a veces necesitas exactamente esto. ¡Pero por favor verifique si este es realmente el caso para usted! – Philipp