Best location for Game Multipliers

Developers
mjluzius
2011-06-14
2012-07-08
  • mjluzius
    mjluzius
    2011-06-14

    Where should the game multipliers be located? These methods should be public
    and only dependent on a list of cards and a rule set. There shouldn't be a
    dependency on a complete SkatGame.

    They could be moved either to CardList:

    getJackMultiplier()
    

    --> from SuitGrandRules

    getBaseMultiplier(AbstractSkatRules rules)
    

    --> from various dependents of AbstractSkatRules

    Or they could still be part of the AbstractSkatRules subclasses, but then with
    a different signature and (possibly?) as part of the BasicSkatRules interface:

    SuitGrandRules.getJackMultiplier(CardList list)
    
    BasicSkatRules.getBaseMultiplier(CardList list)
    

    --> from various dependents of AbstractSkatRules

    Ramsch or null games would return 0 as their multiplier.

     
  • Jan Schäfer
    Jan Schäfer
    2011-06-15

    Sure we can reduce the methods for finding multipliers to a card list. The
    card list must contain the declarers hand and the skat cards to calculate the
    multipliers correctly.

    I've read the international skat order again on the weekend and found out that
    there is a destinction between multipliers and win levels (see chapter 5 for
    details).

    I would get rid of getJackMultiplier() and getBaseMultiplier() and rather have
    two methods getMultiplier(CardList) and getWinLevels(SkatGameData) for each
    game type. GetWinLevels() can be implemented in AbstractSkatRules because it's
    always the same. GetMultiplier() must be implemented in each rule class.

     
  • mjluzius
    mjluzius
    2011-06-15

    Hmmmm. The new method signatures seem to solve my problem concerning the ai
    player. In addition, it seems to be clearer about the source of the points. In
    theory, ai players might want to bid in such a high range. For practical
    puposes, your suggestion should be sufficient.

    I'll take a look if I can do it this way without to many changes in dependent
    classes.