Comments/Ratings for a Single Item

Great Fergus!

Not sure I understand how to use them to store initial random positions.

Can you please give us an example?

I have just added support for function literals. I'll be brief, because now I'm tired.

The literal operator returns a function literal or an array literal, depending on whether it receives a function name or an array.

The setfn command sets the named function to the value of an expression. To copy a function, you can set a new function to the literal of an already defined function. For example:

def ff - #0 #1;
setfn qq literal ff;

This also works:

def ff - #0 #1;
set dd literal ff;
eval def qq #dd;

You can copy functions even faster without the intermediary of function literals:

copyfn ff qq;

With function literals, you can write code that creates its own functions. This may be useful for writing more generalized code, which can be used with more games, or for games whose rules change according to new conditions.

I have now added commands and built-in functions for using logical directions. A logical direction is one associated with a name rather than with an actual physical direction. If you program ZRF files, you are already familiar with using logical directions, because that is all that Zillions of Games uses. Until now, Game Courier has only used physical directions. Contrast how GAME Code could define a Knight's move with how Zillions of Games would:

def N checkleap 1 2;

vs.

(moves
	     (leap2 n ne)
	     (leap2 n nw)
	     (leap2 s se)
	     (leap2 s sw)
	     (leap2 e ne)
	     (leap2 e se)
	     (leap2 w nw)
	     (leap2 w sw)
      )

GAME Code could simply define a Knight as a 1-2 leaper and do mathematical calculations to check whether its move was legal, whereas ZoG needed to have every direction of movement spelled out explicitly.

Now you can do the same thing in GAME Code. The map and link commands will define directions similarly to how Zillions of Games does. The logleap and logride built-in functions will determine whether a leap or ride is legal using logical directions. The logleap function can be used for both simple leapers and lame leapers. Here are some examples:

// Chess Knight. Knight moves must be defined as single leaps.
def N logleap #0 #1 nne nnw sse ssw nww nee see sww;
// Xiangqi Knight. Lame leaps defined by separate paths, each in a pair
// of parentheses
def H logleap #0 #1 (n ne) (n nw) (s sw) (s se) (w sw) (w nw) (e se) (e ne);

The logride function can work for simple riders, winding riders, short-range riders, winding short-range riders, and turning riders. Some examples:

Simple rider. Rook
def R logride n w s e;

Winding rider.
Goes orthogonally, then outward diagonally, then alternates between
the same two directions.
def WR logride #0 #1 (n ne) (n nw) (s sw) (s se) (w sw) (w nw) (e se) (e ne);

Short-range rider. Short Rook. Non-direction z is used to stop movement.
def SR logride (n n n n z) (w w w w z) (s s s s z) (e e e e z);

Winding short-range rider. 
Like previous winding rider but limited to four spaces.
def SWR logride (n ne n ne z) (n nw n nw z) (s sw s sw z) (s se s se z) (w sw w sw z) (w nw w nw z) (e se e se z) (e ne e ne z);

Turning rider.
Moves one space orthogonally, then outward like a Bishop
def OD logride (n (ne) (nw)) (s (se) (sw)) (e (se) (ne)) (w (nw) (sw));

Bug in the preset for Wildebeest Chess:

http://play.chessvariants.org/pbm/play.php?game%3DWildebeest+Chess%26settings%3DWildebeest+Chess+with+rules

Hi, I have written a preset for Wildebeest Chess some months ago. When I tested it (arount spring/summer of 2009) it seemed to work, but now it is no longer working. Before the first move it complained that the function definition of some function is wrong: the message was 'Function def requires more arguments than it has placeholders for.'. I fixed this by removing the function definitions, doing the calculation directly where the functions were previously called.

The function definition was:
def isKINGc == #2 K and == #0 f1  and match #1 a1 b1 c1 d1 h1 i1 j1 k1;

and it was called in post-move 1:
if fn isKINGc origin dest moved:
  ...


Now there is still another bug: when the rook castles onto the origin square of the king (entered as a rook's move, e.g. a1-f1) then the king dissapears.

I am sure that I had checked this after writing the preset and it worked, before Jeremy Good made the preset the official one (see the comments at http://www.chessvariants.com/large.dir/wildebeest.html).


-----------------------------------------------

Edit: I have found the bug and fixed it. I just forgot a ':' after the condition of an if-statement...

Attention Game Courier Developers:

If you have programmed any presets to enforce the rules, and you use variables to keep track of the location of the King or other royal piece, you will need to make a slight modification to your code for your preset to work properly with fairy chess problems. In most of the presets I've programmed, I have code that looks like this:

set K e1; set k e8;

To work with fairy chess problems, in which the Kings might be found anywhere on the board at the beginning of the problem, this code needed to be changed to this:

set K findpiece K spaces; set k findpiece k spaces;

This change will allow Game Courier to know the position of the Kings when a fairy chess problem begins, allowing it to properly use code for recognizing check and checkmate.

I am currently going through my own presets, making the appropriate modifications. For some games with different royal pieces, this code has to be modified.

As an update to my last comment here, the new input and revision commands are called appendmove, ask, askpromote, continuemove, redomove, and rewritemove. They are all described in Input and Revision Commands. The continuemove command is what I earlier called extendmove. I have just made use of it with Extra Move Chess to handle double moves.

While working on that game, I discovered a good use for a do-while loop that ends with a never condition. I previously mentioned that this will function like a simple if statement. Although it doesn't have the benefit of adding elseif conditions, it can sometimes be more useful than a simple if statement, because it allows the use of break or continue to exit it early or the use of redo to return to the beginning. In Extra Move Chess, I had code that I wanted to execute if the player made a second move, but if the player passed the second move with the pass command, I wanted to skip over most of this code. So I put it in a do-while/loop-never loop and used break to exit early if the move equaled the pass command.

I have added a section on including a description of the rules with your preset. This is a natural language description for players to read. It may include HTML or Javascript, and I have written a Javascript function for displaying pieces using the selected piece set. Details are in the documentation at

• http://play.chessvariants.org/pbm/devguide.html#briefrules

Hello Fergus
Is there somewhere a "Zillion2Game" (whatever the name) transcription script ? It would be so much easier to transcript existing games...
Sincerely,
Stephane Burkhart (from France)

No, there isn't. The two languages serve different purposes, and they do not easily map onto each other. It's best to just forget about conversion and  program a game with reference only to the game's rules, not to the ZRF code used to program its rules in Zillions-of-Games.

I have just changed how some of the output commands work. Some output commands output text immediately. These are die, echo, print, and printr. Previously, output from these commands has remained visible when the program finished successfully. I have changed this, so that when a Game CODE program completes successfully, output from these commands will be hidden. This is done through CSS by giving a containing block the property of display:none, and the output from these commands will still be visible in the page source. With this change, these commands are intended only for debugging or for writing errors messages that can be seen when a player makes an illegal move.

I have made this change so that output from these commands will not mess up the display on mobile devices. It also removes clutter that was easy enough to ignore on a computer monitor but gets in the way more on a small mobile screen. I have also removed the restriction against using echo in Play mode, since its output will no longer show up unless something goes wrong.

I have also changed die to display text as an H1 heading, so that the error or warning message it gives will be more prominent.

For text that the player should see upon successful completion of the GAME Code program, you should use say, whose behavior has not been changed.

I traced a mysterious bug in my code for Musketeer Chess to a use of the move command in the castle subroutine. The bug is that the flag on the King's space was being unset prematurely. It turns out I had written the move command to move both the piece and the flag from one space to another. But in all my subsequent uses of the move command, I never needed it to move the flag with the piece. Although I had written the command before I had a full-fledged programming language, I ended up using it mainly in subroutines that temporarily changed the positions of pieces to test for various conditions. Also, I can't think of any game that really requires flags to move with pieces, and if you have written such a game, it's probably best to make the flag movement explicit in your code. So, I have removed the ability of the move command to move flags. It will now just move pieces.

I have reorganized and revised the beginning sections of this guide. I have also touched up the section on GAME Code. It now includes links to more tutorials and links to some of the PHP source code behind GAME Code.

I'm planning to make some changes to how variables work in GAME Code. In practice, the distinction between my and local variables has been a moot one. Both are given the narrowest scope when created, and they differ in whether they are lexically scoped to the current subroutine (my) or to the main scope (local). This difference makes local variables visible to any functions they call. In general, it is a bad idea to use local variables in this way. The basic idea behind a local variable in other languages is that it will be local to the function it is created in, and it will not be visible to other functions. So, my variables are what actually work like local variables in other languages. Also, my variables are quicker to access. So, I plan to remove what I have called local variables and use the name local for my variables. For the sake of not breaking old code, I'll treat my and local as synonyms. So, the available variable scopes will just include global, local, and static, where global has wide/main scope, local has narrow/subroutine scope, and static has wide/subroutine scope. Narrow/main scope, which is currently called local, will be removed.

I also want to provide better support for multidimensional arrays. I don't like the setelem command. I would rather do something like set var[key] "something or other". While I can currently use something like var[key] as a variable name, doing so won't currently create an array element. I want it to add an element to an actual array that will be recognized by functions that work with arrays. I also want to be able to replace key with a variable, such as var[#key]. This will require some changes to line parsing.

There is a catch to changing how variable scoping works in GAME Code. It currently supports block scoping. This means that blocks of code that appear between if and endif, do and loop, for(each) and next, or switch and endswitch increases the scope. Since PHP and JavaScript, the two main languages I program Game Courier in, do not use block scoping, I am not used to it, and I do not use it much in GAME Code, though I have used it a little bit. The main advantage to block scoping is that it will let you use variable names in blocks that might have a different use outside the blocks. The advantage to eliminating block scoping is that it allows the interpreter to handle variables more quickly, because there is no searching down levels of scope for the matching variable. Another possible advantage is that it may simplify how variables work, making it easier to add better support for multidimensional arrays. But to make this change, I'll have to check whether scope plays any functional role in how the control structures work.

I've decided to work on a modified clone script so that I can try things without disrupting Game Courier. So far, the changes I made caused the first move in a game of Gross Chess to be recognized as illegal, though I haven't figured out what is going on. What I want to do is drop block scoping, which has hardly been used, and maybe add include files to lexical scoping. I figured that the main place it would be helpful to be able to use local variables outside of subroutines is in the main body of an include file. This could be helpful given that an include file and a preset may be by different authors. But this might have problems of its own, and it might not be that necessary. Including include files early and inserting changes after the file is included, as I already do, may be sufficient.

While it is a bad programming practice to use variables in a subroutine that were created as local variables in another subroutine, I have discovered that I did this with the castle subroutine. Although I could change this in the include file it appears in, this could have effects on games that include the include file but also use custom versions of the subroutines calling it. So, to update the language without breaking anything, I would have to update the code written with the language first, and that could be a bigger project.