Check out Janggi (Korean Chess), our featured variant for December, 2024.

Enter Your Reply

The Comment You're Replying To
🕸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.


Edit Form

Comment on the page Storm the Ivory Tower

Conduct Guidelines
This is a Chess variants website, not a general forum.
Please limit your comments to Chess variants or the operation of this site.
Keep this website a safe space for Chess variant hobbyists of all stripes.
Because we want people to feel comfortable here no matter what their political or religious beliefs might be, we ask you to avoid discussing politics, religion, or other controversial subjects here. No matter how passionately you feel about any of these subjects, just take it someplace else.
Avoid Inflammatory Comments
If you are feeling anger, keep it to yourself until you calm down. Avoid insulting, blaming, or attacking someone you are angry with. Focus criticisms on ideas rather than people, and understand that criticisms of your ideas are not personal attacks and do not justify an inflammatory response.
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.
Here is some preformatted text.
  This line begins with some indentation.
    This begins with even more indentation.
And this line has no indentation.

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.