Check out Omega Chess, our featured variant for September, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Single Comment

Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]
🕸💡📝Fergus Duniho wrote on Thu, Jul 18 04:38 PM UTC in reply to H. G. Muller from Wed Jul 17 08:08 PM:

I looked into whether JavaScript has wildcard support, and I did not find any native function that supports it. But I did find an article called Wildcard Pattern Matching in JavaScript with a short function that does wildcard pattern matching by converting a wildcard pattern into a regular expression and then doing a regular expression match. Here is the function:

function wildcardMatch(text, pattern) {
    const regexPattern =
        new RegExp('^' + pattern.replace(/\?/g, '.').replace(/\*/g, '.*') + '$');
    return regexPattern.test(text);
}

To test it, I wrote a pair of loops to generate all the coordinates on a Chess board, and I had it display each coordinate only if it matched the pattern. Then I tested it with the patterns "a1", "*", "[abcd]?", [e-h]?", and "[aceg][1357]", and I got correct results each time. Since it's actually doing a regular expression match with some slight changes to the pattern, I also tested "([aceg][1357]|[bdfh][2468])" and got it to display all the black spaces.

But I guess that in the context of the I.D. we should above all ask ourselves the question "where will it be displayed, and what is the intended audience. The Diagram definition would normally be invisible to viewers of the page. And if this info would be displayed at all, it would not have to be displayed in the same format as in the Diagram definition.

There are two types of people who would be interested in looking at it. The first is someone with a knowledge of Betza code who finds it helpful for learning the rules of a game. The second is a programmer who wants to understand how it was programmed in order to be able to do something similar.

But if the board is represented as a FEN he would know exactly where to find the square, as a FEN is basically an image.

For each type of person who would be interested in looking at the code, I think that using a FEN-like representation of the board will add an extra layer that requires some interpretation for a full understanding. For most games that give the same piece different powers on different spaces, short wildcard patterns (or just regular expressions) could be used to distinguish light and dark squares, one side of the board from the other, or isolated sections of the board from the rest of the board. Only a game like Smess or Storm the Ivory Tower would need the whole board spelled out, and the code could be made more compact by grouping together squares on which the same piece has the same powers of movement. This could be done with a switch-case structure as I first suggested, or it could be done as a single regular expression that includes all relevant spaces. A switch-case structure, though, would still be helpful for providing a default value without the need to devise a wildcard pattern or regular expression to match the remaining spaces. It could just be applied to any space that had not matched any previous pattern in the sequence.

Note that by select-case in earlier comments, I meant switch-case, though it does look like BASIC does call it select-case instead, and I do also have background in BASIC.