MEETING NOTES Followup, September 18, 2001: Geoff's Email

Date: Tue, 18 Sep 2001 15:08:51 -0400
From: Geoffrey Rockwell
To: Andrea Laue
Subject: Various

Dear Andrea,

That set of definitions you circulated was terrific. I wanted to write some suggestions:

1. We need to put documentation as a type of document somewhere, probably the discourse field. It is a type of document that is fixed at the beginning and cannot be edited.

1.1 There is one type of documentation that has a special role - (human) rules. As I see it there are two types of rules - computer rules that can be implemented entirely by the computer (in other words the computer can automatically apply the rule completely) and human rules that to be completely applied will take human intervention. For example a challenge will take some human intervention to complete (I assume that it will be other players who judge or "rule" on the challenge.) We can further distinguish the two types of rules thus:

1.1.1 Computer rules have the following properties: They can be implemented on the computer in the form of code. The players do not necessarily have to know about these rules or the details of their implementation.

1.1.2 Human rules will have the following properties: They may be facilitated by the computer (the computer could automatically warn the wizard that they have to do something). They will have to be described somewhere for the players. Their description is in the form of a text that is itself part of the discourse space in some fashion to be set by a human rule itself.

2. Thinking about the variations of moves, rounds, turns and so on I thought we should be more precise. Here is a stab at some definitions:

2.1 Move - a move is a change in the game state. It has various phases:

2.1.1 Move.Start - A move is started when a player does something to indicate that they are starting a move. There could be a formal way in which a player can indicate that they are starting a move. When you start a move a Move.Domain is indicated and Move.Start.Time is also recorded by the system.

2.1.1.1 A Move.Domain is the subset of the game state that the move could affect. It is possible that people on starting a move could indicate a subset of the whole to be locked rather than blocking everyone out of everything. For simplicity sake we may start with the Move.Domain being "all", but theoretically it is possible to describe at the time of starting a move the part of the database to be possibly affected.

2.1.1.2 The Move.Start.Time is the moment when the move is started.

2.1.1.3 At the time when a Move is started the Mover is also recorded.

2.1.2 Move.Duration - There should be a setting that sets the maximum duration of a move should the system be set to not allow simultaneous moves. A "0" means that starting a move doesn't block others out.

2.1.3 Move.Repeat would be a setting that sets how many moves a player can make before they are prevented from moving until someone else has a move.

2.1.4 Move Submission. A move is submitted when the player proposes their move to the system. It is at this point that the computer evaluates the move and acts on it.

2.1.5 Move Evaluation is when the computer evaluates the move and either hands it off to a player(s) for further evaluation or moves on to Move Implementation.

2.1.6 Move Implementation is when the move is recorded and the game state changed. In some cases there will be a prolonged human evaluation before states are changed (Someone decides what to do with the move or it gets discussed.)

2.2 Session - A session is a collection of moves that constitute a whole in some way. The session is important for certain types of game play like the Diplomacy model. A session will have the following:

2.2.1 One or move moves as determined by a Session.Move.Type setting. Here is where you decide if moves must be sequential, in turns, or in clusters. Should a session allow sequential moves then the session does not really make sense. In turns a session is when all the players have moved or declined to move. In clusters is when the players have to submit their move by a certain time.

2.2.2 In the case of cluster-type then a session will have phases. There will be a phase during which moves are submitted (2.1.4), a phase during which all the moves are evaluated by the computer, a phase when any human evaluations have to take place (it could be iterative) and then an implementation phase. In a way a session here is a multiplayer move. The session can be seen a type of move and we might for simplicity sake define it that way.

2.2.3 In a session that is of the turn type there may also be phases before and after everyone has their turn. There could be a phase for the wizard to assign points or a phase for special moves and so on.

2.3 Special Moves. There is a special category of move which is when the wizard (or whatever we call the person who sets up the game and therefore has special powers) changes the game state using their special powers. This in some sense will have to be submitted, evaluated and completed by the system. This type of move might include changing any of the settings above so that the game could be played differently.

3. To summarize I see the following types of games:

3.1 Sequential One Move At A Time Games where there are no sessions, the Move.Duration is set to a period of time more than 0 so that starting a move blocks others, and moves are evaluated and implemented immediately.

3.2 Sequential Simultaneous Move Games where there are no sessions, the is duration to a move so you can't block others, moves are evaluated/implemented as they come in to the system and generally you can make as many moves as you want. (There may be a limit to the number of moves you can make in a row.)

3.3 Turn Taking Games where there are sessions during which all the players in a predetermined sequence make a mover or decline to (based on some Move.Duration time out setting). At the end of a round every player has had a chance to move once and certain other things can happen.

3.4 Cluster Move Games where all the moves are submitted by a deadline set by the Move.Duration setting. They are then evaluated by the computer and in some cases there is human evaluation to suplement the computer. Once evaluated completely the move(s) is implemented and the next session (or move) starts.

As I write this I like the idea more and more of eliminating the term session in favor of calling it simply a move with special features. If a move is the process of changing the state then the session is a move where there are multiple submissions before the evaluation and implementation phases.

Hope this helps,

Geoffrey R.

[back]