gameframe-apis — Mailing list for API discussions

[Gameframe-apis] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

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

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

On Thu, 30 Jan 2003, Frank Nestel wrote:

> Hi Magnus,
>
> What is my below mail? I did some "loud thinking" while reading you
> mail again. I might repeat or even contradict myself :-) In doubt,
> I have kind of a summary in the end.
>
> > > With the original source:
> > >
> > >       PlayerMove was meant to be the action of a single player.
> >
> > My Move interface was meant to have the same purpose so they are the
> > same.
>
> Hmm, I remember Patrick opted against my very long class names either,
> he
> voted for Move, State, Table instead of PlayerMove, GameState,
> GameTable.
> Somehow I apprechiate some redundance, but we could still change...
>

This is not an important. Just as long as we don't decide to change it
back and forth. Since you have started using those names we should
probably stick to them.

>
> Well, I am not sure why your formalism couldn't be able to model games
> with
> changing rules. That is the addition of rules as part of the game. Of
> course
> this had to be part or consequence of a move and theirfore be controled
> by
> appropriate conditions.

Of course you can handle changing rules with this model. I thought it
would be easier to understand the Rules state model if it was fixed. But
we can go for the changing model.

> Hmm, in natural language there is no such sharp distinction between
> class and
> instance. I thought about keeping it separate would make it easier. If
> you
> can live with my terminology I'd apprechiate it.

Sure thing.

> > The GameState would be the current situation in the game, so
> > games could if they want hold a List of GameStates which would represent
> > the history of the game (after each players Move or after each turn).
>
> Yes, the GameTable could expose a list of (historical)
> (Visible)GameState s.
> The idea of the VisibleGameState was, that in many games there is a lack
> of
> information. So the Players or Watchers can never obtain the real
> GameState,
> since the GameTable API only exposes VisibleGameState objects
> corresponding
> to both the Watcher and the GameState to be looked at.

Good idea, I probably missed the purpose of the VisibleGameState
interface.

> I wonder if visibility could be also a criteria for rules? At least
> Robert
> Abbotts "Eleusis" can be seen as a game with partially unknown rule and
> determinining the rule is part of the game. Well "Was Sticht" is a less
> exotic example. I remember I was talking about those two with Sus as a
> interesting (but less linguistic) base for her research.

I don't understand what you mean by this. The VisibleGameState is a subset
of the GameState, so the Rules could always work on the GameState and
still be able to produce the same result as if they were operating on the
VisibleGameState, no? So would this extra complexity really give any
advantage?

<- SNIP ->

> >
> > My idea was that you write rules for each of these different turn orders
> > in the framework, and the game implementations could use one of them or
> > could write its own. The turn Rule would be a rule that is always applied
> > to a move that a player wants to make. If it isn't that players turn or if that
> > player has already taken his or her turn then the move would be
> > disallowed. I can see the need for processing all moves at the same time,
> > but that would just be a matter of waiting until all players have sent
> > their moves instead of executing them on arrival.
>
> I see, this could make sense. The problem I simply "blackboxed" instead
> of
> solving was, that there might be so many different kinds of moves, that
> the GameState is another factory for the admissible moves. Generating an
> EmptyMove (hey that would be a Singleton) for Players who are not
> supposed
> to do something. I.e. for chess for one gameState instance one of
> gameState.getMove(WHITE) and gameState.getMove(BLACK) would return an
> EmptyMove.
>
> For real board games there might be very many different types of turns,
> I wonder
> if customizable rules could be joined to a customizable MoveFactory to
> work within
> the stomach of the GameState.
>
> This is not quite precise, do you see what I mean?

Yes, I think so.


> >
> > >       I think one cannot let the a single players turn do the "update" on
> > >       a GameState.
> >
> > Why? Doesn't that depend on the nature of the game. Take Zoff im Zoo,
> > after a player has decided what cards to play and created a PlayerMove for
> > that don't you want to process that move directly, updating the state of
> > the game. In your examples above wouldn't you have to include "null" moves
> > for each player?
>
> Yes, many, many null moves. Since the primary focus of gameframe was
> something
> like simultaneous "a turn a day" games this didn't look like too much of
> a
> problem. Well sometimes I sit on the table and ask "Who's turn is it"
> and either
> it is me or not. In gameframe I ask the GameTable (somewhat strange)
> what turn
> I have and when I get an EmptyMove, it wasn't my turn. Some application
> logic
> arround gameframe might care about minimizing the number of EmptyMoves
> to be
> created.
>
> > The PlayerMove would only be executed if the Rules allow it. So in my
> > point of view it is only a matter of making sure that the correct
> > TurnOrderRule has been applied before the move is exucuted.
>
> I'm undecided. As stated above I do not worry about EmptyMoves, but I
> wonder
> what a TurnOrderRule could help. Doesn't this raise the question whether
> turns
> are pushed or pulled. That is a (entirely different) gamestate could
> progress
> the message "DoSomething" actively to Player objects. Currently someone
> owning a PlayerObject has to ask, "what can I do".

The two concepts don't have to contradict each other as I see it. You will
still want an TurnOrderRule to see if a player is allowed to play even if
that player previously asked "what can I do". The "what can I do" question
would be answered with an empty list of Moves if the TurnOrderRules
decided that you cannot do anything right now.

I wanted to avoid the need to include all the EmptyMoves for the game to
finish its turn.

> >
> > >       I currently struggle with differentiating your object "Game" and
> > > "GameState".
> > >       They look like a different mixture of the original GameTable and
> > > GameState
> > >       object?! I am confused.
> >
> > Correct, they probably are a mixture of these. Forget the names that I
> > used. My GameState should be read as "object describing the current
> > situation of a game in progress"
>
> So is our GameState, where players see it encapsulated and historified
> by the GameTable.
>

Something like that yes.

> > >       I think I understand the RuleBook, RuleBook is a way to describe the
> > >       construction of complex GameRule's in term of smaller and hopefully
> > >       simpler Rule objects. This could happen at two times, either in the
> > >       customization phase (game setup) or due to certain PlayerMoves during
> > >       the game.
> >
> > Not really, my intention was for the RuleBook to be more or less static
> > once the game has started. It would be possible to change rules in a
> > RuleBook, but most games in progress could actually share the same
> > RuleBook. It would not hold any state apart from the customization, just
> > the code for all rules for a game. If a game cannot be customized then all
> > games in progress could share the same instance of a RuleBook.
>
> So you think of general building bricks for games. This is cool and much
> more ambituous than previous GameState design. I wonder if you have a
> few
> general purpose building bricks in mind and (maybe trivial but) 2
> distince
> games constructed from them?

I will try to think of some examples and send them in another mail.


<- SNIP ->

> >
> > If we are to use the RuleBook-Rule then we should probably start out by
> > discussing whether or not the RuleBook is fixed during the game or if it
> > is intended to be updated by PlayerMove-s.
> >
> > Both works I guess. I thought the RuleBook would be easier to understand
> > if it included all Rules from the begining. That is also partly why I
> > included the Condition interface so that the rules would only be found
> > when they are "active", but they are all there from the begining.
> >
> >
> > It seems I have to take some time and try to understand the intentions
> > behind the different interfaces and classes that you have written so far.
>
> I'm sorry for the poor documentation!
>

No worries.

> I see ...
>
> ... a package of general purpose rules which are useful for many
> games (i.e. a GameEndAtTurnNoRule).

Agree.

>
> ... a package of general purpose conditions which are useful for many
> games, for example a DoesRuleApplyToPlayerCondition and locical
> Conditions
> like AndCondition and OrCondition which allow the construction of
> combined
> rules.

Agree.

> ... GameRule still as the basic factory for a game.
>
> ... most real games will contain special Rule and Condition objects,
> these
> might be those parts which gaming geeks consider as original in the
> design.

Agree.

> ... a GameState which holds a pair of one GameData object which holds
> the
> mere data about the current state and one CurrentRuleCollection (I do
> not
> like the name, but I lack a better one, it sounds more like programming
> than like gaming).

Agree.

> ... Rules could possibly subclass to ExecutionRules which actually
> modify
> a GameState, to VisibilityRules which determine the creation of
> VisibleGameStates
> from a GameState. I see ValidationRules which determine whether a
> certain
> PlayerMove can be accepted and I wonder how a MoveCreationRule could
> look,
> that would be those rules which take the move creation away from the
> GameState.

I have been thinking a lot along these lines the last few days. And I
agree we want to have an hierarchy of Rules interfaces for different
purposes.

Now that I have understood the concept of generating the legal moves for
a player I can see that this has several advantages. I guess that you
would have to let all MoveCreationRules do their work and then apply
all ValidationRules the result of what they created so that the
MoveCreationRules doesn't have to bother about checking everything
themselves.

> ... maybe a XML Scheme which actually allows games to be configured
> rather
> than programmed. At least games which do not contain "original"
> inventions.

Agree, but I guess this would have a rather low priority. It can be added
later.

> ... GameCustomizer as pretty unclear. It somehow has to be a bean which
> takes values to determine the usage of certain rules.
>
> I also wonder if ...
>
> ... GameTable should be renamed GameInProgress.

Probably illustrates the purpose better with the name GameInProgress. A
GameTable can be interpreted as a _place_ where you can start a game,
instead of the actual game.

> ... a Condition couldn't be another subclass of a Rule, could there
> still
> be an automaton to interpret a strange graph of various kinds of Rules?

I really can't answer this question. I was just hoping that it was
possible. I guess you could include some other interface which has as a
sole purpose to create an Iterator over the Rules to check for any given
moment. A basic implementation of this could be written by the framework
and then it could be exchanged if necessary.



--
Regards

Magnus Lundgren

[Gameframe-apis] Hi there

[Frank N. <in...@do...>]

Hello Everyone,

I just wanted to confirm (and test) I'm now subscribed to this 
list and we (Magnus) can move our thread over to this list.

Cheers,
Frank

-- 
------------------------------------------ooO---"---Ooo-------------------
in...@do...,                "I hate this game, lets play it
again"
http://doris-frank.de,            
http://duf.spieleck.de/mailman/listinfo   
Dr. Frank  Sven  Nestel,      http://spieleck.de,
http://frank.spieleck.de 
Spiele von Doris und Frank, Wolfsstaudenring 32, D-91056 Erlangen,
GERMANY

[Gameframe-apis] Some Rules API-thoughts

[Patrick C. <pat...@we...>]

> Hi Magnus, hi everyone else,
>=20
> sorry for the slow answer, I had some trouble with my intestinals=20
> lately and now I'm preparing for the Erlanger Spielertage a=20
> local game event where I'll conduct a M=FC and Zoff im Zoo =
tournament...
>=20
> Therefore only a few coarse remarks on you conribution.
>=20
> > > The Basic idea is: When a Move is to be made we find
> > > the Rules that applies to that move. Checks if the move
> > > is legal, then the Move is executed. After that the Rules get to=20
> > > check the new GameState to see if we should alter it. For example=20
> > > enter a new Phase or declare the end of the Game.
> > >
> > > The intention to encourage the implementer of a Game to structure=20
> > > the rules instead of writing one huge Rule class with=20
> "if-else if"=20
> > > clauses. And also make it possible to have rules that applies to=20
> > > certain pieces or cards.
>=20
> Yes, avoiding all kinds of cases is a good idea. On the other=20
> hand what you describe might be something which could be internal=20
> structure of the previous design.
>=20
> Anyway I'm not sure if yours and the previous design are=20
> entirely in sync. The problem is that we're now talking about=20
> different things but take the same object names. This ain't=20
> gonna work.
>=20
> With the original source:
>=20
> 	PlayerMove was meant to be the action of a single player. =20
>=20
> 	GameRule was meant to be an entirely immutable object, actually
> 	a Factory for an initial GameState taken a GameRuleCustomizer
> 	as a parameter.
>=20
> 	The was no object Game, cause what is called a Game (at least=20
>    	in German) could be all a Set of Rules (i.e. GameRule) a running
> 	game (i.e. a GameState or a GameTable).
>=20
>=20
> 	The GameState is a Factory for "empty" PlayerMoves=20
> (i.e. Beans which=20
> 	describe the possibilities a player has) and a=20
> Collection to gather=20
> 	all players moves. It is also the external (unknown)=20
> driver of a game=20
> 	which  is to issue the GameState.doTurn() to either=20
> obtain a new GameState,
> 	or obtain the old one (i.e. in case of incomplete turns) or=20
> 	issue an exception.
>=20
> 	This allows for very different turn orders:=20
> 	 * Only one player can play, every other player get=20
> empty or null moves.
> 	 * All players play simultanteous the outcome depends=20
> on joint action
> 	   (like that all play a card face down thing)
> 	 * Players play entirely without sync (like some web=20
> games, when you
> 	   log in you do your actions, everyone else does his=20
> action when he=20
> 	   wants.)
>=20
> 	I think one cannot let the a single players turn do the=20
> "update" on
> 	a GameState.=20
>=20
> 	I currently struggle with differentiating your object=20
> "Game" and "GameState".
> 	They look like a different mixture of the original=20
> GameTable and GameState
> 	object?! I am confused.
>=20
> 	I think I understand the RuleBook, RuleBook is a way to=20
> describe the
> 	construction of complex GameRule's in term of smaller=20
> and hopefully
> 	simpler Rule objects. This could happen at two times,=20
> either in the
> 	customization phase (game setup) or due to certain=20
> PlayerMoves during
> 	the game.
>=20
> Well, so far, I must confess I'm not entirely sure if I=20
> really got the point of your suggestion. If I missed it, if=20
> you have time, give me another chance. I'm fairly sure your=20
> approach so far doesn't integrate entirely with our=20
> previous design.
>=20
> 	An (slightly optimistic) assumption of the previous=20
> design was, that
> 	a current GameState would issue PlayerMoves which would=20
> only allow valid
> 	play.
>=20
> 	I'm currently thinking along the lines, that the=20
> (original) GameState
> 	and PlayerMove objects will both become extensions of=20
> RuleBook, enabling
> 	both to be built from bricks instead as a whole entity=20
> (Thinking of
> 	Ursuppe a PlayerMove would either needs many cases to=20
> validate itself
> 	or the GameState would need to be able to generate=20
> different PlayerMove
> 	objects of every possible Gene situtations, or a=20
> mixture, having a=20
> 	basic UrsuppePlayerMove extendable by plugabble Rules=20
> could take lots
> 	of complexity away).
>=20
> 	I also wonder if the GameRuleCustomizer could use the=20
> RuleBook mechanics
> 	also, that is GameRuleCustomizer also extends RuleBook=20
> and the initial
> 	State of a game constructed with that Customizer=20
> involves the copying
> 	of tiny Rule objects from the Customizer to the initial=20
> GameState.
>=20
> 	This is also what PlayerMove.update(GameState) what you=20
> suggested could
> 	mean, it could be considered as a callback for the=20
> GameState to be used
> 	in a fragment like=20
>=20
> 		doTurn()
> 		{
> 			...
> 			Iterator moves=20
> 			while (moves.hasNext())
> 			{=09
> 				PlayerMove move =3D (PlayerMove)=20
> moves.next();
> 				... do s.th. else with the move ...
> 				move.update(this);
> 			}
> 		}
>=20
> 	A mechanic both more general and more specific could be=20
> to have a
> 	RuleBook.transferRules which is meant to copy Rules=20
> from one RuleBook
> 	to another. This could be used to copy Rules from the=20
> GameRuleCustomizer
> 	to the initial GameState, from a old GameState to a new=20
> one or from a
> 	PlayerMove to the fresh GameState.
>=20
> Well, this was long, and I'm not entirely sure it was clear.=20
> But I did my very best.
>=20
> Let us know what you think.
>=20
> Frank=09
>=20
> --=20
> ------------------------------------------ooO---"---Ooo-------
> ------------
> in...@do...,                "I hate this game, lets play it
> again"
> http://doris-frank.de,           =20
> http://duf.spieleck.de/mailman/listinfo  =20
> Dr. Frank  Sven  Nestel,      http://spieleck.de,
> http://frank.spieleck.de=20
> Spiele von Doris und Frank, Wolfsstaudenring 32, D-91056=20
> Erlangen, GERMANY
>=20
>=20

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

[Stefano B. <io...@ba...>]

> The Basic idea is: When a Move is to be made we find
> the Rules that applies to that move. Checks if the move
> is legal, then the Move is executed. After that the Rules
> get to check the new GameState to see if we should alter
> it. For example enter a new Phase or declare the end
> of the Game.

This is a good idea: real board/vard games rules are described in a
rulebook, so we can do this too.

I think GameState should follow the Composite pattern and the content
has to be a well structured tree of extended GameState object that will
be handled by specific gamerules that the framework will provide to the
game creator.

What is a GameBean? Are they the object taking place in the game? Cards
are GameBean? GameBeans are the objects whose state compose the
GameState?

I'm not sure I've understood completely your idea, could you please take
a specific game and try to describe the rulebook for the specific game?
I would like to see how much this method become complex in cardgames
with many rules and many game states.

Bye,
-b-

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

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

[<mik...@ya...>]

Hi,

We are currently trying to schematize card games using
a "formal" syntax (XML).  In this way we can develop a
rulebook in a standardized format for each separate
game.

Mike

 --- Patrick Carl <pat...@we...> 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.
> 
> 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.
> 
> Patrick
> 
> > 
> > Hi!
> > 
> > Some thoughts on architechture around rules:
> > I have intentionally shorted the code so there
> > are few modifiers and no throws clauses here.
> > 
> > The Basic idea is: When a Move is to be made we
> find
> > the Rules that applies to that move. Checks if the
> move
> > is legal, then the Move is executed. After that
> the Rules
> > get to check the new GameState to see if we should
> alter
> > it. For example enter a new Phase or declare the
> end
> > of the Game.
> > 
> > The intention to encourage the implementer of a
> Game to 
> > structure the rules instead of writing one huge
> Rule class 
> > with "if-else if" clauses. And also make it
> possible to have 
> > rules that applies to certain pieces or cards.
> > 
> > -- Code section --
> > 
> > /**
> >  * Generic Move interface used to describe an
> action that
> >  * a player makes. Could be moving a piece,
> playing a Card etc
> >  *
> >  */
> > interface Move {
> >    GameBean[] getInvolvedBeans();
> >    Player getPlayer();
> > 
> >    /**
> >     * Updates the game state when this Move is
> made.
> >     * This method will only be called if it is
> legal
> >     * to execute this Move.
> >     */
> >    void update(GameState gs);
> > }
> > 
> > interface Player { }
> > 
> > interface Game {
> >   GameState getCurrentState();
> >   RuleBook getRuleBook();
> > 
> >   /**
> >    * Checks if the move is legal and if so will
> update the
> >    * GameState.
> >    */
> >   void execute(Move m);
> > }
> > 
> > /**
> >  * Holds all information about the current game
> situation.
> >  * Such as stage, phase, pieces, cards played etc
> etc.
> >  */
> > interface GameState {}
> > 
> > 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);
> > 
> > }
> > 
> > interface Rule extends Comparable {
> > 
> >   Condition getCondition();
> >   boolean isLegal(Move m, GameState gs);
> >   //Possibly there should be different types of
> rules
> >   //One for legal checks and another for post
> conditions.
> >   void postMoveCheck(GameState gs);
> >   int compareTo(Object obj);
> > }
> > 
> > /**
> >  * Used to describe when a Rule applies.
> >  */
> > interface Condition {
> >   boolean doesApply(Move m, GameState gs);
> > 
> >   /**
> >    * Condition for rules that should always be
> checked.
> >    */
> >   Condition ALWAYS = new Condition(){
> >      public boolean doesApply(Move m, GameState
> gs){
> >         return true;
> >      }
> >   }
> > }
> > 
> > /**
> >  * Used to describe a Condition for Rules that
> >  * applies when certain GameBeans are involved
> >  * in the Move.
> >  */
> > class BasicCondition {
> > 
> >   GameBean[] appliesTo;
> > 
> >   public boolean doesApply(Move m, GameState gs){
> >      for(int i = 0; i < appliesTo.length; i++){
> >         for(int j = 0; j <
> m.getInvolvedBeans().length; j++){
> >           
> if(appliesTo[i].equals(m.getInvolvedBeans()[j])){
> >               return true;
> >            }
> >         }
> >      }
> >      return false;
> >   }
> > }
> > 
> > --
> > 
> > Magnus Lundgren
> > 
> > 
> > 
> >
>
-------------------------------------------------------
> > This SF.NET email is sponsored by: Thawte.com - A
> 128-bit 
> > supercerts will allow you to extend the highest
> allowed 128 
> > bit encryption to all your 
> > clients even if they use browsers that are limited
> to 40 bit 
> > encryption. 
> > Get a guide 
> >
>
here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> > _______________________________________________
> 
=== message truncated === 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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

[Patrick C. <pat...@we...>]

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.

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.

Patrick

> 
> Hi!
> 
> Some thoughts on architechture around rules:
> I have intentionally shorted the code so there
> are few modifiers and no throws clauses here.
> 
> The Basic idea is: When a Move is to be made we find
> the Rules that applies to that move. Checks if the move
> is legal, then the Move is executed. After that the Rules
> get to check the new GameState to see if we should alter
> it. For example enter a new Phase or declare the end
> of the Game.
> 
> The intention to encourage the implementer of a Game to 
> structure the rules instead of writing one huge Rule class 
> with "if-else if" clauses. And also make it possible to have 
> rules that applies to certain pieces or cards.
> 
> -- Code section --
> 
> /**
>  * Generic Move interface used to describe an action that
>  * a player makes. Could be moving a piece, playing a Card etc
>  *
>  */
> interface Move {
>    GameBean[] getInvolvedBeans();
>    Player getPlayer();
> 
>    /**
>     * Updates the game state when this Move is made.
>     * This method will only be called if it is legal
>     * to execute this Move.
>     */
>    void update(GameState gs);
> }
> 
> interface Player { }
> 
> interface Game {
>   GameState getCurrentState();
>   RuleBook getRuleBook();
> 
>   /**
>    * Checks if the move is legal and if so will update the
>    * GameState.
>    */
>   void execute(Move m);
> }
> 
> /**
>  * Holds all information about the current game situation.
>  * Such as stage, phase, pieces, cards played etc etc.
>  */
> interface GameState {}
> 
> 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);
> 
> }
> 
> interface Rule extends Comparable {
> 
>   Condition getCondition();
>   boolean isLegal(Move m, GameState gs);
>   //Possibly there should be different types of rules
>   //One for legal checks and another for post conditions.
>   void postMoveCheck(GameState gs);
>   int compareTo(Object obj);
> }
> 
> /**
>  * Used to describe when a Rule applies.
>  */
> interface Condition {
>   boolean doesApply(Move m, GameState gs);
> 
>   /**
>    * Condition for rules that should always be checked.
>    */
>   Condition ALWAYS = new Condition(){
>      public boolean doesApply(Move m, GameState gs){
>         return true;
>      }
>   }
> }
> 
> /**
>  * Used to describe a Condition for Rules that
>  * applies when certain GameBeans are involved
>  * in the Move.
>  */
> class BasicCondition {
> 
>   GameBean[] appliesTo;
> 
>   public boolean doesApply(Move m, GameState gs){
>      for(int i = 0; i < appliesTo.length; i++){
>         for(int j = 0; j < m.getInvolvedBeans().length; j++){
>            if(appliesTo[i].equals(m.getInvolvedBeans()[j])){
>               return true;
>            }
>         }
>      }
>      return false;
>   }
> }
> 
> --
> 
> Magnus Lundgren
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com - A 128-bit 
> supercerts will allow you to extend the highest allowed 128 
> bit encryption to all your 
> clients even if they use browsers that are limited to 40 bit 
> encryption. 
> Get a guide 
> here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> _______________________________________________
> Gameframe-apis mailing list Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gameframe-apis
> 

[Gameframe-apis] Some Rules API-thoughts

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

Hi!

Some thoughts on architechture around rules:
I have intentionally shorted the code so there
are few modifiers and no throws clauses here.

The Basic idea is: When a Move is to be made we find
the Rules that applies to that move. Checks if the move
is legal, then the Move is executed. After that the Rules
get to check the new GameState to see if we should alter
it. For example enter a new Phase or declare the end
of the Game.

The intention to encourage the implementer of a Game to
structure the rules instead of writing one huge Rule class
with "if-else if" clauses. And also make it possible to
have rules that applies to certain pieces or cards.

-- Code section --

/**
 * Generic Move interface used to describe an action that
 * a player makes. Could be moving a piece, playing a Card etc
 *
 */
interface Move {
   GameBean[] getInvolvedBeans();
   Player getPlayer();

   /**
    * Updates the game state when this Move is made.
    * This method will only be called if it is legal
    * to execute this Move.
    */
   void update(GameState gs);
}

interface Player { }

interface Game {
  GameState getCurrentState();
  RuleBook getRuleBook();

  /**
   * Checks if the move is legal and if so will update the
   * GameState.
   */
  void execute(Move m);
}

/**
 * Holds all information about the current game situation.
 * Such as stage, phase, pieces, cards played etc etc.
 */
interface GameState {}

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);

}

interface Rule extends Comparable {

  Condition getCondition();
  boolean isLegal(Move m, GameState gs);
  //Possibly there should be different types of rules
  //One for legal checks and another for post conditions.
  void postMoveCheck(GameState gs);
  int compareTo(Object obj);
}

/**
 * Used to describe when a Rule applies.
 */
interface Condition {
  boolean doesApply(Move m, GameState gs);

  /**
   * Condition for rules that should always be checked.
   */
  Condition ALWAYS = new Condition(){
     public boolean doesApply(Move m, GameState gs){
        return true;
     }
  }
}

/**
 * Used to describe a Condition for Rules that
 * applies when certain GameBeans are involved
 * in the Move.
 */
class BasicCondition {

  GameBean[] appliesTo;

  public boolean doesApply(Move m, GameState gs){
     for(int i = 0; i < appliesTo.length; i++){
        for(int j = 0; j < m.getInvolvedBeans().length; j++){
           if(appliesTo[i].equals(m.getInvolvedBeans()[j])){
              return true;
           }
        }
     }
     return false;
  }
}

--

Magnus Lundgren