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