a) In each game there is a sequence of 1 or more hands: with "Hand" i mean a procedure starting with shuffling/dealing cards.
- if it true?
b) before starting playing the first hand some game could need other operations:
- choice of player partnership / disposition
- choice of first shuffler/dealer.
HandPlay
If the statement before is really true, than we have to better define the "HandPlay".
a) cyclic condition
- some game need hands to be played until the end condition is reached.
- some game need only 1 hands to be finished.
- some game could need a fixed number of hands: is it possible?
b) handplay will be in turn defined as a sequence of procedures that each game can customize. I'll put in round brackets procedures that are not important in the computer game simulation.:
- (choice of the shuffler)
- (shuffling procedure)
- (deck cutting procedure)
- (choice of the dealer)
- Dealing
- Choice of the leader
- Bidding
- Choice of the Trump
- TrickPlay
TrickPlay
TrickPlay is a sort of HandPlay: it will cycle until a given condition is reached.
a) cyclic condition:
- until all hands are empty
- until the end condition for the "parent" hand is reached
- other possible conditions?
b) trick procedure list:
- Drawing (get a card/more cards from the deck)
- CardPlay (one or more, following a given rule)
- so on...
- TrickResolution (some gome need that cards played are moved somewhere: woncards, opponent hand, winner hand... )
We can simplify this saying that a Procedure follow the "Composite" pattern: A Procedure can do something itself, or being a SequenceOfProcedures (do each procedure one at a time) or being a LoopingProcedure (loop until a given condition is reached). This semplification result in too much lowleveling: direct java code would be simpler... so we will provide many high level parametrizable procedures.
We should try to define what "standard procedures" to provide and how much game they will serve.
By now I see:
- Dealing
- HandPlay
- TrumpChoice
- Bidding
- Passing (givin cards to other players)
- TrickPlay
- PlayCard/s (could be generalized in a card movement between card containers)
- TrickResolver
I need to find a way to show this "schematization" for some real card game.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
CardGame Life
a) In each game there is a sequence of 1 or more hands: with "Hand" i mean a procedure starting with shuffling/dealing cards.
- if it true?
b) before starting playing the first hand some game could need other operations:
- choice of player partnership / disposition
- choice of first shuffler/dealer.
HandPlay
If the statement before is really true, than we have to better define the "HandPlay".
a) cyclic condition
- some game need hands to be played until the end condition is reached.
- some game need only 1 hands to be finished.
- some game could need a fixed number of hands: is it possible?
b) handplay will be in turn defined as a sequence of procedures that each game can customize. I'll put in round brackets procedures that are not important in the computer game simulation.:
- (choice of the shuffler)
- (shuffling procedure)
- (deck cutting procedure)
- (choice of the dealer)
- Dealing
- Choice of the leader
- Bidding
- Choice of the Trump
- TrickPlay
TrickPlay
TrickPlay is a sort of HandPlay: it will cycle until a given condition is reached.
a) cyclic condition:
- until all hands are empty
- until the end condition for the "parent" hand is reached
- other possible conditions?
b) trick procedure list:
- Drawing (get a card/more cards from the deck)
- CardPlay (one or more, following a given rule)
- so on...
- TrickResolution (some gome need that cards played are moved somewhere: woncards, opponent hand, winner hand... )
We can simplify this saying that a Procedure follow the "Composite" pattern: A Procedure can do something itself, or being a SequenceOfProcedures (do each procedure one at a time) or being a LoopingProcedure (loop until a given condition is reached). This semplification result in too much lowleveling: direct java code would be simpler... so we will provide many high level parametrizable procedures.
We should try to define what "standard procedures" to provide and how much game they will serve.
By now I see:
- Dealing
- HandPlay
- TrumpChoice
- Bidding
- Passing (givin cards to other players)
- TrickPlay
- PlayCard/s (could be generalized in a card movement between card containers)
- TrickResolver
I need to find a way to show this "schematization" for some real card game.