| Author |
Message |
Ronald W Brierley (Ronaldwb)
| | Posted on Monday, June 16, 2003 - 9:54 am: | |
I would like an (alltheplayers name-list-of-all-players) to be a requirement within a game definition. It should not be available for overwriting within any other variant. Its purpose is to list all the names of potential players in the game or its variants. The (players variant-list-of-players) would then be available for defining in the game or any variant the set of players in the game or variant who are actually available to make moves in that game or variant. New players found to be not in the alltheplayers list would be detected as errors. The game or variant players list would specify the order of appearance of the names of players in the drop-down list available to be chosen by the human, as it now occurs, but without the meaningless redundancy of names which is now required when a globally defined zone is applicable to all the possible players. The turn-order list could then, as now, be as complex as is needed by the design of the variant but being only capable of involving players listed in that variant's players list. |
Jeff Mallett (Jeffm)
| | Posted on Friday, June 20, 2003 - 8:08 pm: | |
I'm unclear on what about this would be so useful to you. For example, if you want to you can make a macro like
(define alltheplayers white black indigo)
and then use (alltheplayers) in your zone statements, etc. |
Ronald W Brierley (Ronaldwb)
| | Posted on Sunday, June 22, 2003 - 8:14 am: | |
Some time ago I decided that a chess variant for standard chess pieces on a non-standard board would make an interesting game. I put a lot of consideration into the design structure and thought that it would be possible to implement it in the ZoG2 ZRF language. On trying to produce a program I encountered two types of problem. Firstly, I was unsure of the subtleties of the syntax of the language. Secondly, I was unsure of the implied semantics of the language. For this reason I decided to implement a simpler game that could help me to solve some of my difficulties. One of the problems I hoped to illustrate and examine was lists of players. Instead of attempting to explain with the actual game that I have been able to run, I shall describe the relevant problems using a game of a similar nature. The problems concerning lists are very complicated, so I hope I am able to illustrate each effect without error or obscurity.
The places where lists of players occur are: in defining zones; in defining the players able to make a move in a 'game' or 'variant'; in defining turn-order of the players; in defining win, loss or draw conditions; indirectly in the listing of the choices for human or computer player available to humans in the drop-down choice list; indirectly in the listing of the pieces available for substitution in a square of the board when using the right-hand button; indirectly in the set-up of the pieces on the board for a 'game' or 'variant'; indirectly in the listing of the images of the pieces.
The game of Rookts is played on a standard chess board with up to four players. There is only one type of piece, the Rookt, which moves as a chess knight when on a black square but moves as a rook when of a white square. Each player, Yellow, Blue, Red and Green, starts with six pieces of a colour corresponding to the player's name. Their pieces are set up to occupy the middle six squares of their side of the board. The game is won by the last player with any piece or pieces left on the board. Several variants are defined for two, three or four players, making moves in various clockwise orders. Since the black and white squares have the same properties for all the players it would seem reasonable to define a zone called on-white using a list of all the four possible players. This could be effectively done using macros. Similarly the game terminating conditions would be the same for all players. The zone and the 'game' or 'variant' termination conditions would be defined in the 'game' code. After trying various codings, experience teaches that this default zone controls what may appear in the 'players' list of a 'variant'. If a reduced 'players' list for a three-player 'variant', for Blue, Red, Yellow, was included in the 'variant' then a syntax error would state that the zone contained a non-player Green. If all variants are given the same 'players' list as the names listed in the zone definition then the 'turn-order' list of players could be those players who actually can make moves in that 'variant', but the order of the three players in the choice of players list is governed by the order in the 'players' list, i.e. Yellow, Blue, Red and Green, would give the order as Yellow, Blue, Red, irrespective of the fact that the players may be going to make moves in the order Blue, Red, Yellow as dictated by the 'turn-order' list. This implies that each 'variant' should have its 'players' list as a complete list of players but ordered so as to indicate the actual order of moving. This is desirable since the player making a choice would like to know the order of turns to play but cannot see the lists within the program. Of course the 'description' of the 'variant' could include helpful explanation but would it help compared to a correctly ordered choice list? Also the list of pieces available for editing a board using the right button would not only contain the names of the players in the 'turn-order' list but there would appear anonymous pieces which if chosen would be shown on the board as a piece belonging to a player who has no moves in the game. This must be an undesirable feature of the semantics of lists as they are currently implemented in the definition of the ZRF language.
I have spent an excruciating weekend editing my actual simplified program so that each 'variant' has a list of 'players' that agrees with the 'turn-order' for that 'variant' and arranging the lists for the drop-down choices and for square editing to correctly list only sensible players in sensible orders and ensuring that each 'variant' has terminating conditions that correspond to the players actually able to make moves in that 'variant'. It is all possible but it requires ingenuity and much patience and editing. For instance a macro was defined to accept four parameters but how could it be passed in a 'variant' with only the three players appropriate to the 'variant'. The answer was to fill up the missing parameters with the names of players who were already represented by earlier parameters in the list of parameters. This is all very tortuous.
My suggestion was to avoid this obscure complexity by altering the nature of the lists of players appearing in the 'game' coding and the coding of 'variant's. A new 'allplayers' list was to include the names of all the players appearing in the 'game' and in all other variants. The 'players' list of the 'game' or any 'variant' would be a list of those players for which the 'game' or 'variant' was designed. A player occurring in this list who did not occur in the 'allplayers' list would be detected as an error in that 'variant'. The players appearing in the 'turn-order' list of a 'variant' would be checked against those of the 'variant's 'players' list. A mismatch would signal an error in the 'turn-order' list. Complex 'turn-order's like A, B, A, C, A, D would merely need to be checked to see if A, B, C and D belonged to the 'players' list of that 'variant'. Any 'variant's Win, Loose, and Draw condition list of players would similarly only need to be checked again the 'players' list of the 'variant'.
I would also like to state that the AI of ZoG2 system copes very well with such a multi-player game. |
Ronald W Brierley (Ronaldwb)
| | Posted on Wednesday, June 25, 2003 - 6:05 am: | |
In the above long message there was no mention of neutral players. This is because I haven't played or designed a game that includes them. On considering the implications of neutral players, I have come to the conclusion that it would be best to create yet another new command (neutrals list-of-players) which could be specific to the 'variant' or the 'game'. The included names would also have to appear in the 'allplayers' list. The players in the 'neutrals' list would be allowed in the 'board-setup' list of the 'variant' and the right button drop-down positions editing list in order for the pieces of neutral players to be able appear on the board. The players in the 'neutrals' list would not be allowed to appear in the 'variant's 'players' list since those are players who can move pieces. The players in the 'neutrals' list would be allowed in the 'turn-order' list of the variant but only as players whose pieces would be moved by actual players of the 'players' list of the variant. An explanation of the use of neutrals would need to be included in the 'variant's 'description' otherwise the person playing the 'variant' would have little evidence of their existence. I hope soon to publish my NotChess game which illustrates all the current means of implementing user friendly interfaces. |
Ronald W Brierley (Ronaldwb)
| | Posted on Sunday, July 06, 2003 - 11:55 am: | |
NotChess is now a published ZoG2 game. Its code illustrates the complexity currently required to provide lists of players, under all circumstances, that specify exactly the requirements of the game. It will one day, I hope, also have an efficiency improved coding using an if-else structure, when I find how to avoid the syntax errors that I always seem to trigger. |
|