The Chess Variant Pages
Custom Search



Enter Your Reply

The Comment You're Replying To
Fergus Duniho wrote on 2019-11-24 UTC

Game Courier originally started out without any support for rule-enforcement. It offered a way to play games by email by generating diagrams from FEN strings that could be included in URLs. When I started working on what became GAME Code, I started with commands for automating some tasks, such as moving captured Shogi pieces off the board. In time, it became a programming language with the ability to be used for rule-enforcement. Because of the way that the language was added into Game Courier, it always remained optional rather than required. Besides that, some games could be too complicated to program, and using Game Courier just as a dumb board server would allow them to be played despite that. It also turned out that some people were a lot more interested in creating and trying out new variants than they were in programming, and they went ahead and created lots of presets without any programming.

As a programmer, my own preference has been for programmed presets. H. G. is also a programmer and might feel similarly as I do about the advantages of having programmed presets. I do want to make it easier to create programmed presets, but I also consider it important to still allow unprogrammed presets. This precludes the option of putting default code in presets. However, it could be helpful to have a GAME Code include file that includes default functions for a wide variety of common pieces. Another thought is to write new include files to require some values to be set before they are included. By require, I mean they would exit with informative error messages if any of these values were not already set. This would give programmers who include them reminders about what values might need to be set differently than for Chess.

This would still require some willingness to do programming, but it would at least make it easier.


Edit Form

Comment on the page Games on Game Courier page

Quick Markdown Guide

By default, new comments may be entered as Markdown, simple markup syntax designed to be readable and not look like markup. Comments stored as Markdown will be converted to HTML by Parsedown before displaying them. This follows the Github Flavored Markdown Spec with support for Markdown Extra. For a good overview of Markdown in general, check out the Markdown Guide. Here is a quick comparison of some commonly used Markdown with the rendered result:

Top level header: <H1>

Block quote

Second paragraph in block quote

First Paragraph of response. Italics, bold, and bold italics.

Second Paragraph after blank line. Here is some HTML code mixed in with the Markdown, and here is the same <U>HTML code</U> enclosed by backticks.

Secondary Header: <H2>

  • Unordered list item
  • Second unordered list item
  • New unordered list
    • Nested list item

Third Level header <H3>

  1. An ordered list item.
  2. A second ordered list item with the same number.
  3. A third ordered list item.

Alt text for a graphic image

A definition list
A list of terms, each with one or more definitions following it.
An HTML construct using the tags <DL>, <DT> and <DD>.
A term
Its definition after a colon.
A second definition.
A third definition.
Another term following a blank line
The definition of that term.