Gestion Des Divisions Dans Java Blackjack Simulator-Récursivité?
Je crée un simulateur de blackjack pour m'enseigner java et il a déjà été très utile. C'est la dernière pièce et ensuite elle sera fonctionnelle. J'ai de la difficulté avec la gestion de la divise. Si vous ne jouez pas au blackjack, un split signifie que le joueur a la possibilité de prendre chaque carte de sa main initiale et de créer une nouvelle main pour chacune.
Actuellement, il y a une classe de cartes, et un deck qui est une arraylist de cartes. Il y a aussi une classe player qui a un objet appelé main, aussi un tableau de cartes. Le joueur a une variable appelée bet qui est le montant à parier sur chaque main.
Le problème avec un split est qu'il crée une main supplémentaire et maintenant chacune de ces mains a son propre pari. Dois-je réorganiser le programme et faire de hand sa propre classe? Cela semble exagéré et cela peut très bien créer des problèmes qui lui sont propres. Par exemple, à un moment donné, le joueur va devoir gérer plusieurs mains de toute façon.
La deuxième pensée I have est de tout gérer dans la méthode de jeu, qui gère toutes les stratégies de base, récursivement. Il y a deux problèmes, un, je n'ai jamais utilisé la récursivité, et deux, il y a toujours le fait qu'il n'y a qu'un seul objet de main par personne.
La troisième idée, qui semble également désordonnée, est de créer une classe playerSplit qui étend la classe person et crée une main supplémentaire. Le problème est qu'il peut y avoir plusieurs divisions par personne dans un tour donné.
J'inclus le code I believe est pertinent car le programme est un peu long pour tout inclure. Veuillez me faire savoir s'il y a du code supplémentaire nécessaire.
Constructeur humain
public Human(String name, Deck deck){
this.handValue = 0;
this.name = name;
this.hand = new ArrayList<Card>();
this.deck = deck;
}
Constructeur de joueur (la classe de joueur étend l'humain):
public Player(String name, Deck deck, double minBet, double maxBet){
super(name, deck);
this.bankroll = 1000;
this.minBet = minBet;
this.maxBet = maxBet;
this.bet = minBet;
}
2 answers
Essayez de penser à la façon dont les différents objets interagissent dans un jeu de blackjack. Un croupier distribue des cartes aux joueurs, qui ont alors une main, ou des mains si la main a été divisée.
Dans votre constructeur Human, vous avez une liste de cartes représentant la main. Au lieu de lier cela à l'humain, vous devriez plutôt avoir une classe distincte pour une main de cartes.
Laissez la classe Hand avoir la liste des cartes, le pari qui lui est associé, et le reste des méthodes qui sont pertinentes à la main.
Dans la classe Human, ayez une arraylist qui stocke toutes les mains du joueur, quelque chose comme ceci:
ArrayList<Hand> hands;
Ont également une méthode qui peut diviser une main qui prend une main comme entrée et renvoie les nouvelles mains après la scission. Vous pourriez le faire quelque chose comme ceci:
public ArrayList<Hand> splitHand(Hand h)
Lors de la programmation d'applications comme celle-ci, vous devez tout séparer dans leur propre classe qui peut agir indépendamment les uns des autres, encapsulant leur logique. Au lieu de ta main rattaché directement au lecteur en tant que groupe de cartes, vous devez reconnaître qu'une main de cartes est un objet indépendant avec ses propres propriétés et méthodes. Il est beaucoup plus facile de programmer de cette manière. Par exemple, vérifier si une main est égale ou non à 21 peut être fait en ajoutant une méthode à la classe hand qui est appelée comme hand.getSum() ou quelque chose comme ça.
La récursivité semble inappropriée pour représenter l'état du système.
En supposant qu'un joueur a plusieurs mains, que chaque main a son propre état et doit être rendue dans l'interface graphique, il vaut mieux avoir une relation un à plusieurs entre chaque joueur et le nombre de mains jouées.
Au blackjack, un joueur peut également s'asseoir à une table et jouer plusieurs mains sur la table, donc cette relation un à plusieurs existe déjà si vous allez simuler réel de casino de style de jeu.