Game Reviews by Robert Price

I had the same question of whose king goes on the left or right, and I was about to suggest an alternative: The author calls for you to push two half-boards together by rotating one into place above the other. I was about to suggest reflecting it into place (and inverting the checkered coloring) instead; now you can let everyone's king start on the e-file but the two-player case is still just like FIDE chess.

Joining by reflecting is not so contrived. Imagine constructing the half-boards out of stiff cardstock or plastic, checkered on both sides so that the bottom-right square from each perspective is light. Use magnetic chess pieces in pairs so that they attract each other through the material. Bind several of these half-boards together with loops of string along the joining edge in an arrangement just like the illustration that opens the article. Now you join half-boards by flipping to two pages and ignoring whatever happens to lie in between.

But I said I was 'about to suggest'. That's because this arrangement causes the act of moving a bishop from the Green half-board to Orange, and then later to Blue, and then back to Green, to have the consequence of changing the Bishop's colorbinding because it has effectively been reflected an odd number of times. I still like the idea somewhat, but I think it is more important to have colorbound bishops than a symmetrical royalty-seating arrangement.

Since a properly-functioning SIR unit is colorbound, I am guessing that the author intends that a SIR unit is 'Berzerk' if and only if there is no friendly Invader (bishop) on the board occupying the same color of square. If this is the intention of the rule, then phrasing it this way handles situations that can arise after promotions.

I can think of three ways to restore a Berzerk SIR unit to normal operation:

1. You move your Berzerk SIR unit moves to a square of the opposite color, and under the command of your remaining Invader
2. You promote an Irken Soldier to Invader on a same-colored square
3. You are playing Invader Zim Bughouse (!) and you drop an Invader onto a same-colored square

I would love to help in coding Nemoroth in Zillions, just as soon as I can convince myself that it's possible at all. <p> As I understand it, piece <i>attributes</i> can not change the <i>appearance</i> of a piece, so a petrified Basilisk, for example, must be implemented as a different piece-<i>type</i> from an ordinary Basilisk (if you want them to look different), even though their non-voluntary behaviors are identical. <p> A far greater concern is multiple-occupancy. The usual approach is to declare a piece-type for every <i>combination</i> of pieces that may coexist on a space. Add to that the need to distinguish between petrified and fleshy, friendly and enemy (because such strange bedfellows may indeed come to share a space). And realize that pile-ups of more than two may easily arise... All of a sudden, Octi's library of 256 piece-types (<a href='http://www.zillions-of-games.com/games/octi.html'>http://www.zillions-of-games.com/games/octi.html</a>) is looking downright trivial by comparison. <p> From the game-logic standpoint, I intend to investigate the possibility of treating each of the 64 spaces similarly to a <i>prison</i> in the ZRF for Shogi. From the graphical standpoint, we can't afford simply to divide each square into a 3x3 grid of positions as I did for <a href='http://www.zillions-of-games.com/games/edgechess.html'>Edge Chess</a>, or people will need a magnifying glass to see the great graphics someone's going to make for the pieces. Instead, the cells of my prison will overlap, and with a well-defined order of precedence. I learned from <a href='http://www.zillions-of-games.com/games/platformchess.html'>Platform Chess</a> that the later-defined space will have its contents drawn before a sooner-defined space. This works perfectly. The front cell of the prison will dominate most of each space, with four more behind it kind of peeking in from the corners. Clicking-and-dragging a piece from the prison works as expected; if you grab a pixel that belongs to two spaces, Zillions assumes you mean the one it drew out in front. So if you want to move your Human that someone's gone and pushed a Basilisk statue onto, you can click on the visible portion of his puny form and command him, exactly as if two pieces really were present on the same space at the same time. <P> <b>Anyway,</b> multiple occupancy is what struck me as the big difficulty. Besides that, the non-simultaneous nature of the Go Away shout may not be pretty. One solution is to present a big pop-up menu consisting of all possible orders in which to push the victims (or only those which are substantially different due to the presence of basilisks). I would hate to have to use one move per push, because that's the sort of thing that weakens the computer opponent. <p> The evaporation of ichor is something that will just have to be managed by a ?Moderator who is programmed to scan the board and decrement all the ichor-plies by one. This raises another point... in order for ichor to be visible, it has to be a piece-type. I could do that by making a position behind each prison, where the ichor would sit. If the graphics designer wants to make ten different pictures of ichor, that's great, because each ply of ichor is going to be a different piece-type, and when the board is covered in broad sweeps of the stuff, the players are entitled to know which ichor is ickier. <p> Compulsion is tough to describe - it's slightly more complicated than the move-priority construct which in Checkers requires you to jump if able. But it is definitely doable. A piece is never compelled to make any <i>particular</i> move, only to make a <i>legal</i> one, provided the 'legal' constraint handles the details like preventing a piece within 2 of a Ghast from moving-without-fleeing. (note the beauty in Nemoroth on this point: The same *legality* constraint appies whether the Ghast is friendly or enemy; the only difference is that a piece within range of an <i>enemy</i> Ghast is compelled during its move generation.) Imposing move-priority and also (somehow) verifying that either a compelled piece was moved, or no compelled piece remains (after the immediate effects of the move have happened) comes very close to fitting the bill. <p> This sounds like an extraordinary game, and it certainly was presented in a marvelous way.