[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