Re: AW: [Gameframe-apis] Some Rules API-thoughts

[Magnus L. <io...@ne...>]

On Tue, 21 Jan 2003, Patrick Carl wrote:

> Hi Magnus, hi gameframe ;)
>
> I like your ideas. Currently there exists a GameRule interface which
> represents the rule of a game. The processing of moves is done by
> GameState/GameTable, not to an interface Game. As you will notice, there
> is no interface Game yet in gameframe. The reason, as I remember, was
> the danger of mixing up what is meant with Game and prefering to split a
> Game in smaller pieces.
>
No problem, the Game interface was just my notion for a Game in progress -
that which keeps track of the state of the game, the players etc etc. It
could be called something else or be a combination of objects.

> But your idea of an RuleBook sounds good to me. A GameState could use a
> RuleBook instead of a GameRule. One question to the people knowing about
> game creation: Can the rules of every game (or every game we want to
> offer a framework for) be presented as a RuleBook and therefore be an
> ordered collection of Rules which are processed sequentially? I think it
> should be possible as long as every rule is atomic, meaning that it
> doesn't have influence on a former processed rule or it isn't influenced
> by a latter one.
>

If I would answer this I would say NO. You cannot just process them
sequentially. The Condition interface togther with the overrideRule
method in RuleBook are intended to add a level of flexibility over
simple "check that all rules are fullfilled".

My intention is for the overrideRule method to be used when for instance
Player that ownes a specific card can break certain ground rules as in
Cosmic Encounter or Ursuppe. The rule for the card overrides the
normal rule. When getRules() for a player is called then the Condition for
the card rule will check for the existance of the card in that players
hand. If it is there then the normal rule will not be returned in the
array only the card specific rule (together with all other rules that
applies to that move).
The implementation has to take of the problem with several Rules
overriding the same basic rule. Then the basic rule should only be
returned if none of the overriding rules are applicable.

Just so that you understand my idea: the getRules() method will
return different Rule arrays with each call depending on the Move
and the current GameState. It is a "dictionary call" checking which
rules that applies to a specific condition in the game. So that
when moving a Rook in chess the array could include the following
rules:

* PlayersTurnToMoveRule
* RookMovementRule
* SquareNotOccupiedByOwnPiece
* PlayerNotInCheckAfterMoveRule
* OpponentInCheckAfterMoveRule (only updates GameState)
* OpponentMateRule (only updates GameState)

As I have been seeing it the Move itself should also update the GameState,
but I guess that is just a matter of reference. You just as well have a
Rule that actually inspects the Move and makes the appropriate changes to
the GameState.

Splitting the rules into a Rule and a Condition when the Rule applies will
hopefully increase the reuse within a game. It will also make it possible
for a basic implementation of the RuleBook to be included in framework.

I think that the more the atomic rules are the better. I think we write
basic Rules for turn order, card play, payment etc, that can be reused in
many games. If we also supply a number of basic Conditions then a skeleton
of rules will be easy to set up. It would also be fairly simple to include
a XML format where you can describe the rules for a game.



> > interface RuleBook {
> >   /**
> >    * Checks all rules that applies to the move and current game state
> >    * sorts them and returns them.
> >    */
> >   Rule[] getRules(Move m, GameState gs);
> >   void addRule(Rule r);
> >
> >   /**
> >    * Overrides an old Rule with a new one.
> >    * If the Condition for the new Rule is met then only that Rule
> >    * will be checked. If the old Rule's Condition is met and the
> >    * not the newVersion's, then the old rule is checked.
> >    *
> >    */
> >   void overrideRule(Rule toOverride, Rule newVersion);
> >
> > }
> >

--

Magnus Lundgren