Comments by HGMuller

This article is ready to be published.

Whether a piece can promote or not depends on its ranking in the piece list and the value of maxPromote. If you want a Pawn that cannot e.p. capture you just leave out the e mode. E.g. fmWfcF instead of fmWfceF.

Just some suggestions: 'Pithia' is a kind of high priestess. 'Abbess' is a female abbot: head of a community of Nuns.

You will find it in the alphabetical index under P. It can generate GAME code for rule enforcement / highlighting in Game Courier presets. But it has no provisions for uncommon rules like Frog kissing, or mixture of chess and shogi promotions. So it would be necessary to supplement it with code of your own.

Are you sure the diagram of the initial position is correct? There seem to be some Frogs missing, in an asymmetric way.

The Bishop might be weaker than the Elephant, and the Rook weaker than the Roo. I am pretty sure they would be weaker on 8x8.

The rules for game termination seem a bit illogical, and therefore needlessly complex. Easier would be to declare a loss when you do not have a Princess at the start of your turn, or a King at the end of your turn. (Combined with the usual checking rule that you are not allowed to do a move that causes an immediate loss.) I see no reason for making an exception for when the Princess is in check. For one, it is very unlikely that the King capture checks the Princess, so it won't affect the game much. And if you cannot solve the Princess check by converting a Frog when it should happen, you would just have lost.

Consensus values for pieces in Xiangqi are R=10, C=6-4 (opening-endgame), H=4-6, A=E=2, P=1-3 (unpassed/passed). So C and H only approximately half a Rook, and it depends on the game phase which of the two is somewhat stronger. And one should realize here that the Horse (Mao) is only worth half an orthodox Knight on a board as crowded as orthodox chess. (Which is quite a bit more crowded than Xiangqi, so that extrapolating the Xiangqi values to that higher density might give H=3 and C=7. That would then imply N=6, which indeed gives the correct relative value of R and N. So this suggests C could be worth slightly more than a Knight in a FIDE context.)

In games without drops the opening value of pieces is dominated by what they will be worth in the end-game. E.g. it is still much better to have a Rook in the opening than a Bishop or Knight, even though a Rook on a crowded board trapped behind his own Pawns is hardly of any use at all. But it is almost unavoidable that it will get to express its true power later in the game, so that hanging on to it is a good strategy. But for Cannons the end-game value is low, and rather than waiting for their potential to develop with time, one should try to trade them in the most-favorable way before that time.

To do a meaningful empirical test of the Cannon value you would need to do it with an engine that handles it well. Otherwise the value will be underestimated. ("A piece is as strong as the hand that wields it.") And handling hoppers well means you have to be very much aware when it becomes time to exchange them for other minors. If you do that too early you would not have exploited any superiority while it still existed; if you do it too late you will be stuck with them when they get nearly useless. To make the program seek trading at the right moment it is essential that it makes the hopper value dependent on the piece density, in the correct way. Which would have too be determined empirically too.

You could post a description of the rules on this website.

https://www.chessvariants.com/how.html

To add a new piece (say X / x)  to the GAME-code generated by the Play-Test applet you would have to add its move definitions at the end of the legdefs array, and supply functions X and x that return where in the legdefs array you have done that. Determining the latter is a bit of a pain; there are comments in the legdefs table that in parentheses indicate where the definition for each piece type starts, and you can then count the numbers appearing after that. Note that because the 'bare Pawn' is an asymmetric piece you would need different definitions for the white and the black one.

The move definition of a (white) FIDE Pawn is:

1  1  0  1     1
1  1  1  1     2
1  1 -1  1     2
1  1  0  2   16577 // pawn(1)
1  1  1  1     4
1  1 -1  1     4
0

The first 3 lines would suffice for the Shatranj Pawn; each line starts with the number of legs (always 1 here, as Pawns only have simple moves), the forward and sideway step size, the 'range' (= number of times the step can be repeated) and finally a code to indicate what the move can do (2 = capture, 1 = non-capture, e.p. capture = 4) and other details (like whether it is a virgin-only move). So the 4th line is the double-push, the 5th and 6th are the e.p. captures. For your bare Pawn you would leave these lines out. The final 0 indicates that the definition ends there, and that the moves that follow (if any) are for another piece. The move specifications for a piece should always end with such a 0.

In the example I copied this from the white Pawn was the first piece, so it starts at element 1 of legdefs. The special moves of that Pawn start at element 16 (as the three normal moves each take 5 numbers to describe). That means that just behind legdefs there is a line

def P cond #0 1 16;

that tells the code that the move definitions of piece P start at 1 (normal moves) and 16 (special moves = moves having side effect, such as creation of e.p. rights, or disappearance of pieces elsewhere). For pieces without special moves the latter number should always be 0. So for the bare Pawn you would have to add a line there like

def X cond #0 ... 0;

where the ... is the location in legdefs where the move definition starts.

They will only be empty until an editor approves them.

I am not an editor here, so my words carry no official weight. But I think the article is annoyingly verbose and digressing. E.g. the introduction section contains no information related to the variant at hand other than the e-mail address of the author (which people can already get from the author's profile) and two external links. The remaining 85% discusses the history of Chess, what other chess variants the author likes etc. I don't think an article about a specific chess variant is the proper place for that.

Dwelling on the obvious, such as "The unique units seen in chess variants are called fairy pieces" is just diluting the information one would be interested in. OTOH, in the Setup section it would be more useful to write the coordinates of the starting squares of the pieces, rather than their number. Most readers will likely be able to count, but it would be nice if they could unambigously associate the names with the images at that point. Although I admit that (perhaps with the exception of Prince / Princess) most images speak for themselves. But if the image is supposed to be selfexplanatory, why waste words on the fact that the pieces of a player occupy 3 ranks?

There doesn't seem any need to explain what e.p. capture is, and why it was introduced during the evolution of chess to its current orthodox form. Scrolling through pages and pages of diagrams containing only information everyone knows is pretty annoying. Most articles on CVP would simply state "King, Queen, Rook, Bishop and Pawn move as in orthodox Chess, including the initial 2-step move for the Pawn and e.p. capture". The same applies to castling, where if you want to be truly elaborate you could still mention that the King moves 2 squares towards the Rook, if you think "moves the same as in orthodox Chess" was too difficult to understand. This would get rid of 17(!) diagrams, and gets the reader to the interesting stuff immediately.

There isn't any need to explain what checkmate or stalemate means. Spending a diagram (3 times!)  for illustrating what you mean by "adjacent square" also seems overdoing it.

Typographically, the article now uses headers for the descriptions of the individual pieces of the same 'level' as those used site-wide for the article's main sections (Introduction, Setup, Pieces, ...). While they are all supposed to be sub-sections of the Pieces section. There is an extra redundant header "Unit Moves and Captures", which repeats what "Pieces" is already supposed to convey. Rules and Notes sections seem to be missing entirely; one would have expected description of the check / checkmate / stalemate (if it would have to be given at all) to appear in the Rules section, not in the description of the King's moves. Other draw conditions than stalemate (repetition, 50-move) are now not mentioned at all. It would probably suffice just to mention that all these rules are the same as in orthodox Chess.

As to the variant itself: it always saddens me when people use a well-established piece name (such as Griffon) for another piece. As if there isn't already enough confusion.

When a Sorceress, Mage or Archmage swap a Pawn to last rank, does that Pawn promote? Does the swapped Pawn count as having moved? Would a Pawn swapped back to 3rd rank regain its two-step move? BTW, it also seems a bit superfluous to have practically the same diagram for illustrating the swapping in 3 places. It would be better to discuss the swapping once (e.g. in the rules section), and then just refer to that from the descriptions of the pieces that can do this. It is not clear to me why the description of the swap has two side-by-side diagrams. On supposes that the second diagram shows the position after the swap, but then it is illogical that it still has an arrow in it. I would think that a single diagram with a two-way arrow would suffice. In general people can be expected to know what 'swap' means, so devoting a diagram is already quite generous.

It's not clear what the rules of promotion are in this game.

Since about three quarters of the article's text is devoted to explaining just that, this is a bit disappointing. The Rules section is almost entirely devoted to explaining when you must promote, and explains contageon; and both the Pieces and the Notes section both mention what promotes to what. So what exactly is not clear about them? Is it that it should be stated explicitly that there never is any choice what to promote to?

The Pieces section is slightly awkward to read since the promoted forms sometimes show up before the unpromoted pieces and they aren't arranged in any obvious pattern.

OK, I cured this by sorting the piece descriptions from weak to strong, and by putting the promoted versions near the end. For each unpromoted piece it now also mentions what it promotes to.

I am starting to suspect that this summoning business will sort of spoil the game. Because you get the Demons back whenever you lose them, at the cost of only a tempo. The most effective strategy thus seems to simply keep summonig them in a developed location, and immediately send them on a kamikaze mission against whatever opponent is in their path. Even a Pawn is usually worth more than a tempo. You would not even care whether the square you summon them on is in a location that the opponent attacks once, as when the Demon(ess) gets captured you recapture with the Mage or Sorceress, and would still have traded the indestructible Demon for some opponent material.

There is nothing wrong with the mechanism of summoning itself. What wrecks things is that you automatically get the Demon back in hand when it gets captured. That effectively makes it an 'iron piece'. Giving the opponent two moves, knowing that he has those, is too costly, though. In the opening you might get away with it, but in a typical middle-game position the opponent would use those to make a hit-and-run capture.

Furthermore, summoning a Demon for free seems too easy; in horror stories one typically has to make some sacrifice as part of a summoning ritual. Using this concept the following might work: to summon a Demon, the Mage should first capture a friendly piece. That will then 'activate' him for summoning a Demon in the next turn. But depending on what the opponent does in his turn, you might pass on the opportunity to summon, and do something else. That would waste the opportunity to summon, and you would only regain it by capturing another friendly piece.

I now also upgraded the general Diagram script to get more realistic piece values for this variant. It had a rather complex algorithm for determining the contribution of promotability to the piece value. Which would determine the ease of promotion based on counting the fraction of moves that would enter the promotion zone in (randomly generated) test positions, and assume the product of this ease and the promotion gain would determine the probability that this piece would indeed promote during the game. (Assuming that pieces with a less attractive promotion prospects would have to be traded away to clear the way for that.) This of course gave rather non-sensical results if there was no promotion zone at all. In that case the Diagram now assumes promotion on capture for promotable pieces (as specified by maxPromote). It then adds 50% of the promotion gain if this is positive, and subtracts 10% of the devaluation if it is a demotion (assuming there are ways to avoid it, but that this avoidance does make the piece less useful).

Use the "Try it" link in the Notes section, and start playing for black to see how it is done.

For larger board sizes you can try the general Checkmating Applet, upto 16x16. That also makes it more obvious what the general method is, for driving towards the edge, and then towards the corner.

Because you press the Piece1 or Piece2 buttons only once?

Unfortunately it is not very easy to include the bent riders. For one, their retrograde moves are not the same as their normal moves. The current program assumes they are, and uses the same move generator for both. It would also raise the design problem for how to indicate the bent slides.

The current move-definition pane does allow you to define limited-range sliders such as R2, btw. Just define a regular Rook by clicking the W squares twice, and then for each paths click the H square to cut off the slide there. Usually the ability to jump doesn't have much use at this stage of the game; both WD and R2 can force checkmate in the same number of moves. It is just the statistics that changes a bit.

So R2-then-B can certainly force checkmate, as R2 already can. B2Z reaches a subset of the B2-then-R destinations, and it is also able to force checkmate. So I expect the B2-then-R to do it even faster, as the fact that it cannot leap directly to the Z squares should hardly hinder it.

Good catch. This problem surfaced everywhere after a change in the general Diagram script. I did fix it in most places, but apparently forgot to fix it here. It should work now.

(The reason was that this applet abuses the routine WeirdPromotion, which would be called for every move, to invoke the routine that fetches the best move from the end-game table and play it. But at some point the Diagram script started to call WeirdPromotion twice, also once to figure out whether it should allow the user to choose a piece. This to also support unexpected promotions that involve a choice. So the WeirdPromotion routine included in this applet should be more careful now, and only invoke the routine for playing a move when it has not already been done.)

My guess is that forbidding kings to face each other would not help. Exposed kings get checkmated very quickly in Shogi. So when the manage to cross it is always surrounded by a group of friendly pieces, from which they are chased out, and then again get new pieces dropped around the to survive.

I could imagine that the Kamikazes present the same problem as Pawns, when you are allowed to drop more than one of those in the same file.

There is one caveat: R2 (and WD) lose their mating potential on 12x12. Adding Camel moves cures this, even up to 16x16 (the largest the Applet can do). So I have little doubt R2-then-B would have mating potential there.

For B2-then-R very large boards actually make it easier. Because from a large distance you could use the R legs as if the piece were a Rook. Even an invulnerable one, because the bare King cannot approach it. And the F step can be used to tighten the noose around the bare King. So it should be a very easy checkmate.

This is an interesting idea. It also would make kings a very large threat to each other, when they get close in ranks. Because they create an artificial board edge against which the opponent could be checkmated. Or could provide protection for a general dropped in front of the enemy king.

It woould be worth it to apply this in normal Shogi, to create a variant 'Impasseless Shogi'.

Impressive! So far the complexity of this game even deterred me from reading through the rules.

The way it is described is a bit confusing. Basilisk squares and Ghast squares are not really different types of squares, and what happens there just follows from the proximity of the Basilisk or the Ghast. They do not define additional game state. For ichorous squares, the amount of ichor on a square is part of the game state, however. So there really are many different types of ichorous squares. Since having multiple pieces on the same square is normal procedure in this game, Ichor might as well be considered an additional unmovable and unpushable piece. For over-the-board play I would use stacks of Draughts chips for representing Ichor, and just unstack the topmost on every square at the end of each turn.

A suggestion: wouldn't it be 'cleaner' to consider the go-away move a simultaneous operation, if you abandon the idea of having the moving player specify an order? Just displace all adjacent pieces first, and only then calculate the side effects of each from the new position?

[Edit] While reading back through the comments, I see that Adrian King had already proposed the same, concerning the Go Away.

It doesn't say how the Bomber moves when it doesn't explode.

Is this game winnable with a reasonable advantage? I am not sure even a Starship could catch a Hideout.

The Checkmating Applet cannot do bent riders like Osprey. But it can do a truncated leaping version, like DC. And a pair of these does have mating potential, on 10x10. In the theory of 3-vs-1 mates discussed on the Applet page the Osprey would classify as 'potent', since it can switch its attack from c1 to a1 in a singly move (e.g. f2-f4 or f2-d2). This means it can execute mates in combination with almost anything else that is not bound to the same color.

In fact an Osprey can drive a bare King into a corner together with almost anything on any size board: positioned on an edge it can dynamically confine a King in a corner with the help of its own King. With moves to spare, which can be used to invoke the additional piece.

Some Nemoroth pieces are 'color blind': they capture or otherwise affect friendly and enemy pieces in exactly the same way. The only effect of their allegeance is then which player is allowed to move them. But when they are petrified neither player can move them, and in effect they become neutral. An alabaster and an obsidian Leaf Pile are really the same piece, from a game-theoretical point of view, and that also holds for petrified Wounded Fiends. Likewise petrified Go Aways are all the same. And since they lose their special power on petrification, they are also the same as a Mummy. And they only differ from petrified Humans when we adopt the rule that petrified Humans promote to Zombie when pushed to last rank. Which would also make it necessary to distinguish petrified Humans by color.

Petrified Basilisks remember their allegeance because of the Basilisk's asymmetric move, which is preserved in the way it sees. Ghasts have a more severe effect on foes as on friends.

You are right, something is not as it should be here. (So thank you for reporting it!)  hlalfN gives a 4-step orthogonal move, while hrarfN gives a 4-step diagonal one. While logically they should just be each other's mirror image.

I will have to figure out why exactly this happens. My first suspicion is that I added code to swap the meaning of l and r after a left-handed chirality-breaking step. At an early stage of designing the notation I thought this would be helpful, because it means that you could simply write afrN to mean hrafrNhlaflN. But later I realized that the modifiers q and z could be used in continuation legs as placeholders for l or r, meaning deflection in the same or in the opposit direction as the previous leg. This would be a natural generalization of the original Betza meaning of circular and zig-zag.

I suspect that in implementing the latter, I somehow interfered with the original idea of making the meaning of l and r itself in continuation legs dependent on context. I will check this out.

Anyway, the recommended notation for what you wanted to do would be aqfN, a first Knight step, followed by a 45-degree bend in the same direction. Where the original direction was defined by the way the oblique move was bending when you consider it an orthogonal move followed by a diagonal one.

In my opinion riders based on a leap other than a king step are very awkward to play with. That holds for NN, but also DD and AA. It is never intuitively clear whether the path between such a rider and a distant target is blocked, especially when the blocker is far from both. For me that makes them annoying pieces.

I guess the problems with tactically non-quiet opening positions can be avoided by putting all pieces more valuable than a Nightrider two ranks behind the Pawns. Then the Pawns will block any Nightrider attacks on them. And of course make sure all Pawns and pieces directly behind them start protected.

There is nothing 'unknown' about the set of prime numbers; it is in fact very well known that there is no such thing as a 'complete' set of them, as the set is infinite. There exist simple (albeit inefficient) algorithms to determine for any given number whether it is prime or not.

It is also a misconception that the presence of a Huygens would make a game unsolvable due to the properties of primes or any other of its properties. E.g. it is very easy to prove a game with a starting position of King + 2 Queens vs King + Huygens on an infinite board is won for the Queens. It is even possible to give a detailed algorithm for how to do this, in a number of moves that only grows logarithmically with the distance between the Huygens and the Kings. If the Huygens has the first move, this number can of course be made arbitrarily large, by moving the Huygens far away after it runs out of safe checks (because the King approached it).

All this would still be true if the Huygens was a Rook, rather than a subset of it.

I am not sure why you refer to 'fast castling'. Is that the type of castling proposed by Kevin Pacey in his wide-board variants? Neither the Diagram nor the GAME-code produced by it do support such castling.

The Cannon would have to be in the partners set to allow castling with it. How far the King moves on castling is defined in the moves of the King; castlings are defined in the legdefs table as two-leg moves, the first leg being the slide that has to be used to find the partner, and the second leg (only attempted when a partner could be reached) indicates the leap the King should make. Your presets appear to define both 2-step and 3-step castlings for the King.

A problem is that the castling moves you define on the King are not critical w.r.t. the partner they use; any piece in the partner set would do. So it would not be possibe to only allow 2-step castling with a Rook, but not with a Cannon.

I think this is unlikely. I have never seen the Edo-era description of Tenjiku Shogi, but I do know how such descriptions looked in general. They basically showed a drawing of the initial position, where each square contained a drawing of the way the piece moved, with the kanji of the piece name in the center. Sliding moves would just be radial lines, and it would be immediately clear whether the Lion Hawk also had orthogonal slides.

Only complex moves, such as the Lion, would not be obvious from the drawing, and would be described by an additional line of text. I once have seen the picture for the Teaching King (a piece from Maka Dai Dai Shogi); it had lines in 8 directions, each with 3 perpendicular line segments crossing it for indicating the multi-captures of teh Lion Dog. (And the text line then said it would move like Queen or Lion Dog.)

It appears the CVP website has been switched from http to https. Since the piece images are on my own website, which is http, the browser now refuses to display them.

In this case I can easily fix it, because the same piece set probably is somewhere on the CVP website, and if not, can be uploaded as user graphics. But the same problem will now manifest itself in other places. In particular, the 'Diagram Editor with Scalable Graphics' will be broken. This refers to a C program on my own website thar dynamically generates piece images according to specification, and now also is no longer accessible. So far Fergus did not manage to compile the same program for the CVP website, so that it could run there.

[Edit] Interesting. On my PC with FireFox all this works. Perhaps I have switched off this pedantic security feature there; I don't really remember.

It appears that access to the render engine is now permanently boken for everyone using a browser with standard security settings, because of the move to https. It therefore becomes important to migrate the engine to the CVP website. So can we revive this effort?

If I knew what Linux version exactly is powering the CVP server, I could install it myself in a VM, and have a try at compiling the rendering engine. I seem to recall it is some version of CentOS (although that is not mentioned in this discussion?).  The renderer is based on XBoard's board rendering code. I do think XBoard is available for CentOS, which means it must be possible to compile it, or figure out how it was patched by the maintainer to make it possible to compile it.

Are you sure this is the problem? Because what you describe is what I already do. (That is, I set it to the weighted average of the value of all pieces, where the weight is equal to the value. This because I assume that stronger pieces will be moved more often than weak pieces. And I subtract 30% of the variation in this, because I assume the opponent will adapt his move choice to make the imitator less useful, if he can, by moving more weak pieces than he otherwise would.) When you click the 'move' header in the piece table to see the values, you will see that the imitator does have a finite weight.

The procedure could be a bit improved. (E.g. I now take the average of all pieces, while it should really just be opponent pieces. But if that would be very different the game is decided anyway. And it does not take account of an imitator's fixed moves, if it had any (e.g. if you define WfI).) But whatever flaws it has now, it should never lead to thinking the imitator is worthless.

Perhaps the problem is simply that the AI doesn't search deep enough to see that an Imitator can be easily trapped.

Where can I create my piece set?

For what purpose? If you want to use your own piece graphics in the Interactive Diagram you can just upload the images to the page belonging to your article, and point the Diagram to the corresponding directory.

You cannot use the variable 'checked' the way your code does (in the functions K and k), because the betza.txt include file does the mate test before the check test (which sets this variable). As a result the variable 'checked' is undefined during the mate test, which apparantly is interpreted as not being in check. So the mate test thinks the King, still in its initial position, can use its initial jumps to escape the check, and hence does not see it as mate.

There currently isn't a good alternative. Perhaps all initial moves of a royal piece should be forbidden when in check. Castling is forbidden when in check, but this is implemented as a property of the castling rather than of the fact that it is defined as an initial move. The mechanism by which this is implemented is that castling creates e.p. squares along the path of the King, including the starting square. And that any move to an e.p. square will always (locust-)capture the royal piece, if that was the last-moved piece. (Otherwise only e.p.-capable pieces would perform the capture.) So what really should happen here is that the initial King moves create an e.p. square on the original King location.

[Edit] This e.p. trick for detecting moving out of check after the fact unfortunately does not work in general: a King could make a leap towards a hopper, and therby activate the hopper for capture to the square it just left. While it would not have been in check by that hopper if it had stayed there. For castlings this cannot happen, as there will also be a Rook in between King origin and any piece that would be standing outside of the Rook. Although a bent hopper might be activated by the Rook. An enemy Grasshopper outside of the Rook would attack the Rook after castling, which could lead to the accusation of having castled through check. Or, when the King would end next to the Rook's original square, to moving through check on its destination square, which would no longer be checked after the castling.

I would expect it to be weaker against more different pieces of roughly the same value. Because it allows the opponent more opportunities to do a move that makes the Imitator harmless in its current location.

For now I have solved this as follows: when a move is indicated as an initial one, it will still be rejected if the mover is not virgin. But if it is, it will be tested whether the mover is in an array inocheck, which by default is set to (K k). If it is, this will add the origin of the move to the set of e.p. squares. And hence consider it illegal if that square is under attack after the move. If you want to forbid any other piece to use inital moves when attacked, or when your royal does not have the label K, or you have multiple royal types, you could set the inocheck array to contain the types you desire.

As dicussed this can in theory fail in the presence of hoppers. Although it is extremely unlikely that you would ever want to play an initial move designed to get you to safety to stay in the path of a hopper. Anyway, it seems to solve the problem with the game you mentioned, as this now says 'checkmate!' above the board. It is also not possible to have both initial moves that can, and that cannot move out of check on the same piece.

About your implementation of that preset: it is not necessary to build the in-check dependence into the move list of the King that is used when the argumet to the K or k function is 0. This call only has to generate moves with an implied side effect, i.e. a change of the board state not explicitly expressed in the move eneterd by the user. This is used when playing out the moves of the game for the purpose of setting up the current position, to make sure the side effects are properly applied, but where there is no need for testing the (pseudo-)legality of the moves. As this would presumably have been done before the move was allowed to be appended to the game. Normally the only moves that do have side effects are e.p. capture and castling. So there is no need to generate other initial King moves than castling in that case; the extra moves you defined do not have side effects.

Indeed. There is no need to generate anything else there than the castlings. And for castlings the code would know that you cannot do those while in check anyway. So you can simply return the index of the castling moves in legdefs in the second case.

There is no real save function. Under the buttons in the AI bar there is a text box where the game record will appear, and you can copy-paste that to a place where you want to store it. You can paste such a game back into that same text box to load it into the Diagram again.

I am not sure that this is feasible. Alice Chess is basically a 3-dimensional variant (with 2 levels), where all pieces have two-leg moves where the seccond leg changes level, and which are lame or (locust-)capturing by their orthodox move in the first leg. But the code in the include file used by the wizard assumes 2-dimensional boards.

Of course you can map the 3d board onto a wider 2d board (16x8, or perhaps 18x8 to allow a dead zone in between the boards that even Knights cannot cross, deleting the squares in that guard zone from the board in the Pre-Game code). And then define all moves as 2-leg moves that have a (dx, dy) = (+-18, 0) leap as second leg. There is no way to describe that in Betza notation, so the Interactive Diagram could not be used to generate the legdefs array with move definitions. But you could of course write that by hand. Either from scratch, or by adapting the code generated for orthodox chess, adding a second leg to each move. E.g. the Bishop in orthodox Chess would have

1 99  1  1     3 // bishop(104)
1 99  1 -1     3
1 99 -1 -1     3
1 99 -1  1     3
0

and this would have to be changed to

2 99  1  1     3 // bishop(???)
   1 18  0     1 
2 99  1 -1     3
   1 18  0     1
2 99 -1 -1     3
   1 18  0     1
2 99 -1  1     3
   1 18  0     1
2 99  1  1     3
  1 -18  0     1
2 99  1 -1     3
  1 -18  0     1
2 99 -1 -1     3
  1 -18  0     1
2 99 -1  1     3
  1 -18  0     1
0

And you would have to determine the new starting index for Bishop in this array, and put it into the B and b function definitions instead of 104.

I am not sure whether this would have the desired effect for castlings and e.p. captures, though. (Or indeed how the latter are supposed to work in Alice Chess in the first place.)

You write the variant does not have piece drops, but then you write: " The player who can no longer move or drop pieces loses".

It is not clear what you mean by 'situation' in the description of the repetition rule. Is that just the same board position, or does it also mean the same player has to be on move? When you write the 'after it occurred twice no one can repeat the position again' you suggest that it does not matter who has the move. Because one it does, only the player that created the position for the first time could recreate it.

And about the absence of a 50-move rule: it it really your intention that when an endgame of King versus King results the players should go on until one of them gets stalemated by the ban on repetition? That seems awful.

The ascii diagram of the initial position seems redundant. And wrong too, because there is a Templar in there.

You should ask an editor that.

I thought the changes I made on August 1 fixed that? As long as the game you try to past is legal and unambiguous, of course.

Chances that people want to play a variant are very small. Chances they would want to pay for it next to zero.

There are two variants I know of that were patented. In the U.S.. (Patents do not automatically apply world wide.) In the U.S. you can pretty much patent anything; whether the patent is valid is to be determined in the court cases that challenge it. That makes them cheap; there only is a (yearly?) registration fee. In Europe it can take tens of thousands euros to do the due diligence get a patent approved. (And the result of this in case of a chess variant would most likely be that it gets rejected, for lack of novelty.) As far as I know both U.S. patents expired before anyone challenged them, because the inventors got tired of paying the fees.

To make sure there would be no legal issues for this website, there was a ban on using words that reminded of the variant in any posting here.

I am not sure how you could make money out of a chess variant. Unless it requires special equipment, which you sell. Patents are more suitable for protecting equipment than ideas. Chess variants typically only require a board and pieces, though. Boards can be made from cardboard and paper, and pretty much anything could be used as pieces. (A wide selection of high-quality unorthodox pieces is already commercially available, both in wood and plastic.) There is no way you could prevent people using these at home.

Of course you could set up an internet server where the variant could be played on-line. And ask a fee for regestering there. It seems a good way to make absolutely sure no one would ever want to play it, even in the extremely unlikely case that the variant would have the potential to become popular on its own merits.

If that is supposed to be meaningful to players who play the game, then I m really curious who you expect to play...

I had not scrutinized this variant much, because I dislike games were pieces change their move too much. But now that I give it a closer look, I start to wonder whether it is actually winnable. The version where the king moves as a normal avatar seems completely hopeless in this respect; you just keep shuttling your royal avatar between high-mobility squares. How many avatars should the opponent be ahead in order to checkmate a bare royal?