My actual Project, I think.

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m (Chug)
(Edit this Mofo!)
Line 111: Line 111:
 
== The long and the (very) short of it ==
 
== The long and the (very) short of it ==
 
Damn. I have run out of time to come anywhere near complete with this design. To that end I shall abandon any attempts at working code and leave the design diagram as it is below. It is still very much incomplete and lacks still lacks a great many things.<br>
 
Damn. I have run out of time to come anywhere near complete with this design. To that end I shall abandon any attempts at working code and leave the design diagram as it is below. It is still very much incomplete and lacks still lacks a great many things.<br>
[[Image:Iteration_1.6.jpeg|centre|'''Partial attempt 2''']]
+
[[Image:Iteration_1.6.jpeg|centre|'''Partial attempt 3''']]
 
<br>
 
<br>
 
===Class tour===
 
===Class tour===
Line 129: Line 129:
 
'''Shuffle()'''
 
'''Shuffle()'''
 
I realise that if I am disposing of the deck after each game then I really don't need the independent shuffle method, just randomize the deck on creation. This would however affect extensibility, as only games that required a shuffled deck could immediately use it. This is only a minor issue though and if I was continuing further I would remove the shuffle command for simplicity.
 
I realise that if I am disposing of the deck after each game then I really don't need the independent shuffle method, just randomize the deck on creation. This would however affect extensibility, as only games that required a shuffled deck could immediately use it. This is only a minor issue though and if I was continuing further I would remove the shuffle command for simplicity.
 +
 +
'''K&B Decorator'''. This refers to the previously noted decorator pattern applied to the K&BPlayer class to add in the behaviour of either the King or Bastard classes at runtime. There are several things wrong with the design as it stands. There is the lazy class smell in the basicKbPlayer. This can be fixed however, as I have broken the principle of having a lightweight abstract class in a decorator. Still, the object is vulnerable to being decorated multiple times and by the same subclass more than once, which clearly breaks the model that the player may be a King or a Bastard or neither at anytime. Two potential fixes have been brought to light: Decorate the basicKbPlayer, rather than the abstract super class. While that would work and provide a limit of one level of decoration, it does leave the abstract superclass just hanging around with little reason to exist. The alternative is: do away with the basicKbPlayer and just decorate K&BPlayer directly. That should work, (I haven't actually tried it) but then it is almost a composite pattern anyway, which is not completely suitable since it doesn't contain instances of itself. <br>
 +
 +
[[Image:KbStrat.jpeg|centre|'''K&B Player strategy option''']]

Revision as of 02:41, 5 October 2009

Ok, time to get this off the ground for real.

Since someone did my first choice of project, poker, last year I am going to attempt to combine at least one other non-poker game with poker. I will probably use a fair bit of last years design: Poker Simulator Design Log by Elliot Fisher. The first game I shall try to integrate will be 'Kings and Bastards'. You may know this be another name as there are many variations. It is quite different to poker, as it is a card shedding game rather than a bidding and pattern matching game. Should this prove overly simply (can't see that being the case, but you never know) I will add another game to the mix, possibly Gin Rummy. I also intend to feature wildcards, including jokers, just as soon as I can adequately fix the joker problem.



Contents

Game Rules

Kings & Bastards

Objective:

Dispose of all of one's cards as soon as possible and gain the title of King.

This game is for 4-6 players, using a single deck. For higher numbers of players, extra decks are added as appropriate. I am not likely to implement that feature though.

Deck:

The deck ranks like this: 3,4,5,6,7,8,9,10,Jack,Queen,King and Ace is the highest card. The 2 card is a trump card. It plays as a single card and trumps (wins) any trick/play that has not already been trumped. It trumps single cards and sets alike. The joker functions as a single wildcard and can represent any card except the 2. It can not represent a whole set of cards, but can play as a single card in a set. Suits have no effect in this version.

Sets:

Cards can be played in singles, pairs, triples and quads. Any single/set can only be beaten by a another single/set of higher rank and the same quantity of cards. For example: a single 7 beats a single 6, but cannot be played on a pair of 6's. Similarly, triple Kings cannot be played on a pair of 4s' but beats a triple of Jacks.

Basics of Play:

For the first round a dealer is chosen and that player deals out all the cards in a clockwise direction, one at a time, starting on their left. Some players may end up with 1 less card than others, this isn't a huge problem in this game.

The player with the 3 of clubs begins with this card as a single or part of a set, placing this card/set on the table to begin the trick. Play proceeds in a clockwise direction, each player attempts to beat the last played card/set with one of a higher value (never equal) or they can choose to trump with a 2 and immediately win that trick. If a player either cannot play a card/set or chooses to skip that turn (eg: to hang onto a set or trump) then they 'pass' and do not play again until their turn comes back around.

If no other players can beat a trick/play then the player who played the last cards in the trick (ie the cards that cannot be beaten) wins that trick and starts the next one. If that player has disposed of all their cards then the next player to their left starts the next trick.

Victory:

The first player to dispose of all their cards wins the title of King and the round. They now wait out of play until all the other players dispose of their cards. The last player left gains the title of Bastard and becomes the dealer for the next round. At the start of each subsequent round the Bastard must exchange their two highest ranked cards with any two cards of the King's choice from the King's hand, before play begins.

The game has no specific end point, the rounds can be repeated as many times as desired. I will implement a scoring mechanism to record a player's number of rounds as King, but I will not add any particular limit to the number of rounds, that is something the actual players should agree on.



Poker: 5 Card Draw, No limit

Objective:

Win as much money from the other players as possible.

This game is for 4-8 players, using a single deck. For higher numbers of players, extra decks are added as appropriate. I am still not likely to implement that feature.

Deck:

The deck ranks like this: Ace,2,3,4,5,6,7,8,9,10,Jack,Queen,King and Ace again. Ace plays high and low. The joker functions as a wildcard and can represent any other card as required.

Basics of Play:

A player maybe chosen as the dealer or an individual not playing may deal.

Before any cards are dealt the Ante is set and collected. This is just a small amount of money/chips collected from each player that is used to start the Pot.

Cards are dealt clockwise from the dealer's left. Players get 5 cards each.

The first betting stage commences with the player to the dealers left. This is no limit poker so there is no cap on the value of the bets or Pot. The first player can 'bet' (into the pot) or 'fold' (decide their hand is too rubbish to play) (there is no 'checking' in this version). The next player can 'call' (place the same bet as the first player), 'fold' or 'raise' (place the same bet as the first plus another bet on top of that). This stage continues in that fashion until the bet against has been called and all players (that haven't folded) have had the same number of turns.

Provided not less than 2 players remain, the game moves to the Draw stage, where players may try to improve their hand by exchanging up to 3 cards with the remaining deck.

Next another betting stage begins, behaving in exactly the same manner as the first. Players bet, raise or fold until all but one have folded, or the bet against has been called, or all players have gone 'all in' (bet all their remaining money/chips).

Once the betting stage concludes all players reveal their hands, with the best hand winning everything in the Pot. This sequence can repeat until all players except one have run out of money/chips (bankrupt). In my version I intend to just declare the player with the most money/chips to be the overall winner when a game is stopped.

Victory:

Is achieved by forcing all other players to fold or by having the best (highest ranked) hand of cards at the table. See: [1] for a list of poker hands and their arrangement.


BEHOLD, THE HORROR:

This is a partial diagram, showing not a hell of a lot really. A certain individual shot this one down like an Airliner approaching a tall building. The main thing I had going on in this was that each player would advise the next player when it was their turn, a kind of chain of responsibility, but not really. The person advised using a more central class or classes to encapsulate the turn based behaviour away from the players. Grudgingly, I must agree.

Partial attempt


Yet another (large) incomplete diagram, much further along than the last one though:

Partial attempt 2

I think I have most of the elements now, though there is much in the way of connections, fields and methods missing. Card will probably use the card design piece that I had been toying with on the previous page. WildCard is something I intend to implement, but I can't figure out how to bolt it in yet.

Problem: Decorator used for K&bPlayer. Decorator seems appropriate, since during a Kings and Bastards game a player can be awarded the King or Bastard title, as well as being neither. However, using the decorator pattern straight from the wiki results in a lazy class, BasicKbPlayer. It adds nothing that the abstract does not already have. The King/bastard behaviour could be implemented with bvooleans, but then some other class has to manage that responsibility, which seems incorrect. A player, if King should have the responsibility of exchanging cards with the Bastard, in some manner. Other patterns like strategy don't fit outright. Since strategy works for methods that change their behaviour, the KbPlayer would end up with a no-op override when they are not the King or Bastard. I will leave this alone for now unless another solution presents itself.

Problem: God class in the form of Game and it's subclasses. This class currently ties most of the show together, and it is only going to get larger. I am not sure just how I can shed some of it's responsibilities without causing a sharp increase in coupling between other classes.

Problem: Dealer subclasses. The only significant difference between a dealer in Poker and in K&B is that one deals only 5 cards per player and the other distributes the entire deck. Hence the override of dealCards(). I am not sure this is sufficiently different to warrant the subclasses. This could be handled during initialisation, but doesn't seem OO like.

Problem: There seems to be some potential to pull out the "Stages" from the Game subclasses, making them in to some sort of strategy perhaps. This would allow customisation of the game sequences and rules.

Problem: The "Play" class. It is intended to be a wrapper for a Set of cards as played during K&B, a sort of 'playable unit'. However, I can't see any specific behaviour it could encapsulate so I may abandon it.

Problem: Lack of factories. There are classes that could use factories for construction, such as player, card (maybe), Dealer.

Problem: Ranking the poker hands. This has been causing me some grief, I am damned if I know how to make this work nicely.

Problem: I am not identifying the King and Bastard in a positive fashion. This failure could support using a boolean field to provide id of the condition, which in turn may eliminate/alter the need for a wrapper for the King or Bastard behaviour.


The long and the (very) short of it

Damn. I have run out of time to come anywhere near complete with this design. To that end I shall abandon any attempts at working code and leave the design diagram as it is below. It is still very much incomplete and lacks still lacks a great many things.

Partial attempt 3


Class tour

Game and Subclasses

This class is abstract and is supposed to contain methods and fields that are common to both Poker and Kings and Bastards. It's responsibilities (when instantiated through one of it's subclasses) are:

  • Instantiate and maintain the specific dealer object for the game type (Poker or K&B).
  • Instantiate and hold a list of all players in the game.
  • Maintain a reference to the current player who's turn it is.
  • Track the round number.
  • Determine the round and overall winners.

It also has methods to start off the game, end it, continue (when possible) after a player has completed some sort of action. The nextRound method is essentially a reset for most of the games mechanics like the deck, which rather than gather all cards back to it at the end of game is simply dumped and a new deck created. See my comment about shuffle().


Broken Stuff and Improvements

Shuffle() I realise that if I am disposing of the deck after each game then I really don't need the independent shuffle method, just randomize the deck on creation. This would however affect extensibility, as only games that required a shuffled deck could immediately use it. This is only a minor issue though and if I was continuing further I would remove the shuffle command for simplicity.

K&B Decorator. This refers to the previously noted decorator pattern applied to the K&BPlayer class to add in the behaviour of either the King or Bastard classes at runtime. There are several things wrong with the design as it stands. There is the lazy class smell in the basicKbPlayer. This can be fixed however, as I have broken the principle of having a lightweight abstract class in a decorator. Still, the object is vulnerable to being decorated multiple times and by the same subclass more than once, which clearly breaks the model that the player may be a King or a Bastard or neither at anytime. Two potential fixes have been brought to light: Decorate the basicKbPlayer, rather than the abstract super class. While that would work and provide a limit of one level of decoration, it does leave the abstract superclass just hanging around with little reason to exist. The alternative is: do away with the basicKbPlayer and just decorate K&BPlayer directly. That should work, (I haven't actually tried it) but then it is almost a composite pattern anyway, which is not completely suitable since it doesn't contain instances of itself.

K&B Player strategy option
Personal tools