Comments/Ratings for a Single Item

After exposure to Jocly's distinction between model and view, I realized that the same distinction was implicit in Game Courier, but I hadn't made it as explicit. So I have now reorganized Edit mode to reflect the same kind of distinction. I have split what Jocly calls the model into two different sections. These are Structure and Code. The structure of a game is its coordinate system and its location of pieces. The code is where automation and rule-enforcement are handled. The code has to regularly refer to the structure of the game to interpret, evaluate, and make moves.

What Jocly calls the view, I'm calling Appearance. These are details that affect how the game looks. In general, the code has nothing to do with appearance, and it should not be allowed to change it, but, for the most part, details of appearance should be user-configurable. The main exception to this is the shape of the board. This will have an impact on the rules, which the code needs to handle, and except for changing between squares and custom grid, it should not be user-configurable. But the code does not need to know the value of this field to process moves, and changing it should have no effect on the game logic.

While doing this reorganization, I have also linked each field to the appropriate entry in the Developer's Guide, and I have placed a brief description of it in the link's TITLE field, which you can view by hovering over it. Edit mode is currently showing all fields. I will fix this later.

I have taken a big step toward making Game Courier more suitable for games played in real-time. I have removed the automatic page refreshing when you hit the Continue button, and I have replaced this with a bit of AJAX that periodically checks whether it is your turn again, then refreshes the page once it is your turn again. I still have more things to do to better support real-time play. One is to include a starting time in invitations for real-time games. Another is to add an audible alert when it is your turn again. I might include a selection of sounds and give players a choice.

There are now animated clocks, and you can watch games live. The clocks appear in timed games above and below the board. The one below the board is for the player whose turn it is to move, and, as long as JavaScript is on, this one counts down one second at a time. It shows days as a serif number on a white square and hours, minutes, and seconds in a digital clock font (DSEG7 Classic Bold from http://www.keshikan.net/fonts-e.html). The number of days will not show up unless greater than zero. The hours, minutes, and seconds appear in green so long as only grace time is being used, and they change to yellow when grace time is used up, and time is being lost for real. The clock for the opponent of the current player appears at the top, and its hours, minutes, and seconds appear in red. The color coding is by traffic light colors. Red is for the player who is stopped, and green and yellow are for the player who can go.

When you view a game you're not playing, and you're viewing the latest move, the page will update whenever a new move is made. JavaScript must be on for this to work. This allows you to view games live, watching the moves as they're being made.

When making the first move on a multi-move variant, the border color and text color are now reverting to black.

Game Courier will now display the captured pieces. By default, this works by making a list of pieces in the starting position, subtracting from the list any piece on the board in the latest position, and displaying the pieces still left in the list after sorting them in case-sensitive alphabetical order. Since this is not always appropriate for every game, how or whether Game Courier displays captured pieces can also be controlled with GAME Code for individual games. To display captured pieces, Game Courier populates an associative array called $capturedpieces. This array takes pieces labels as keys and piece counts as values. This variable can be set with setsystem to an array calculated with GAME Code, or it can be set to false, which will cause no captured pieces to be displayed. This is appropriate for games with drops, such as Shogi, which already display captured pieces in the playing area.

The problem with the border and text colors was more general than anything to do with double move variants. Tying this back into the history of Game Courier, I am currently studying HTML5, and I am trying out new ways to improve the forms with the use of new features in HTML5. One of these is the color type for the input element. This displays the color instead of its name or hexadecimal code, and it provides a color selector, like what you may find in a graphics program. But when I changed the input fields for the border and text colors to the color type, I learned that it expected the color code to begin with a #, and I had been allowing color codes without it. To fix this, I used a regular expression to test whether the pre-existing value PHP would populate the form with was a six-digit hexadecimal number without a preceding #, and if it was to add one. But I had forgotten to begin and end this regular expression with ^ and $, which caused it to return true for values that already had a preceding #, causing it to add an extra one, which caused the color to change to black.

The addition of the text color is new and incomplete. I think I still have to go through the scripts for displaying the board and change how they access the text color.

When a GAME Code program displays a message with the say command, it will now also insert the message as an inline comment for the current move. To distinguish it from user-entered comments, it will surround it with two hyphens. In games I have coded, this will add comments for check, checkmate, stalemate, and draws. It can also be put to other uses.

Although Game Courier cannot fully analyze GAME Code to tell whether it fully enforces the rules of the game, I have given it the ability to more accurately estimate which presets enforce rules and which don't. One new thing that helps with this is the ability to display legal moves. When a preset has been programmed to display legal moves, it will populate an array of legal moves. So, if this array exists and has something in it, then it can display legal moves, and it very likely enforces them too. Besides checking this, Game Courier checks which code blocks are populated with code. If they're all empty, then it can be known for sure that there is no rule enforcement. If the post-move blocks are empty, odds are good that it doesn't enforce rules, and if the post-game blocks are empty, it's expected that it does not spot check, checkmate, or stalemate. One more thing is that it checks the post-game code for the strings check and stalemate. If it finds one of these in both, then it is assumed that it includes code for spotting check, checkmate, or stalemate, and this is taken as a good indication that full rule enforcement is present.

Based on this analysis, Game Courier will include a message above the board before a game begins to let you know what its capabilities appear to be. If you have programmed a game, you may bypass this and inform potential players of your preset's capabilities with even more certainty by including something like this in your pre-game code:

if == thismove null:
  say This preset enforces the rules and displays legal moves.;
endif;

By running the say command only when thismove is null, this message gets passed to it only at the beginning of the game before any moves have been made.

For games that can display legal moves, the ability to display legal moves is now extended to View and Preview modes in a user-friendly way. When you touch or click on a piece, it will show you how that piece can move. When you click an empty space, it will clear any markers that have been displaying legal moves for a piece. This can be particularly useful in Preview mode, because it will let you see how your opponent would be able to move if you go through with the move you are previewing. It will also enhance View mode by letting you see how the current player to move can move.

Game Courier has now been modified to give an error message if it does not recognize the value of the Submit field when clicking on a form. This is because the use of Google Translate may change this value to something Game Courier does not recognize, and users should be notified of this error when it happens.

I have begun to replace buttons made with the INPUT tag with buttons made with the BUTTON tag. The BUTTON tag allows me to separate the display text from the form value, which allows the display text to be translated to another language without changing the value that will be passed by the form. I have already changed a few forms, and they are working correctly when translated.

I have also begun to add the notranslate class to some tags, so that translations do not mess up the data passed to the form, and so that coordinates display properly on translated pages.

Game Courier checks where GAME Code has been entered for a preset, whether there is a list of legal moves, and the value of the rules flag to determine the extent of a preset's rule enforcement, and it now displays this information below the board, just underneath the name of the game, which links to the rules page. It used to put this information above the board before a game began, and it didn't weigh in the value of the rules flag. It now displays it below the board during the course of a game. The rules flag can be set with the command "setflag rules;", typically in the pregame code. Setting this simply serves as a signal that the code you wrote actually does enforce the rules. It has no effect on the rest of your code, and it will not provide you with rule enforcement if you don't actually program it in.

I have added an Advanced section to the Edit form. This includes a couple options that can be checkmarked. One of them was already included in the Edit form. The new one is the option "Do Not Include Moves in Code." For most games, this option should not be checked. And for unprogrammed games, it should never be checked. It's useful if you handle the execution of moves within your code. What this does is stop Game Courier from automatically adding the moves in a game to the code it generates for the game. If your game is not programmed, the result is that moving pieces will not work.

I added this option, because when I castled in Marseillais Chess and then tried to move the Rook that had just castled, it wouldn't let me, giving me the error message that the Rook was not on the space I was trying to move it from. I realized this was happening, because it would automatically execute all the moves before evaluating any of them. But I didn't need to include that in my code, because my code for Marseillais Chess would normally undo the latest moves, then replay them individually. Given that it was already doing that, I could just remove the moves it was undoing. So, I added the option to remove them.

I have modified how constant values can be included in code. In the past, a constant could be used by preceding its name with the # sign, just the same way that variables can be used, and constant names would have higher precedence than variable names. This helped keep the value constant when the name was used for a constant. But I have decided that this is a bad practice, because it interferes with a function's ability to count on its local variables having higher precedence than anything else with the same name.

So, I have made two changes. First, the @ sign may now be used in place of the # sign to get a constant value. This works only for constants, and its use will make it clearer that a given name belongs to a constant. Second, the # sign may still be used to return a constant value, but it now has lower precedence than variables with the same name. This will provide backwards compatibility so long as your variables and constants do not use the same names.

Very nice.  This, combined with the new fairychess include file, marks a definite step forward.  I'm glad to see GC code is continuing to be developed.  I was a little concerned that the change of precident could break some presets, but I just opened a large number of finished games and didn't see any issues.  Using constants and variables with the same name is probably uncommon.

I'm glad you like it. The changes I made to constants came about while I was working on the fairychess include file. Since I planned on using constants to associate piece labels with piece names, I wanted to avoid collisions between constants and variables with the same name. I did a grep search on the settings files and changed a few to use the @ sign instead. Just in case constants are used in presets that are defined in forms instead of settings files, or in case someone inadvertently uses # for constants in the future, I let it continue to be used that way but with lower precedence. Even without replacing # with @ in a few settings files, this would have been enough, because they normally did not use the same names for both variables and constants. But if I name constants after piece labels and also use short variable names in functions, collisions could arise. So, I wanted to separate the namespace between them.

I am deprecating the use of global and setglobal as aliases for system and setsystem. I would like to eventually eliminate these from the language, since global variables have a different meaning in the language.

I have limited the power of the system built-in function. While it had prevented people from viewing a password with it, it did allow you to enter "system GLOBALS" to view all the variables, which could be a big security risk. I changed it to return values only from a whitelisted set of system variables. These correspond to the same ones that may be set with setsystem.

I introduced the use of the dollar sign as a system variable designator. When appearing at the beginning of a variable name, it will return the value of the corresponding system variable if it has been whitelisted. I also added support for $old and $moved, which return the values of $lastcaptured and $lastmoved. Since the dollar sign is also the designator for PHP variables, it is basically a way to get the values for some of the PHP variables with the same name. You may also think of the S in $ as standing for system.

Game Courier is already set up to recognize old, moved, origin, and dest as values of system variables, but I don't like this, because it prevents these from being used as ordinary words, and it might make the code more confusing if you don't already know their meaning. The use of $old, $moved, $origin, and $dest should now be preferred, though I can't phase out the old way without rewrting lots of code. I have at least made the changes in the new fairychess settings file for Chess, so that they can be used going forward.

I have removed $countextrasas from the system variables. It was not used in any settings file, and I could not figure out what it was for. My comments on it were not informative enough. I commented out the code that used the variable, since it appeared to be useless.

Since I am updating the GC presets for Opulent anyway for the new array, I am going to modify it to use the new fairychess include file.  To that end, I modified the include file to add a few new pieces.  I added Half_Duck and Knight_Wazir since Opulent requires those.  While I was at it, I added the three new pieces for Kevin's games that Aurelian has been working on: Elephant_Ferz, Elephant_Wazir, and Frog.

For reference, here are all the pieces currently supported by the fairychess include file (the notes in parenthesis are not part of the actual name):

Queen
Rook
Knight
Bishop
King
White_Pawn
Black_Pawn
White_Berolina_Pawn
Black_Berolina_Pawn
Cardinal (BN)
Marshall (RN)
Amazon (BRN)
Cannon
Vao
Wazir
Ferz
Camel
Camelrider
Dabbabah
Dabbabahrider
Elephant
Elephantrider
Nightrider
Dragon_Horse (BW)
Dragon_King (RF)
Eques_Rex (NFW)
Wizard (CF)
Champion (WDF)
Korean_Elephant
Chinese_Elephant
Giraffe (4,1 leaper)
Grasshopper
Short_Rook (R4)
Squirrel (NAD)
Spider (DA)
Spider-rider (DDAA)
Squire
Unicorn (BNN)
Zebra
Elephant_Ferz (FA)
Elephant_Wazir (WA)
Half_Duck (HFD)
Knight_Wazir (NW)
Frog (FH)
Griffon
Aanca
Leo (Cannon + Vao)
Mao
Moa
Murray_Lion

One small nit-pick, the Spider-rider has a dash while the other riders do not. Any objections if I correct this inconsistency?

The hyphen is in Spider-rider to separate the two adjacent r's.

I have added to the fairychess include file the Shogi and CWDA pieces that weren't already in it.

I'm working on adding piece descriptions to the fairychess include file. One reason for this is to help programmers using the include file find the code for the pieces they want. But instead of putting them into comments, I am creating strings that can be used in error messages to remind players how a piece moves. I started with the Chess pieces while I took the time to hone the code for displaying the messages. The strings use "%s" instead of the piece name in case someone renames a piece. I had thought of using printf, but I ended up using str_replace, which I added to the language. Like the PHP str_replace, its arguments are search, replace, and string.

I have completed some improvements in how arrays are handled. Elements of multi-dimensional arrays may now be specified by including periods in the variable name. Each period separates an array element from its parent array. For example, in #example.element, the parent array comes first, and the element comes second. Deep multi-dimensional arrays are also possible, such as #this.is.an.example.of.a.deep.multidimensional.array.element. You can now set array elements with set, and you can use the value of array elements as arguments to commands that do not evaluate expressions.

You can also use array elements with some commands that change their value. For example, if you kept track of captured pieces in an array called cp, inc cp.p would increment the number of captured Black Pawns.

You can also read the values of elements in system arrays, such as $originalpieces.p, which would return 8 in Chess.

You can also insert variables into array element names using {}. For example, the code below would increment the element of cp corresponding to the captured piece whenever a piece is captured.

if capture:
  inc cp.{$old};
endif;

The setelem command still works, but now it just concatenates the array name with the element name and calls setuservar(). Likewise, the elem operator still works, but when an array is given by variable name, it will concatenate the names and call getuservar();

I have made a few changes to GAME Code today:

1. Functions will now evaluate variables when they are called, not when they are defined. In this example, the function x2 returns a different value each time:

def x2 * 2 #x;
set x 12;
print fn x2;
set x 23;
print fn x2;

2. Functions now allow you to set named my scope variables. To do this, prepend a variable name with the = sign, and follow it with the value you want to copy to the variable. In the following example, the function copies "Chess Variant" to the variable v, and it doubles it. Both before and after calling the function, #v returns the value of "cartoon violence". This is because the function raised the scope, and the my scoped variables it created were destroyed when the function ended.

set v "cartoon violence";
def s2 list #v #v =v "Chess Variant";
print #v;
print fn s2;
print #v;

If more than one argument follows a variable assignment, they will be converted into an array, leaving nothing to the right of the assignment.

3. Functions now accept named parameters. This works the same way as assigning a value to a variable except that no value follows the assignment. When no value follows the assignment, it pops off a value from the arguments passed to the function. In the example below, the output is 30, 110, and #x, because x has not been defined outside of the function:

def sqrplus + * #x #x #x =x;
print fn sqrplus 5;
print fn sqrplus 10;
print #x;

Numbered parameters will still work, since it would break way too much code if they stopped working. But numbered parameters will not work with named parameters. With numbered parameters, the exact number of arguments to expect is calculated. If too few arguments are given, there is an error message. If too many are given, only the ones that are needed get read and used. This allows code like this to make sense:

def mns - #0 #1;
def multdiff * fn mns #0 #1 #2;
print fn multdiff 5 11 10;

In the multdiff function, the call to mns has three arguments after it. It uses only the first two, leaving the third to be used as an argument for the * operator.

When you use named parameters, you will get an error message if there are not enough arguments. But if there are more than enough arguments, only the last arguments in the list will be used. In the code below, the first function call prints my name, but the second prints my uncle's.

def name list #first #last =first =last;
print fn name Fergus Duniho;
print fn name Fergus Patrick Duniho;

In general, you should avoid extra arguments when using named parameters, but this behavior may prove useful for creating functions that can take a variable number of arguments. To enable this, I have added the args operator, which returns an array of the remaining arguments. Named parameters will shrink the array of arguments by popping them off. So, if you pop them all off, args will be empty. But if you don't, you can do something like this:

def revwords list reverse args;
print fn revwords Fergus Duniho;
print fn revwords Fergus Patrick Duniho;

The revwords function can take a variable number of arguments. It reverses the order of the arguments and makes a string out of them. So, the two calls to the function output "Duniho Fergus" and "Duniho Patrick Fergus".