Ratings & Comments

@ Aurelian

I hadn't realized there might be confusion over the stated rules for the Ship and Archer, or I might have gotten back to you sooner. The Ship in this game works likes a Cannon, but it can also move (and capture) like a Guard (aka Man, or Commoner). Similarly an Archer in this game works like a Vao, but it can also move (and capture) like a Guard. Thus, the Ship and Archer in this game are novel sorts of compound pieces, to my knowledge.

Note that recently the first ever game (to my knowledge) of Gamma2 Chess was played and finished. Also, I revised a previous comment (the part about my estimates for the piece values of the SH and AR).

The AZ is a quite strong piece. It does not have mating potential, but is powerful enough to drive a bare King into a corner on boards up to 9x9. So it can pretty much checkmate in combination with anything. Even with an Alfil.

Something may be wrong with the 'game review' page (linked to from 'What's New' page). No reviews show at all, but rather some sort of coding(s).

Okay, I've corrected the link to use the supported parameter instead of sortbydate.

The Camel and the Zebra never seemed very useful to me. Combining a Camel and a Ferz gives us the Wizard which functions well in many variants, from Wormhole Chess to TenCubed Chess. I wonder if combining a Zebra and an Alfil would improve this game? Sample endgame provided below - the diagram has been cut down to six ranks.

WHITE wins by 1.Nc2 check Kb1 2.(Z+A)e3 mate.

Well, the boards are HTML tables, so rotating them doesn't seem to be an option. I also don't see any point in it; just rotate the board back 45 degrees, and it becomes a normal board. You just have to keep in mind that the Betza angular specification have to be a bit different, for pieces that are not totally symmetric.

As to hexagonal boards: perhaps. It would be possible to build a table on a grid of half-width or half-height cells, an merge two cells bordering on their long side into one by colspan="2" or rowspan="2" parameters. And do that in a masonry-like pattern. That would give the same topology as a hexagonal board. By suppressing the borders and specifying transparent square shades, you could the use a whole-board image with true hexagons as background.

The script just refers to the table cells by HTML id of the <td> elements, and would not have to know about the 'skewed' layout. The only thing that would have to be changed is the routine that constructs the table. You might need more parameters than just files and ranks to describe the board. E.g. the files and ranks parameters could define the left and bottom sides of a diamond, and a third parameter could specify how many 'short diagonals' should be left in the center. (Where the default 0 would give you a rectangular board).

Move descriptions would of course look strange and asymmetric, like frblvvssQ for a rook-like move along 6 rays. AFAIK  there is no hexagonal Betza notation.

I decided to go with color.

Is there any chance of having interactive diagrams for hexagonal or 45° rotated square boards?

@ Fergus

Something may be wrong with the 'game review' page (linked to from 'What's New' page). No reviews show at all, but rather some sort of coding(s).

This is a nice game. It seems to have a theme of rook + weaker piece compounds. I wonder why the board isn't 15x10 to make room for another knight, and have a nice 3:2 shape like Courier Chess. An alternative enhancement would be a pair of camels on d1 and k1 and a camel-rook on i1. That would make more sense of the 10 rank board.

I found color versions of the artwork, and since the artist died over 100 years ago, I assume they are also in the public domain. But I'm having trouble deciding which I prefer. I'm wondering if maybe the color makes the images too distracting. So that others may compare them, the color images will be used if you are signed in, and the black and white images will be used if you are not.

Games with a rank label of 0 don't display correctly, as can be seen in Apothecary Chess Modern. It looks right if the rank label 0 is replaced with something else

Another game with this problem is Rococo

I have been at work making our 404 page the best in the world. The main strength of our 404 page is the ability to search the database and offer appropriate suggestions. When I was looking at examples of what are supposed to be the best 404 pages, none of them did this, and their main strengths were only in graphic design. I won't say ours has the best graphics. I did limit myself to public domain art instead of hiring an artist, and there are lots of other 404 pages with good art. But the art I chose was suitable for a 404 page and a good match for our site. So, I'm happy with it.

You could increase the cap of instances of one type for trackPieces to four without much trouble.

Well, that is actually not so easy, because then you would have to examine all entries to see which one has to be replaced, as all others could contain valid data for the other pieces. With two I only have to examine the first entry, and if the piece is not there it must be in the second.

If pieces were numbered, rather than piece types, life would be easier. The piece encoding could consist of a color bit, a virgin bit, a number of bits for types (now 7, to allow 511 types, which is perhaps a bit generous), and 2 bits for an instance number. Then the type could still be examined by masking out the type bits, but type+color+instance number could be used to index the location[] array, where each instance would then have its private entry, which would be adapted when that instance moves. The spell-zone marking would then have to loop through all 4 instances, and check if the colored type is indeed in the recorded location (since we don't track capture), and mark its spell zone if it is.

The problem is that I use many of the bits in the board[y][x] elements to indicate markers; the old move-entry system used that to know whether a destination click would have to trigger a castling or e.p. move, or whether it was a locust square. So I would have to be careful not to collide with these bits.

The work-around of defining two (identical) types of Chariot Soldiers, promoting to two (identical) types of Tertarchs is an extremely simple one, though. It would only require that both types will get their spell zone marked. I could add a parameter trackedTypes=M for that, which in combination with trackPieces=N would put spell zones around type N to type N+M-1. And leave it to the user to make sure there are never more than two instances of each sub-type. That would only require me to put the spell-zone-marking code I have now in a loop (with M iterations) over these piece types.

Does anything look amiss here?

   2 setconst T Tusker
   3 setconst t Tusker
   4 setconst J JumpingGeneral
   5 setconst j JumpingGeneral
   6 setconst M Minister
   7 setconst m Minister
   8 setconst H HighPriestess
   9 setconst h HighPriestess
  10 setconst E Elephant
  11 setconst e Elephant
  12 setconst Y WarMachine
  13 setconst y WarMachine
  14 setconst L BattleEngine
  15 setconst l BattleEngine
  16 setconst K King
  17 setconst k King
  18 setconst P White_Pawn
setconst p Black_Pawn
  19 setconst G Guard
  20 setconst g Guard
  21 setconst N Knight
  22 setconst n Knight

You're missing a semicolon after one line.

I played this on brainking.com many times and it is fun, even if the outcome is more dependent on luck than on skill.

@Adam: I see that you are using your own markers. Beware that I have added a new marker (markerFFF000.png), which the betzaNew.js script uses for indicating moves of a piece that has active burning defined for it through the captureMatrix in the move diagrams. It then also indicates the blastZone on hovering, by making the background of the burned squares around the indicated target grey.

BTW, the tracking, and thus the marking the spell zone of the indicated piece, currently only works correctly if there are not more than two pieces of that type in play. Otherwise it will loose track of some of the pieces. The current way I use for tracking just keeps two locations (in loc[coloredType] and loc[coloredType+512]), of the last two pieces of that type that were moved during the search. (And it then only marks the spell zones around those.) Now this is fine for Mitsugumu Shogi, but in Suzumu Shogi there can potentially be 4 Tetrarchs. This is of course unlikely to happen in a real game, so perhaps we should not worry about it at all.

I can switch to a more robust way of tracking, able of handling an arbitrary number of pieces of the same type. This would cause a slight slowdown, though. Which is a pity, as almost no game would use it. An cheaper alternative would be to allow requesting spell zones around more than one piece type, so that piece types of which there can be more than two instances can be artificially split into two identical types. The location of each piece is tracked anyway, it is just a matter of marking the squares around the designated types before every move generation, and pieces where only a single type cause spells would not experience a delay by this.

It would even be possible to mark the spell zones of different types differently, e.g. as nodes | (1<<(24+K)) for the Kth spell zone. This would allow, say, freezing and burning in the same Diagram. The test for being in the zone would than have to be (neighbors[sqrNr] & 0xFFFFFF) == nodes. I wonder if all that complexity would be worth it, though. I am not even aware of any variants that would need it.

I'm trying to use the fairychess include file to enforce rules with this preset and it's giving an error I can't figure out.

The fn built-in function has not been given a valid function name or lambda function.

As well as I can tell, I have provided the proper functions for every piece.

It would be a misconception to think editors communicate amongst each other by any other means than the comments you can read here...

Well, whatever the case, the issue is settled. I'll let you get back to working on the Interactive Diagram code.

The current description is not so good. Can an editor please change it to:

"The total distance a piece can travel is limited."

Many thanks.

Ah OK, I see it now. Burning is configured through the captureMatrix, which makes it piece-type selective, both w.r.t. attacker and captured piece. But the size of that matrix is of course dependent on the number of participating piece types. I had added a few types since the first version of the Diagram, but had forgotten to extend the row for the Fire Dragon with more burns, so that capturing the few pieces latest in the list did no longer trigger burning.

I am still not completely happy how this works, because the way the moves are encoded as burns now excludes they could also promote. So it would be impossible to burn on the move where the Queen promotes to Fire Dragon, even if I wanted that. Pehaps I should change the standard script such that when a promotion occurs (which could also have be specified by the capture matrix) that it consults the capture matrix (again) to see if burning was specified for the promoted piece making that same move.

BTW, I now altered the promotion of the Diagonal Jumper (= Bishop General) from Minister to a 'Lion'. Which in this case does not have the power of the Chu-Shogi Lion, but only a (two-step) area move. It seemed more logical to use that move than to give it the usual KNAD. The Minister was an embarrasingly weak promotion for the Diagonal Jumper, as it is worth less. (But this promotion could still be useful, as a Minister has mating potential, which the color-bound Diagonal Jumper lacks.) Now it promotes to a strong piece (the Diagram values it as nearly a Queen), which could contibute to its value.

Also, can you approve the Rules pages for Suzumu Shogi and Mitsugumi Shogi?

I don't know how to approve articles; I limit my activities as editor to inserting Interactive Diagrams in existing articles, and improving the infra-structure for doing this. I am the only editor working on this task, and it doesn't seem a good idea to reduce the time I can spend on it by also taking up tasks that other editors can do.

I ask because I'm trying to figure out how to implement pieces with non-displacement capture. Is it possible for a function to relocate a piece after it captures?

The pawn functions use remove to handle en passant capture. This is the only built-in function that normally has an effect, since functions and expressions are normally just supposed to return values. To achieve any other effect in a function, you can call a subroutine from it, and the subroutine can cause any effects you like. But if your interest is in non-displacement capture, then remove should be all you need. See the Breaking Logic section of the fairychess include file tutorial for details on how it is used in the pawn functions.