Comments/Ratings for a Single Item

I adjusted the code to account for rank and file markers and borders around the board, but the board is too squat on Android Chrome. However, I will stop working on it for tonight.

It looks like a combination of two issues were causing this problem. One is that this diagram had rank and file markers around it, and I haven't done anything to adjust the height and width of the table cells with the rank and file markers in them. The other is that I was using cqi and cqb values in browsers that were apparently treating these units as zero. So, when I first got rid of the file and rank markers, the whole board disappeared on Chrome in my Android phone and on any browser on the iPhone. When I removed the cqi and cqb values from the min function, the board showed up in these browsers at an appropriate size. I still have to fix things for when a board includes rank and file markers, but for now, I have omitted them from this board, and it is displaying properly on phone displays.

I removed the onlyjs class from the diagram, and that seemed to fix the display for Firefox on my Android phone, but it had no effect on Chrome or the iPhone.

I see the same things happening on an iPhone. On my Android phone, Firefox is giving me a similar but larger board display, and Chrome is making the spaces wider than they are tall. I'll see what I can do.

And interactive diagram is still narrowed! What I mean. iPhone SE. https://www.chessvariants.com/membergraphics/who/CryInto/bugultima.png

Ideally, it should set itself to the width of the widest item that will appear in the second column.

To make it work like this, I replaced "display: none" with "visibility: hidden; height: 0px;", and I replaced "display: inherit" with "visibility: visible; height: auto;". So, while the viewport width remains the same, it will no longer jump between a one column display and a two-column display. At the viewport width where it would have been doing this, you will now just get a one column display.

But when I click 'here' to open the piece table, the table opens under the board anyway, and the word I was just clicking jumps away from under my mouse with it. And when I seek it out again, and click a second time to see the legend, it jumps back!

I got it to do that by narrowing the width of the window. The width of the second column depends upon the width of its content, and as its content varies, its width varies. So, at a certain viewport width, it will alternate between being able to fit the available space or being too wide to fit the available space. Ideally, it should set itself to the width of the widest item that will appear in the second column.

And interactive diagram is narrowed!

That should depend upon how wide your screen or window is. I have added code to betzaFlex.js to use more flexible values for the height and width of table cells in the diagram. Instead of assigning a single fixed value to height and width, it calculates the maximum value that will allow the whole board to remain visible in terms of viewport units and container units, and it uses the CSS min function to apply the minimum of these and the assigned value. So, if the viewport is wide enough, it will use the assigned value, and if it is not wide enough, it will use a smaller value that lets the whole board stay in view.

For me the Diagram looks OK. But when I click 'here' to open the piece table, the table opens under the board anyway, and the word I was just clicking jumps away from under my mouse with it. And when I seek it out again, and click a second time to see the legend, it jumps back!

And interactive diagram is narrowed!

I modified this page to use my /fergus/betzaFlex.js fork of the betzaNew.js script, and when I saw the board and the piece table side-by-side, I noticed that the piece table did not update when I switched from one Alfaerie set to another. It apparently updates only when the value of graphDir changes. As a quick fix, I wrote it differently for each Alfaerie set. Two use the full URL with the chessvariants.com and chessvariants.org domains respectively, and one uses a relative URL.

I recently changed the ID script to report non-fatal errors in the definition lines. In this case specification of key=value pairs with an unrecognized key. This should be harmless; such lines are still ignored, and the message would be overwritten as soon as you start manipulating the pieces in the Diagram anyway. It can never be a reason for the Diagram not working (i.e. not showing the pieces, which is what I see).

So it seems we are dealing with multiple causes here.

When I look at the HTML I see two lines at the botom of the Diagram definition that serve no purpose, and don't belong there, setting royal to a value it should already have, and this enableAI=2. The latter is what you would do if there is a permanent piece table somewhere on the page, instead of the one you can open below the board. (Which is convenient in games with drops, where the table is the source of the pieces to drop.) In that case the message for opening the table below the board is omitted, but since that line also contains the "Play It!" link to activate the AI this would make the AI inaccessible. (Which is OK fror drop games, as the AI cannot handle those anyway.) But sometimes you want to display a piece table for other reasons than drops, and then you can force appearence of a link to open the AI panel with this parameter.

There is no separate piece table on this page, so the enableAI=2 line would have no effect, even if it was understood. I think the reason it is not understood is that the line is prefixed with two tab characters; the Diagram parser probably considers these part of the key. Just delete these two lines, or at least the tabs. (WinSCP did not allow me to overwrite the page, when I tried it myself.)

This should make the error message disappear. It would not cure the failure to show pieces, though. For this I am in the dark, as the FireFox console did not report any JavaScript errors for this page. The pieces appear in the piece table you can open, and react to the theme buttons there.

The Interactive Diagram on this page has stopped working, and it says "unknown parameter: enableAI=2". When I looked up enableAI in the code, it was among the public parameters rather than the private variables. So, I don't understand why it should be reporting this message or what I can do to fix it.

Zillions-of-Games follows the convention of treating the color green as transparent, and it ignores any transparencies built into the image.

I don't quite understand the role of green here. In principle, when you take square shades that are not too different (e.g. light and dark brown), you could render the pieces with transparent background on the average color, and then declare that color as transparency. (Or, when you need another color to indicate transparency, use the paint bucket to flood-fill the outside with that.)

I figured out what to do about making the pieces smoother for Zillions-of-Games, which allows only a single fully transparent color instead of multiple partially transparent colors. It's similar to what I've done before in making pieces. While I might be able to automate this, I have been doing it manually following these steps in Ultimate Paint:

1. I open a PNG file.
2. With green (#00FF00) as the foreground color, I color the background green.
3. I make green the official background color and copy the image as a brush, which gives me a version of the image without the background.
4. I paste this brush to the center of a 48x48 grey (#808080) image.
5. I change anything colored #808080 to #00FF00.
6. I save it as a 256 color BMP image.

What this does is turn the partially transparent colors into shades of grey, which looks smoother than letting them turn into black, as they were doing with a simpler conversion. While the look may not be as ideal as what you can get with a PNG file on the web, it's probably the best I can do within the limitations of the graphics capabilities of Zillions-of-Games.

I tried converting three sets of Alfaerie Ultima pieces to BMP images for use with Zillions-of-Games, but I encountered a problem. Zillions-of-Games simply uses the color #00FF00 to indicate what should be transparent, and it ignores the partial transparencies that were in the PNG images. So, in Zillions-of-Games, the results don't look as smooth. Is there any solution to this? If not, I'll try using the original bitmap images and see if they look better.

OK, I created the following SVG:

• pincerpawn
• lizard
• windmill

Thanks, I have now updated the Animals set on this page and in Game Courier to use these pieces.

OK, I created the following SVG:

• pincerpawn
• lizard
• windmill
• princess
• block
• medusa
• gorgona
• crookedbishop
• reflectingbishop

I wasn't asking in general, though.

I was meaning, just in general.

But the Okapi is not one of the pieces used in the game.

But the Okapi is not.

No, the Kangaroo is one of the pieces that is already available as SVG.

I don't know about any of those, but I have managed to replicate my Okapi into SVG if you want it. (It's just the Kangaroo, with a couple of black stripes across the bottom.)

Would someone be able to convert the following pieces from the Alfaerie Animals set to SVG? These are the only pieces from that set not yet available as SVG.

• blizard.gif and wlizard.gif
• bpincerpawn.gif and wpincerpawn.gif
• bwindmill.gif and wwindmill.gif

The other pieces are already available:

I got the 1963 edition of Abbott's New Card Games, and it says the same thing with the same words as the 1968 edition concerning the object of the game. The object is checkmate or stalemate in both the 1963 and 1968 editions. Further details are in the body of the page.

Checkmate still exists in games that finish by King capture, as the condition where it is impossible to avoid such capture on the next move. It just doesn't terminate the game. Since at any serious level of play people would not blunder away their King, the only way to capture it would be by first achieving checkmate (or stalemate). So one could say that the goal is to achieve checkmate, so that you can then forcibly capture the King. 'Goal' doesn't necessarily mean terminating condition of the game; you can have many different strategic goals. So I don't see a very large contradiction here.

That it would be mandatory to declare check doesn't mean that it is mandatory to resolve it. Of course not resolving it means your King will get captured, and that sort of makes it mandatory enough for most players, even when the rules do not strictly demand it. The fact that check has to be declared makes it even less likely they would allow the capture by oversight. (Of course they could still move themselves into check by mistake; they would receive no warning against that.)

The special status of check is not really fundamental; it is a consequence of the peculiar way that Chess handles illegal moves. In Shogi any illegal move counts as a loss, and then it makes no difference at all whether moving into check is forbidden, or just a bad move that gets your King captured. In Chess it would decide whether you have to take back the move that exposed your King, and continue the game from there, or that the opponent can capture it for the win.

Whether the 1963 rules include checkmate remains an open question until someone gets ahold of the 1963 rules and checks. While the Zillions-of-Games file does treat capture of the King and not checkmate as the winning condition, it also says it is based on the original rules, and these would be the 1962 rules we can read on Abbot's website. Concerning Abbott's four Ultima puzzles, he describes the first one as "Mate in 1", and he describes the other three as "Mate in 2".

However, he says of these:

This follows the conventions of chess problems, even though in Ultima the object is to capture the king, not achieve check mate.

Notably, he is saying this within the context of having tested his puzzles with Zillions-of-Games, and this is the rule programmed into Zillions-of-Games. Zillions-of-Games claims to be based on the original rules. Since these rules say the game is won through capture of the King, and they do not explicitly mention checkmate, they could be interpreted to not include checkmate. It was presumably Mark Lefler or Jeff Mallett who programmed this interpretation of the original rules. However, the 1962 article on Ultima says "The same rules for declaring check apply as in chess." How are we to make sense of this if checkmate is not part of the game? Additionally, it ends with the sentence "We are especially interested in discovering the minimum number of pieces needed for checkmate." If checkmate was not part of the original rules, it would not make much sense to say this. So, it would have been valid to understand these rules as including checkmate, and Lefler or Mallett may have made a mistake, which Abbott repeated without accurately remembering his own rules.

Around the same time that Ultima appeared in Zillions-of-Games, David Pritchard published the rules in The Encyclopedia of Chess Variants and in Popular Chess Variants. In both of these, he claimed the object was checkmate.

In the 1968 rules, Abbott explicitly mentions that the game is won through checkmate, and this comes after a paragraph in which he said "The object of the game is to check the enemy king." Given the context, this sentence does not imply that the game is not won through checkmate, and accordingly, the similar sentence in the original rules, "The object of the game is to capture this king", may not have been intended to deny that the game is won by checkmate.

Given that checkmate may have been part of the original 1962 rules and was definitely a part of the revised 1968 rules, it's reasonable to expect that it was also part of the 1963 rules.

At this point, we probably have two traditions concerning the rules of Ultima. We have those who followed Pritchard in treating checkmate as a winning condition, and we have those who followed Zillions-of-Games in making capture of the King the winning condition.

The pincer pawn and withdrawer?

Yes to one of those and not the other.

The visual pun is quite funny ngl; I wouldn't have said either it or its replacement is terribly suggestive though

Still, the "visual pun" version would go well with the Gerfod. ;)

The pincer pawn and withdrawer?

For me, the tall knight is the only one of these that both suggests its piece (clearly the long leaper, starting where the Orthochess knight does — though I agree with Bob that it has wider applicability) and would fit in with a Staunton‐style set; I kind of guessed the last one (of the original comment) correctly from its mild rookishness but I wouldn't be confident about it; I find the 3rd and 5th almost indistinguishable w/o direct comparison (presumably the scale would help irl)

The king is nice enough for a very ornate set, provided it had suitably ornate companions to match; the chameleon is kinda pushing it tbh (and doesn't even resemble ebony)

The visual pun is quite funny ngl; I wouldn't have said either it or its replacement is terribly suggestive though

Most of these pieces look very much like some kind of Queen. Did you tell the AI how the pieces moved?

No, I just gave it the name of each piece as it is called in Ultima.

But I did just try it, and the results were less distinguishable from each other than what I got using names.

I redid one piece with the addition of a negative prompt to avoid an incorrect visual pun.

These pieces are not in this game. See the description of the game on this page for the available options.

Oh, I'd reached this from just viewing Comments, and thought it was from another page. I hadn't even noticed that it was Ultima! (Now, where's that "embarrassed smile" emoji?)

(I still like the horse one for a Midnighter, though.)

Daniel, you mixed up two of them. Your clue is that one of these uses a very literal, though wrong, interpretation of the name.

Most of these pieces look very much like some kind of Queen. Did you tell the AI how the pieces moved?

I'd guess the most recent is the immobilizer. For the others,

1. King
2. Chameleon
3. Coordinator
4. Long Leaper
5. Pincer Pawn
6. Withdrawer

I forgot to include this one:

The Knight is not an Ultima piece, so it probably represents a Long Leaper. A Locust/Grasshopper would have made more sense, though. Apart from the obvious King and Chameleon the others look nothing like an Ultima piece. No cigar for Leonardo.

4. Knight,

6 Archbishop, perhaps?

These pieces are not in this game. See the description of the game on this page for the available options.

My eye:

1. King. Suitable mainly for display.

2. Chameleon. Suitable mainly for display.

3. Don't recognize, but I'd play with this one.

4. Knight, though it could be used as a longer-range alternate Knight such as a Nightrider or Midnighter. Good for either play or display.

5. Don't recognize, but good for play. (I might use that as a Berolina.)

6 Archbishop, perhaps? (It looks like it could be a decent Inquisitor or Kuhani, actually.) Another one suitable for either play or display.

Since today is the last day of my paid subscription to Leonardo.Ai, I have been generating lots of images. Here are some I generated for Ultima pieces using only the name used in Ultima. I will display them without names, though you could find out what they are by examining the URL. Without doing that, what do you think each piece is? Were you able to recognize all the pieces? How suitable do you think pieces like these would be?

Well, if Abbott expressed his ideas as a computer program, it doesn't matter what he said elsewhere at all. There is no ambiguity in computer code.

From a game-theoretical perspective there is no ambiguity in the rules: checkmate and stalemate are both won positions, whether the game ends there or whether one in some cases would have to play one more move to actually capture the king.

This isn't correct because players aren't perfect agents. They do not always identify and make the most optimal move. It is possible that someone in "checkmate" will move their king into an easily missed "check" (e.g. a check from the coordinator), and the opponent won't realize they could still capture the king.

Whether this is allowed or not clearly makes a difference when played in any setting with a third-party overseer (an arbiter, a computer client, etc).

he actually changed his mind at some point how the game should be played

Well, we know this is the case to some degree because the 1968 rules are very different from the 1963 rules. He then decided those had been a bad idea, and went back to the 1963 rules.

He even stated in both 1962 and 1963 that the game was still freshly developed and may still have issues. It isn't that surprising for some language of a newly designed game to be contradictory; an aspect of the game started out one way, and later in the design process was changed, but the rest of the rules weren't updated accordingly to reflect the change.

It should be assumed the part of the contradiction that was intended was the part the creator later explained was intended (capturing the king), especially when he also said the other part of the contradiction was not intended (the checkmate).

E.g. an on-line interface would be likely to make it impossible to enter moves that expose the king to begin with, and perhaps automatically resign for a player that is checkmated.

This reminded me that Abbott promoted "Zillions of Games" as a software that accurately enforces the rules of Ultima.

I just found and installed this piece of software and tried a game of Ultima on it. You can play against the computer or against other people.

In this interface that Abbott promoted as correct, you are allowed to enter moves that expose the king. You are allowed to move your king from a safe position into an attacked position. It does not automatically resign, allowing the opponent to make a mistake and miss a capture. You must capture the king to end the game, whereupon it says "King captured. Black wins!"

what is the proper procedure for claiming the victory when the opponent exposes his king to capture

According to the software Abbott promoted, the proper procedure is to capture the king.

I would not exclude that the sentence was just intended to convey that stalemating is an alternative.

No. As someone who loves Robert Abbott's work, I'm not okay with this blatant misrepresentation of his words. His paragraph again was:

The first puzzle is Mate in 1 and all the others are Mate in 2. This follows the conventions of chess problems, even though in Ultima the object is to capture the king, not achieve check mate. So, Mate in 1 should be translated to Capture the king in 2 moves (that is: White moves, Black moves, then White moves and captures the king). Mate in 2 translates to Capture the king in 3 moves.

After saying "in Ultima the object is to capture the king, not achieve check mate," he elaborated with "So" and even explained what he meant with "(that is: White moves, Black moves, then White moves and captures the king)." There is no way to misunderstand this language, and the attempt to do so makes me question the motivation behind it.

And again, these puzzles which require the king to be manually captured per the rules of Ultima were made in 1964, and explained in 2004. It makes it very clear what Abbott's intention was, and the only interface Abbott promoted for playing Ultima works that way as well.

in Chess the object is to capture the king, not achieve checkmate.

No one says that of orthodox Chess, because it obviously would not be true there: there is no way to win an orthodox Chess game other than by checkmating the opponent. Not so in Ultima, where stalemate is a second winning condition, rather than a draw. And 'smothered stalemates', where a player doesn't have any moves even when he would be allowed to expose his king, are not nearly as hypothetical in Ultima as in orthodox Chess: Pieces without replacement capture can easily be boxed in, even if they are not frozen by an Immobilizer. So I would not exclude that the sentence was just intended to convey that stalemating is an alternative.

From a game-theoretical perspective there is no ambiguity in the rules: checkmate and stalemate are both won positions, whether the game ends there or whether one in some cases would have to play one more move to actually capture the king. So the whole discussion is about what I would call "game etiquette": what is the proper procedure for claiming the victory when the opponent exposes his king to capture. Should you actually capture the King and press the clock, or should you just stop the clocks and submit the claim? Or is this not a victory at all if there was an alternative, and should you allow the takeback and that alternative to be played, possibly in combination with a time penalty?

Some of the quotations attributed to Abbott seem to contradict each other, though. There can be two reasons for that: he actually changed his mind at some point how the game should be played, or he has always thought the same about that, but failed to express himself unambiguously. In the latter case we could speculate on what he actually meant. If it is correct that Abbott at any time mentioned that it was not allowed to expose your own king to check, this strongly suggests that he thought a move that did should be handled as per FIDE rules: take back and play another one. For if it would be handled the Shogi way (instant loss), there wouldn't be much reason to mention it at all: the game is over anyway, either by claim or by king capture, unless the players don't notice it, in which case it doesn't matter what the rule is, as it isn't going to be invoked. So it is a matter of weighing the "not by checkmate" against "it is illegal to put your own king in check", I would say the latter of those is the least likely to have meant anything else as what it says.

I can add that no matter what Abbott actually meant, tournament organizers are likely to enforce their own game etiquette. E.g. an on-line interface would be likely to make it impossible to enter moves that expose the king to begin with, and perhaps automatically resign for a player that is checkmated.

I don't believe many people would say "in Chess the object is to capture the king, not achieve checkmate." I don't think anyone would say that. But that is what Abbott said about Ultima, as a direct quote.

The extra clarifying statement he added at the end ("not achieve checkmate") specifically denies the possibility that he meant "this is equivalent to checkmate."

If the rules of Chess stated "in Chess the object is to capture the king, not achieve checkmate" then that is what would happen. Players would likely still resign before the game is over, as often happens now, but someone determined to play the game to completion would have to get the enemy king off the board to win. I think the wording that was used makes this very clear.

The examples Abbott laid out show that even when the king is guaranteed to be captured on the next turn, play still continues with both players moving normally. If the "winning" player doesn't perform the capture, then they don't win, and the game would continue until one of the kings was captured.

It seems that Abbot suggests the latter.

Could you elaborate on this? Apologies if I'm overlooking something, as I may have parsed through everything Abbott has ever written at this point, and it's a lot to keep track of.

From what I've seen, in all 4 instances where Abbott published an explanation about the rules of Ultima over the span of 42 years, he has always said you can capture the enemy king directly. In none of them does he suggest you're allowed to undo this outcome if it resulted from an illegal move, nor does he otherwise imply you have the right to redo moves without consequence. Again however, if I've overlooked something please let me know.

The only practical issue is what should happen on an unforced king sacrifice: does the player lose through having made an illegal move, or should he take the move back and play another?

I'm not seeing anything Abbott has said that outlines special considerations for someone ending their turn with their king in an attacked position. If there are no rules addressing it, then presumably it would need to be resolved either by the rules or by the players making something up themselves. If it's determined by the rules, the only rule that seems related at all to this scneario is the first one: you are allowed to capture the enemy king.

Looking at Shogi, the 将棋連合規定 offers a similar resolution: If a player's move leaves their own king in check, and their opponent points it out, the player immediately loses the game. The outcome of this scenario is mechanically equivalent to the opponent noticing the king is being attacked and capturing it.

Then again, on the chessvariants page for Shogi, I don't see any mention of how these types of situations are resolved. Presumably it is left as an exercise for the players to decide how they'd like to resolve a rules breach when it arises. Perhaps that could be assumed here as well.

All I know is that throughout his entire life, Abbott has been very consistent with his choice of wording for what "the object of the game" is in Ultima, and yet in our "object of the game" section we aren't respecting that wording. We're actually saying the exact opposite.

When a game's creator states "the object of the game is to capture the king" multiple times, and eventually elaborates to specifically say "the object of the game is to capture the king, not achieve checkmate," it seems inappropriate to write that the object of the game is to "achieve checkmate."

I'd hope we could just write what the creator said, instead of the exact opposite of what he said. His own words aren't going to misrepresent him.

Well, many people would say that the object of chess in general is to capture the enemy king. So I don't think such a statement in the description of Ultima necessarily means anything other than that it is similar to chess in terms of goal, rather than to eliminate all opponent pieces, reach a certain goal square, etc.

The thing of practical interest is whether there is a checking rule, which would make this king capture a hypothetical event one move after checkmate. Note that Shogi is generally considered a king-capture game, and that the rules still refer to checkmate (in the context that this should not result from a Pawn drop).

In cases where stalemate is a win, it is a moot point anyway. The only practical issue is what should happen on an unforced king sacrifice: does the player lose through having made an illegal move, or should he take the move back and play another? It seems that Abbot suggests the latter.

I think it is hard to argue against "The object of the game is to capture the enemy king." This is a direct quote from Abbott. There's no way to misinterpret that sentence to mean the object is checkmate.

From what I see, both the oldest source and newest source from Abbott agree on this. Even if the 1968 edition (which Abbott is on record disavowing by the way) includes contradictory language, it still says "The object of the game is to capture this king." This statement can't be ignored.

These statements are very straightforward and impossible to misunderstand. Every source from Abbott is in agreement. In each source, the object of the game is explicitly stated to be "to capture the king."

I believe "The object of the game is to capture the enemy king" makes it clear what the object of the game is, and there is only one way to interpret it. Even if some of these sources include contradictory language that also states the exact opposite, not all of them do (i.e. the rules as explained by Abbott on his website state that the object is to capture the enemy king, and they also specifically state that there is no checkmate). The only object every source from Abbott includes and agrees on is "to capture the enemy king."

Also, if it "moves and captures in exactly the same fashion as the chess king," it could not move into check.

I feel this may be a bit of a stretch. This interpretation would contradict the object of the game that is explicitly stated in the same line. Rather than assume Abbott was thinking of checking behavior and castling when he said the king "moves and captures" as the chess king does, it would probably make more sense to read his statement literally: the king "moves [1 square in any direction] and captures [by displacement]" as the chess king does. Taking his sentence at face value has the added benefit of not contradicting his very next sentence in the paragraph as well.

Even if there was a source in the past where Abbott indicated "the object is to capture the king" and at the same time he said "the object is to checkmate the king," that only tells us one of those contradictory statements would have to be wrong. Given that Abbott wrote an in-depth explanation about the object of Ultima on his website, it seems clear which option he intended to go with.

I am looking at this page mentioned earlier, and Abbott is even more explicit here.

The first puzzle is Mate in 1 and all the others are Mate in 2. This follows the conventions of chess problems, even though in Ultima the object is to capture the king, not achieve check mate. So, Mate in 1 should be translated to Capture the king in 2 moves (that is: White moves, Black moves, then White moves and captures the king). Mate in 2 translates to Capture the king in 3 moves.

Note that if checkmate was the object of Ultima, there would have been no reason to include a paragraph here at all. Attempting to find checkmate is how these types of puzzles work by default. Abbott went out of his way to write and include this paragraph about how the object of Ultima is not the same as chess, and to make it completely unambiguous. It's pretty clear he didn't want any further confusion about this.

Going through the content of Abbott's explanation, I'll start by highlighting the short answer:

in Ultima the object is to capture the king, not achieve check mate.

In this case, he not only said "to capture the king" is the object of the game (matching his other sources), but this time he even elaborated that achieving checkmate is not the object of the game. This explanation directly addresses the contradiction that was found in one of the older sources and leaves no room for misunderstanding.

However, in case he still hadn't been clear enough yet, Abbott went on to explain the actual turn sequence that ends a game of Ultima:

White moves, Black moves, then White moves and captures the king

Note that in Abbott's example of how an Ultima game ends, Black makes a legal move that leaves his king under attack. It is obvious from this that there is no checkmate, otherwise Black could not have moved. Abbott's detailed move-by-move explanation removes all ambiguity and clears up any potential confusion. It rules out any possibility that checkmate is the intended object of the game.

On the Chess Variants article, there is also a 4th source linked, the original 1962 Article introducing the game. This article was brought up earlier, but again, this source matches the rest of them, clearly stating "The object of the game is to capture this king." The rules include no mention of checkmate at all. All it says about checking is "The same rules for declaring check apply as in chess." Of course, there are no rules that require you to declare check in chess, so that's a moot point.

Additionally, I see on Abbott's site that he was really enthusiastic about David Howe's "extensive" and "especially useful" write-up of an Ultima game ending. I found his write-up.

These are the last three moves of the game in his write-up:

White Chameleon at e8 moves to g6

Black must move LL at g7 (or suicide a piece)

White Chameleon at g6 captures Black K

Note that in this write-up, White moves a Chameleon next to Black's King, which Black has no way to avoid. Black is then required to make another move. White then captures Black's King to end the game.

This is another specific example for how an Ultima game ends, with Black making a move that ends with his king under attack, and White then capturing Black's king.

Earlier it was mentioned that Abbott recommended the chessvariants page at one point, but he did so in the context of wanting to share admiration for David Howe's animated illustrations. It appeared to be a short respectful way to introduce the topic, giving a general compliment lacking any specificity. Based on the rest of the paragraph, Abbott makes it clear that the part of the site's explanation he was impressed with was the animated illustrations that explain the piece movements. Even if all the context is ignored in order to assume the compliment was well-researched and literal, saying something is the best option available doesn't suggest that it can't be improved upon, or that the speaker made a point of proofreading the site in the first place.

Additionally, shortly after that paragraph where he says chessvariants is a good site, he then links to his own page which he had just written himself, where he states multiple times that the object of Ultima is to capture the enemy king, and that the object of Ultima is not to checkmate, and he even explains move-by-move how an Ultima game ends in order to make the object of the game perfectly clear.

Actually... Abbott mentions multiple times, across several different pages, that his Ultima puzzles (which required you to capture the enemy king) were created in 1964. This means the 1963 rules, which these puzzles were utilizing, also intended for you to capture the enemy king.

With the Abbott of 1964 and the Abbott of 2004 being in agreement that the object of Ultima is to capture the king, the conclusion seems pretty straightforward.

It turns out that Abbott has included a copy of the original 1962 article on Ultima on his website, and I have now added a link to it. Here is what it says on the object of the game:

KING: The king moves and captures in exactly the same fashion as the chess king. The object of the game is to capture this king. The same rules for declaring check apply as in chess.

One could get the impression from this description that the object is just to capture the king, as this does not explicitly mention checkmate or stalemate. If Abbott was referencing this version of the rules, he could have misremembered the object of the game. Since a change in object has not been mentioned as one of the changes between the 1963 and 1968 editions, I am assuming until I learn for sure otherwise that the 1963 edition specifies checkmate and stalemate as the winning conditions. Also, if it "moves and captures in exactly the same fashion as the chess king," it could not move into check.

So, the copy of Abbott's New Card Games that I ordered turned out to be the 1968 edition. When I looked at the record of my Amazon order in hopes of complaining about this, it said it was the 1968 edition. Checking ebay, I saw another copy with the same cover described as the 1963 edition, and maybe that is why I thought this would be the 1963 edition. As David previously reported, this edition limits the distance a piece may move to the rank it is on from that player's perspective.

Getting to the question of whether the game is won through capture or checkmate, here is what it says,

The object of the game is to capture the enemy king. The players declare check in a fashion similar to that of Chess. That is, if a player makes a move that puts him in a position to take the enemy king on the next move, he announces check. A player may not move into a position that puts his own king in check.

The game is won when a player achieves checkmate, attacking the enemy king in such a way that it cannot escape capture on the next turn. A player also wins if his opponent is unable to move any of his pieces.

Although he first seems to say that it is won through capturing the enemy king, the sentences I have put in boldface make it clear that the game is won by checkmating or stalemating the opponent, and as a player may not make any move that places (or presumably leaves) his king in check, any position where a king could actually be captured is illegal.

So if we are bent on introducing new sets that have never been used before, we better give it some thought before acting rashly.

A variation on the Alfaerie Animals set has long been in use for Rococo, which is based on Ultima. Since it appears that the Alfaerie Animals set has not been in independent use, I have replaced its Withdrawer image with the ox image used in Rococo. This also brings it more in line with the Galactic set, which was the default set for the original Game Courier preset, as that set uses an ox for the Withdrawer and a Kanagaroo for the Long Leaper. Also, its Pincer Pawn image matches the image used for another Alfaerie set that has long been in use on Game Courier. What I think happened is that David Howe made the Alfaerie Animals set first, and then he later designed other pieces for Ultima and replaced that set with the new set.

Each of the other sets has long been in use or is similar to one that has been. The Alfaerie Chess pieces have long been used for other variants. Judging by Archive.org records, I had created my Abstract pieces for Ultima by early 2004. I have long made them available on Game Courier, and they are now the default for the new Ultima preset. David Howe's Ultima-Alt set was previously used on this page and is still used on the animated diagrams page. And your Alfaerie Queens set is a variation on David's most recent Alfaerie set for Ultima, which has long been available on Game Courier, but it differs because some of the images in that set have not been converted to SVG yet.

Well, I would easily know a better set that would have very diverse shapes and be more suggestive of the powers:

• Pincher Pawn -> Go stone
• Long Leaper -> Draughts King (i.e. stacked chips)
• Chameleon -> Mirror
• Coordinator -> Radio-telescope dish
• Immobilizer -> Horseshoe magnet
• Withdrawer -> Rocket

So if we are bent on introducing new sets that have never been used before, we better give it some thought before acting rashly. We are not married to Alfaerie, so "best set using Alfaerie pieces" is a meaningless distinction. That a piece set has dedicated Ultima pieces would be a reason to show them 'under a button', but if they are not much good we should avoid their use (and thus the use of the set they belonged to). Beside that, we should just present the set that is best without limiting ourselves to existing images from existing sets.

is it really needed to include the 'Alfaerie Animals' representation? Showing multiple representations can only increase confusion. It should be obvious that chess pieces can be represented by any set of images, and one can even buy orthodox chess sets where all pieces are sheep, frogs, pigs or heroes and villains from Star Wars. Is anyone actually using this 'Alfaerie Animals' representation? If not, why would we encourage this particular choice over the few million others that could be concocted with animal images from the Alfaerie set?

This set was in the sets directory for Game Courier, and I didn't realize until today that it wasn't showing up in Game Courier. So, I have now corrected this. Although the images it uses are not all available as SVGs, I consider it the best Alfaerie set for Ultima, because the images are distinct from each other while also suggesting the powers of each piece. The Alfaerie Queens set slows down my recognition of the pieces, because they look too similar, and the Alfaerie Chess set uses pieces that mostly do not suggest the powers of each piece, as the piece designs used were not intended for Ultima.

I have now finished the new diagrams for this page, and I have updated the piece descriptions, mostly by copying and modifying descriptions I already wrote for Game Courier. But I also checked the other descriptions to make sure I wasn't missing any important details.

If there are to be static move diagrams, they should not be made with the Abstract piece set. For people with JavaScript off these pieces have not been introduced; they would only be aware of the 'inverted rook' or ultima-alt representations, so the move diagrams would be useless to them.

I have also updated the setup diagrams. I moved the ultima-alt diagram to the page for the animated diagrams, and I added two diagrams that show up when JavaScript is disabled. One uses the Alfaerie Chess pieces, and one uses the Abstract pieces. They will also show up in the printed version.

Is anyone actually using this 'Alfaerie Animals' representation?

As far as I'm aware, not for Ultima itself (even the GC preset lacks it as an option), though some of its offshoots (Rococo, Fugue) and other games using its pieces (Carlos Cetina's Universal Chesses) use its Chameleon, Long Leaper, and Immobiliser quite consistently. Those games use a different image for the Withdrawer though (An ox, whereas the one here is used by David Howe for his Chess on a Longer Board with a few Pieces Added) and don't feature the Coördinator at all

Whether use in other games qualifies the piece set to be used on this page too is another question of course (though one could certainly argue for at least the GC preset to include them as an option)

Well, there was never a danger of anything getting lost, as I was careful enough to first make a copy of the old version.

Because I was not done yet editing the page before I saw your comment, saving my latest changes probably overwrote whatever you did.

Note that the old page contains many errors and unclarities. E.g. the starting squares mentioned for the pieces did not coincide with that in the diagram.

If there are to be static move diagrams, they should not be made with the Abstract piece set. For people with JavaScript off these pieces have not been introduced; they would only be aware of the 'inverted rook' or ultima-alt representations, so the move diagrams would be useless to them.

I see no logic in having a separate page for move diagrams, no matter how revolutionary these were at the time of their publishing. Move diagrams belong in the piece section of the article describing the variant, and the page with the move diagrams would make an excellent Pieces section for this article.

Now that you have moved the animated diagrams to this page, I see the logic to keeping them on a separate page. Animations on a page are annoying, which is why <BLINK> is no longer part of HTML. Also, animated diagrams are not suitable for printing should someone choose to print the page to have a copy of the rules. It's better to provide static diagrams, as I was starting to do before I got sidetracked by other things. Anyway, I was able to get a cached copy of the older version of the page. So, my work on the static diagrams has not been lost.

Now that Utrecht is available in SVG and 50x50 PNG I think it would be better to use that rather than Alfaerie to present this representation as the primary diagram, and only show 'Ultima-Alt', 'Alfaerie Queens' and 'Abstract' as alternatives.

I disagree and have changed it back to using Alfaerie.

This page is indeed in a sorry state. With JavaScript switched off the Interactive Diagram does not appear, and we get to see a number of non-functional buttons with the Diagram's definition displayed below it as reformatted text. People then only get to see the static image of the setup in the Alternate Pieces section, plus two static move diagrams, which uses a hitherto unintroduced and far from self-explanatory piece representation.

In fact it is strange that these move diagrams are on the page at all; none of the other pieces have such move diagrams, and all piece descriptions already refer to a page with animated move diagrams. Note that separate move diagrams are not really a luxury here even for people that can see the Interactive Diagram, as the capture mode of some of the pieces is not properly demonstrated by the move diagrams that by default can be displayed through this Diagram: it would show moves of the piece on a board that is otherwise empty except for a single opponent 'pawn' that can be moved around through hovering over the board. Pincher Pawns, Chameleons and Coordinators never have any captures under those conditions, but the Withdrawer is one of the few pieces for which the Interactive Diagram would work (if JavaScript is switched on).

I see no logic in having a separate page for move diagrams, no matter how revolutionary these were at the time of their publishing. Move diagrams belong in the piece section of the article describing the variant, and the page with the move diagrams would make an excellent Pieces section for this article.

I also see no reason to show an Alternate Pieces section if there already is a (working) button through which the Interactive Diagram can show this same, as well as several other alternate representations. So this section should be hidden when JavaScript is switched on. And with JavaScript off the setup should be shown not only in the 'alternate' representation, but also in the preferred one. A more logical layout would be to delete the section, but show the diagram side by side with a static image of the setup with ordinary chess pieces (and inverted Rook) in the Setup section.

As to the piece sets that can be shown through the buttons: is it really needed to include the 'Alfaerie Animals' representation? Showing multiple representations can only increase confusion. It should be obvious that chess pieces can be represented by any set of images, and one can even buy orthodox chess sets where all pieces are sheep, frogs, pigs or heroes and villains from Star Wars. Is anyone actually using this 'Alfaerie Animals' representation? If not, why would we encourage this particular choice over the few million others that could be concocted with animal images from the Alfaerie set?

I also seem to recall that originally the initial (static) setup diagram used the ('small') Utrecht theme with the 'inverted-Rook representation'. Now that Utrecht is available in SVG and 50x50 PNG I think it would be better to use that rather than Alfaerie to present this representation as the primary diagram, and only show 'Ultima-Alt', 'Alfaerie Queens' and 'Abstract' as alternatives.

As you are currently revising the page for this important game, maybe you could do something about the graphics. There are 4 different graphic sets used in this page and this is a lot. It doesn't help.

Just stating that one wins by capturing the king doesn't fully cover it, as stalemate can be achieved by immobilizing a bare king. Assuming that removing one's own king is illegal. As I don't think removal of own pieces is covered by the term 'capture', the rules should either explicitly state king removal is terminating the game as a loss, or it would have to be specified that stalemate is a win. Which, together with king capture as winning condition implies that checkmate is a win. Assuming that none of the players will ever be so stupid as to overlook he can capture the king.

BTW, 'stalemating the opponent king' is a non-sensical phrase: the concept of stalemate applies to a player, not to one particular piece of a player.

Also note that when level of play is so low that players are likely to blunder away their King in a single move, invoking concepts like checkmate becomes a bit pointless, as they would not be able to recognize a checkmate with any accuracy. This becomes more an issue of how to handle illegal moves, which I do not consider so much part of the game rules, but more 'tounament etiquette'. Even orthodox Chess is often played with 'blitz rules', where an immediate win can be claimed after an opponent plays an illegal move, rather than forcing a takeback and resuming the game from there. So king-capture victory can simply be seen as a method for claiming a win after violation of a checking rule. The important issue from a game-theoretical perspective is how to handle stalemates.

I wrote this in 2004:

The Wikipedia page on Baroque Chess currently asserts that Robert Abbott did not invent the game, as can be discovered by reading the Fairy Chessmen by Lewis Padgett. I expect this is a bunch of nonsense and have explained why in the discussion area for Wikipedia's Baroque Chess page. However, I have not read the Fairy Chessmen and cannot get ahold of a copy.

Since then, I have read The Fairy Chessmen by Lewis Padgett, which was a penname for the husband/wife team of Henry Kuttner and C. L. Moore, and it does not describe Ultima. It does show a knowledge of fairy chess and mentions some pieces, such as the nightrider and the grasshopper, but it is a science fiction novel and does not delve into the subject too much. Since I have it on my Kindle, I searched for the names of Ultima pieces and did not find any except the king.

In my research, I learned that Robert Abbott died in 2018. To confirm the 1963 rules once and for all, I have ordered a copy of his book.

in Ultima the object is to capture the king, not achieve check mate.

Since it's on Abbott's page, that gives it authority. But I should do some more checking, as Pritchard said "The object remains checkmate," and I'm aware that Abbott tried to revise Ultima, but the original version remained more popular.

I received the following email:

"I just wanted to bring to your attention an error on the Ultima variant page: Ultima (chessvariants.com)

In the "Object of the game" section, the word "checkmating" should be changed to "capturing" (so the line says "capturing or stalemating"). This variant is intended to be played without checkmating; you are meant to capture the enemy king. This is an important aspect of the game, because a common strategy is to misdirect the opponent into opening their king up to an attack in order to capture their king on the next move. The threat of losing to a "sneak attack" was specifically mentioned by Robert Abbott when he published the rules.

For citations: Ultima was first published in Robert Abbott's book "Abbott's New Card Games" in 1963. On page 125, when detailing the rules of Ultima, Abbott wrote "The object of the game is to capture the enemy king."

This webpage was written by Robert Abbott 41 years later, in 2004: http://www.logicmazes.com/games/puz1to4.html He writes: "In Ultima the object is to capture the king, not achieve check mate." This is what the page said when it was published by Abbott in 2004, and it has remained unchanged since.

I hope this information helps. Thank you for your time."

A quick check of the references shows the above is correct. I started a more extensive search, but haven't found anything else yet, except the discrepancy noted below. Currently I've started looking through the 150 comments on the game's onsite page. If I find anything other in the search, I'll post it here.

Abbott himself recommended the chessvariants page for the best explanation of the game. From Abbott's logicmazes.com page:

"After my card game book was published, I began seeing problems with Ultima and tried to fix one of them by making a change in the rules. These revised rules appeared in the 1968 paperback edition of the book. The change turned out to be a pretty bad idea, and everyone uses the 1963 rules instead.

For the best explanation of the rules (the 1963 version) see this page of the web site ChessVariants.org. Not only is their explanation well-written, but if you click on “Animated Illustration” you’ll see a series of moving diagrams that help explain the pieces (a sample is at the right). These are animated GIFs created by David Howe. They are a fantastic innovation for presenting game rules and could be used in other forms of technical writing. The Chess Variants site also has an interview with me."

Although this article says that Ultima was played by NOST, it does not mention any issues of NOSTalgia describing the game. The oldest issue of NOSTalgia that I could find material from through the Wayback Machine is #367, and none of the available articles mentioned Ultima in the title.

This page includes a link to Robert Abbott's article in World Game Review. This magazine was published by Michael Keller, who is no longer allowed to use the name. However, Keller reports on a page about the magazine on his website that he plans on putting together The WGR Index of Chess Variants, which would include Paul Yearout's articles on Ultima.

Does anyone know where to find the documents mentioned in the article? I'm struggling to locate either the World Game Review or the issues of NOSTalgia that mention Ultima.

I have found a simple way to increase the size of everything on the Kindle. It looks like this:

@media (min-width: 1060px) and (max-width: 7in) {
    HTML {zoom: 2;}
}

While zoom is not official CSS, the Kindle browser accepts it, and that is all that really matters here. But for it to work properly, I have to roll back everything else I did to increase the size of things on the Kindle. Otherwise, this makes some things too large.

However, this fixes most things without quite doing that:

@media (min-width: 1060px) and (max-width: 7in) {
    HTML {font-size: 6pt;}
    MAIN {zoom: 2;}
}

Currently the board squares are defined by the statement

     row = row + '<td id="' + bnr + 'y' + h + 'y' + j + '" style="width:' + sqrSize + 'px;height:' + sqrSize + 'px' +
            ';border:' + bb + ';font-size:xx-large;background-repeat:no-repeat;background-position: center center;background-size:contain"' +
            ' onmousedown="Down(' + bnr + ',' + j + ',' + h + ',event)" onmouseup="Up(' + bnr + ',' + j + ',' + h +
            ',event)" ontouch="Touch(' + bnr + ',' + j + ',' + h +
            ')" onmouseover="Hover(event' +
            ')" ondragover="PreDrop(event)" ondrop="Drop(event)" ondragend="Relay(event)" valign="center" align="center"></td>';

and it should not be difficult to replace all the style stuff in the first two lines there by a class="boardsquare". But it seems a problem that sqrSize is not fixed here, but a JavaScript variable that only becomes known after the JavaScript has parsed the Diagram's definition squareSize=N.

Apart from that, we should also handle the situation where there are multiple Diagrams on the same page, which each use different squareSize. I suppose this could be fixed by defining a separate class for the squares of each Diagram, with name 'boardsquare'+bnr.

But I guess it would be simpler if the JavaScript could somehow query the screen width in pixels as well as in inches. Then it could set a variable bigScreen to 1 or 2 based on some logical combination of that, and it could multiply the parameter value of sqrSize by that at the point at the point where it gets read from the Diargarm definitions.

But it would still be a problem if the Diagram was contained in a surrounding HTML element with a fixed width specified in pixels. (Like almost all Diagrams I made so far are.) Then the Diagram would have understood it would have to present itself with twice the size, but the browser would then think "hey, this is too large to fit", and reduce it back. (And perhaps not at exactly 50%.)

So I guess it would only work if the Diagram script would somehow double the size of all surrounding HTML elements that did have a specified size in pixels as well. I suppose this would be possible, even though such elements would in general not have an id (and even when they have, it would be unknown): I think it is possible to ask a HTML element what its parent is, and work your way outwards from the Diagram that way. It sounds a bit tricky, though.

What I'm proposing is a responsive web design fix for browsers that have the issue I have noticed only in the Kindle browser. This should not affect the appearance of the board on desktops, laptops, or most mobile devices. Last night, I posted a @media query that can be used to detect this. It may also be possible to detect it with JavaScript. In this circumstance, it would be appropriate to double the height and width of the spaces. Doubling these dimensions should not make bitmap images look as bad as increasing to some other arbitrary size would. If you have a Kindle, you can see this on the home page, where I have used the @media query I mentioned to double the height and width of the buttons.

However, it is not presently as easy as using a CSS @media query with the Interactive Diagram. Looking at your code with Web Developer Tools in Firefox, I see that you have embedded the width and height of each space into the STYLE element of each TD element of your table. This gives it a higher priority that may be difficult to override from a @media query. If width and height are normally going to be the same for each space, you could put these values in a class, and then allow a @media query to change the values set by the class.

As long as the pieces are going to stretch to fit the size of the space, maybe you could make an Interactive Diagram increase in size on a large (in terms of pixels) mobile screen.

This could be hard to control without knowledge of the entire page layout. The way I usually insert Diagrams into articles is by defining a 2 x 1 table, where the left cell contains the Diagram, and the right cell a list of pieces that can be clicked to summon the corresponding move diagrams (generated by the Diagram script as a 'satellite'). I then specify an explicit width for the left cell (and top alignment for the right cell). This to leave as little white space as possible between the board and the list.

It appears that the width specified for the table cell overrules the natural width of the Diagram itself; if I specify it too small the Diagram gets squeezed. So with an absolute width specified here, there would never be an opportunity for the Diagram to expand, no matter how wide the screen is.

I suppose the width of the left cell could be specified as a percentage of the screen width. Then the Diagram inside of it could expand if again the square size would be indicated as a percentage of the table width, rather than in pixels. Currently the Diagram script applies parseInt() to the value given for squareSize (this to prevent the 1+1=11 problem when you try to calculate something with it), so that specifying a width of 10% would be the same as specifying 10 (which by default is interpreted as pixels when used in the style width spec). It could make the script remember any non-numeric suffix to the value, and append that again to the number when specifying a width. Then it would be up to the one who configured the Diagram to decide whether he wants to use relative size (which would expand with the screen or window size when the surrounding HTML element does so).

But I don't think expansion would give a good result, unless overly large piece images are used (like 100x100). But of course the preson designing the page would know whether that is the case.

I got a Kindle Scribe yesterday, and I've been looking at this site in its web browser. Because it's a 300 PPI e-ink device with a large screen, it fits a lot of pixels on its screen, and various elements whose size has been defined in pixels appear small. Based on its 1860 screen width and 2480 screen height, I calculate that it is just about 6.2 inches wide and about 8.26 inches tall, and those values are very close to the less precise measurements I took with a ruler.

One step I've taken is to give HTML a font-size of 12pt in the CSS files. This doesn't change the appearance on my desktop, but it makes text a more comfortable size for reading in the Scribe's browser. One thing that's much smaller on the Scribe's screen is the Interactive Diagram. Since the screen has 300 pixels per inch, an 8x8 board with 50 pixel squares should be less than 1.5 inches wide, and that is in fact what I'm measuring. As long as the pieces are going to stretch to fit the size of the space, maybe you could make an Interactive Diagram increase in size on a large (in terms of pixels) mobile screen.

There is an aspect-ratio style, but it seems to be ignored. When I use aspect-ratio:1/1 in the style of the td elements of the board, instead of specifying a height, I get this:

Here none of the dimensions of the table was 'under pressure'. But it seems to base the row heights on what is needed for the coordinate font in the left board margin, rather than making it equal to the width as requested.

This could be a problem associated with the board being generated by the JavaScript rather than being in the original page source.

[Edit] The problem seems to be more fundamental. The entire Diagram in the case above was again within a cell of a larger table and a div within that. These HTML elements were present in the originally loaded page. But if I request some aspect ratio for those (and leave the board cells with specified height), it also is ignored.

[Edit2] It seems I finally found something that does have an effect. In the routine Display(), for displaying the current board position, where it loops over all squares to specify their new background image (i.e. the piece), I can put

cell.style.height = cell.clientWidth;

This adapts the height to the actual width that the browser gave to the td table cell. The problem is that it doesn't work when you merely resize the browser window (as no JavaScript is called by doing that). But the next time you click in the board this will trigger a call to Display(), and restore the aspect ratio of the squares. If the browser window was already narrow when the page gets loaded (as should be the case when you view the page on a phone), the proper aspect ratio will be used immediately.

I suppose it should be possible to attach an event listener to the page that would call a handler on resizing; If this handler would call (or be) Display(), I suppose it would even adjust the height when the width gets squeezed by a resize.

[Edit3] OK, I now uploaded a betzaNew.js script that does this (including the resize handler). Flush the browser cache to test it.

It has occurred to me that there is a use for stretching normal sized GIFs and PNGs. One of the issues the Interactive Diagrams have had on my phone is that as the spaces get smaller than the pieces, the pieces get cropped, which looks really bad. For example, the one I made for Chess has this problem. But the one for Ultima does not have this problem, because the pieces are shrinking to fit the smaller space. This greatly improves the appearance of Interactive Diagrams on phones, and it removes one nagging issue I had with using Interactive Diagrams in place of static images. (The one remaining issue is that the spaces become rectangular on my phone. It would help to include some CSS for preserving the aspect ratio of spaces as they shrink to fit a small space.)

With this in mind, I had XnView do some mass file conversions on the Abstract and Motif pieces, and I uploaded these to new directories to test them out. I updated the Interactive Diagram to use them, and the extra space added to each image appears to be transparent. All I did, though, was set it to #00FF00, the same color used for the transparent color, and hoped that was good enough. So, I'll do some more testing later.

I was examining what the individual Interactive Diagram for each piece reveals, and it gets some things wrong.  ...

Well, this is partly to be expected. Move diagrams are for indicating how pieces move. For replacement captures this happens to coincide with how they capture. For other capture modes, these become entirely different aspects of the piece. Even if there was a King on the board, I would have no idea how to show all coordinator moves and captures in a single diagram, and the 'dynamic probing' by dragging a potential victim over the board is unlikely to discover the squares where it can be captured unless you already understand the move. For Long-Jumper capture we are at least lucky that the victim has to be in the path of the non-capture move.

It is indeed a bit strange that the Long Leaper's move diagram indicates capture of an edge piece is possible. The highlighting of moves in the move diagrams is now done by a completely different routine (namely the old one) than that for entering moves (which uses a move list generated by the AI). This because it really should highlight different squares, or use different markers for the same square. (For instance, the move diagram for Pawns must indicate the possibility to capture on squares that are empty.)

I suppose that the 'spell zone' of the Immobilizer could be indicated in the diagram. But it would require some additional explanation for an uninaugurated user to know what it means. Immobilization is not the only type of 'spell' the Diagram now supports. The problem here is that one would really be interested in the moves (or survival) of the piece that is being dragged around, rather than in the move of the Immobilizer.

I think that in cases of such exotic rules as Ultima, the rules can only be properly illustrated by showing dedicated diagrams with carefully set-up positions. The Interactive Diagram can assist in this by allowing the user to experiment with arbitrary positions in its main display.

As to moving your King in check: the ID would allow you to make any move, you could start with Ke8-d4 if you wanted. There is no rule enforcement, and moving your King into check is no exception to that. And of course it will capture it in that case. For some variants King capture is actually the goal. It should allow you to take back the moves, though, and continue play from an earlier position. If that did not work properly there must be a bug in taking back moves. There seems to be a problem with notation as well, as for some moves it indicates the piece by a question mark. And it seems to think promotion is possible, which could be a configuration error (e.g. wrong value for maxPromote) or a bug in the generation of move notation.

I will look at those problems; the betzaNew.js script is not fully finished yet. I am already glad that the newly added features allow it (with the aid of some custom scripting) to have the AI play something as non-chess-like as Ultima without making illegal moves.

I looked up the solution and got this:

  var img = document.getElementById('imageId'); 
  var width = img.naturalWidth;
  var height = img.naturalHeight;

This could offer an approach to the problem, but I don't expect tit to be simple. The piece images on the board have no ID, as they are background, and not independent HTML elements. But the images in the piece table are foreground, in HTML img tags. I could assign an ID to those (they currently don't have one), and access their properties in the way you indicate.

But it is a problem that this entire table is generated by the script. In your test you apply the code to an image that was already present in the page source. So it will be available by the time the code gets executed. In the Interactive Diagram the tags specifying the source URL for the images would only be created during execution of the code. And in my experience changes in the HTML brought about by the code would not be processed by the browser until after the code stops executing. (E.g. in the Checkmating Applets, when the End-Game Table is being generated, if I add a row to the results table after every iteration, all rows appear at once, only after all iterations have been done.)

So control would have to be returned to the browser after the HTML for the table with piece images has been generated and inserted into the page, for the HTML to be interpreted y the browser, and make the newly defined HTML elements exist and become accessible. Otherwise getElementById would think the element does not exist, and return null.

This would completely upset the way the Diagram script works now. Which is creating the board first (including the style instructions to scale background images or not), and only then the table. Another problem is that the decision to resize or not can be dependent on the piece: in a set with variable image size some images might be larger than squareSize, and others might be smaller.

I think this opens a can of worms. Which is not worth it for makikng it possible to handle an occasional sloppily designed piece set.

I was examining what the individual Interactive Diagram for each piece reveals, and it gets some things wrong. For the Long Leaper, it indicates that it can capture a Pawn at the edge of the board, yet it cannot, because there is no space behind it to land on. For the Chameleon, it works the same as a Long Leaper, yet the Chameleon cannot capture the Pawn with the powers of the Long Leaper.

For some pieces, the individual Interactive Diagram just isn't that helpful. Since there is no King on the board, the Coordinator shows the same inability to capture as the Immobilizer. Also, both are given the Betza code `mQ`.

When I played a game, Coordinators captured as they should. This game didn't provide the same opportunity to test Immobilizers. At one point, it let me move into check and captured my King to win. After taking back some moves, it declared mate for a position I don't think is mate. Here is that game:

1. c3 a3 2. b4 Ca4 3. ff3 cxc4 4. Lb4 ch4 5. f5 hxc4 6. c5 Le5 7. Ixc3-b2 Lexc5-b5 8. Ib4 bc7 9. Kc2 cxc4 10. ?d5=P Lbxd5-e5 11. Wd2 Lexc3-a1 12. Xfxd2-d1 cg4 13. gf2 ag3 14. Cxc8-a8 Cxa8-a7 15. Kb1 Laxa2-a5 16. Wd6 Lh5 17. Wxe7-a3 Lhxh2-h1 18. Le1 W-h6-g5 19. ?a2=P W-e3-d2 20. Kb2 Wxe1-b4 21. Xd7 Kxd7

When I continued the game by moving my King into the corner, it did not capture my King, because the King was in fact safe.

This would be ideal, but I am not sure whether it is possible. The JavaScript is only aware of the URL of the image; it does not have access to the actual image data.

I looked up the solution and got this:

  var img = document.getElementById('imageId'); 
  var width = img.naturalWidth;
  var height = img.naturalHeight;

Here is a test:

I am confused. Which code was containing that?

Old code that's no longer on the page. When I switched the main set from Motif to Alfaerie, I removed those two lines.

Btw, why is the squareSize in the Diagram's initial specification set to 52, while all the sets seem to need 50x50?

I was testing the stretching of images.

In the case of Ultima there does seem justification to show an alternative: the inverted-rook representation is how many people might be used to playing it 'over the board', but some people (including myself) will find it very annoying to use orthodox piece symbols to represent entirely different pieces. But the original article already does propose an alternative piece set.

I much prefer my own Abstract set to the Alternative set David proposed, but I wanted to keep sets other people have preferences for. I could remove the Motif set, as I don't think we need multiple Chess set setups for this game. I think the Galactic set is ugly and has only a few images that make sense to me, but it was the default set for the previous Ultima preset for Game Courier, and I guess it got used a lot. The Alfaerie sets could be reduced if SVGs and high-resolution PNGs were made of some of the pieces not yet supported, such as Pincer Pawns, Spiders, and Kangaroos. Then there would be no need for using the Templar pieces for Pincer Pawns, and Alfaerie3 could be merged into Alfaerie1, and Alfaerie2 could use higher quality images.

I also think we should somehow get rid of the button for choosing between burners and tramplers.

I was just copying that from your original Interactive Diagram for Ultima. I would like to get rid of it myself, but from the rest of what you were saying, it sounds like we're not ready to do that yet.

It was using a lowercase prefix, yet the code includes these lines:

whitePrefix=W
blackPrefix=B

I am confused. Which code was containing that? I don't see those lines anywhere. Not in betzaNew.js, and not in the JavaScript embedded in the page. (Except in the buttons, but this is executed only when the buttons are pressed.)

At page load the color prefixes are set to the values specified in the definition of the Diagram, with lower-case w and b as defaults. Anyway, using the piece theme with the inverted Rook seems the right thing to do, as I recall that the original diagram in the article used that representation too (but using the small Utrecht set).

Btw, why is the squareSize in the Diagram's initial specification set to 52, while all the sets seem to need 50x50? The resizing that occurs because of this makes the images appear less crisp than they actually are.

I doubt the wisdom of offering so many different sets through buttons. This could be done in almost any variant, even those that only use orthodox pieces. Offering too many choices will just confuse the reader; standardization is a good thing. I think we should leave it to the author of the page to decide what representation he prefers. So I hope we are not going to do this in every article.

In the case of Ultima there does seem justification to show an alternative: the inverted-rook representation is how many people might be used to playing it 'over the board', but some people (including myself) will find it very annoying to use orthodox piece symbols to represent entirely different pieces. But the original article already does propose an alternative piece set.

I also think we should somehow get rid of the button for choosing between burners and tramplers. This is not something we should bother people with who only want to learn the rules of Ultima. I put that button in the comment, because that comment mainly served the purpose of showing the newly added capabilities of the Diagram, and give people an opportunity to judge the different move-entry methods. I think everyone would agree that for Ultima it is much better to treat the pieces as burners (i.e. all side-effect captures fully automatic, without the need to click any victims). So we should just make the Diagram in the Ultima article always do that. Problem is that the Diagram is not smart enough to judge whether treating pieces as burners would cause ambiguity of the entered moves. So the treatment as burner would have to be requested in the Diagram definition, (and otherwise default to shooter/trampler). And I have not implemented a method for doing that yet.

In the examples you give of where stretching is helpful, the image is larger than the space. So, perhaps you could check the size of each image and apply stretching only if the image is larger than the space.

This would be ideal, but I am not sure whether it is possible. The JavaScript is only aware of the URL of the image; it does not have access to the actual image data. It passes the URL to the browser by inserting it into the innerHTML of some element on the page, and then the browser takes care of loading and formatting the image. This process can only be controlled through the style specifications, in particular background-size. There doesn't seem to be a directive there to demagnify only if needed. The betzaNew.js script uses contain.

I admit there is a problem here, but I am not sure what the best solution is. To allow the use of overly-large images for zoom friendliness, there will have to be a size specification for the size background image. Otherwise too-large images would be clipped to the size specified for the table cell. I never tried using SVG as background, but I suppose the behavior would be the same there, as such images also have a natural size.

But in the early days of the Interactive Diagram pieces were displayed as cell content (and highlighting could only be done through background color, not by symbols, which made it unsuitable for monochrome displays). This posed the problem that it always tried to make the height of the cells larger than that of the image (apparently to leave space for 'true descenders' of the font). This would lead to expansion and contraction of board ranks depending on whether these were empty or contained a piece, unless the squareSize was specified larger than the piece images. So many Diagrams made in those days would specify squareSize=54 when using the 50x50 Alfaerie GIF set. This is no longer needed now that the standard script displays the images as background; the size of a background image does not affect the size of the cell, like the content does. But it would be undesirable if these Diagrams now started scaling the GIF piece images to 54x54, with loss of image quality.

I could make the inclusion of the background-size:contain style specification dependent on a parameter, so that it gets omitted by default, and would not affect existing Diagrams. But if our future default for this website will use overly large (say 100x100) raster images or SVG for the piece sets to improve quality on zooming, it means we will have to include an extra parameter for this in the Diagram specification for eternity. I don't like that very much. It would be better to just keep the old betza.js script as it was for Diagrams that already use it, and let future Diagrams use the new script, which scales the images by default (but can suppress that through an option). Keeping two versions of the script for eternity is also not ideal, but only the newest version would have to be maintained, as the old version should alreaady satisfy the needs of all existing Diagrams that used it.

For now, I have made the main set an Alfaerie Chess set with an inverted Rook, because Alfaerie will show up when the page loads.

The latter was done to allow use of larger-than-needed raster (as opposed to SVG) piece images, which then would allow zooming without too much image degradation. E.g. the Diagram in the Minjiku Shogi article uses the 50x50 alfaeriePNG set, but has a 100x100 GIF image for the Fire Dragon.

In the examples you give of where stretching is helpful, the image is larger than the space. So, perhaps you could check the size of each image and apply stretching only if the image is larger than the space.

To figure out why the pieces are not showing up when the page loads, I opened up the table of information on the pieces and looked at the URL for one of the broken images. It was using a lowercase prefix, yet the code includes these lines:

whitePrefix=W
blackPrefix=B

So, I think there is a bug.

The easiest solution is probably to edit the images so they all get the same size.

I'm sure that is not the easiest solution. There should be a programming solution that treats different files differently, as Game Courier and the Diagram Designer are able to do. Or maybe you could add in a toggle that indicates whether images should be stretched.

I guess the different behavior of the Chess and Ultima Diagrams occurs because these make use of different Diagram scripts. These past months I have been working on a 'next generation' of the Diagram script, which for now is called betzaNew.js instead of betza.js (in the same directory, /membergraphics/MSinteractive-diagrams/). This new script uses the AI's move generator for move entry and execution. This allows entry of moves with more than 1 locust victim, which the old code (from before the addition of an AI) that is being replaced could not handle. That conversion is not really completed yet (move notation for triple captures is still lacking), but Ultima can only be handled through betzaNew.js.

This betzaNew.js also differs from the old one by including a style attribute for the table cells "backround-size:contain", (the piece images are displayed as background, so the highlighting markers can be displayed in front of those as cell content), to force too-large images to fill the cell. The latter was done to allow use of larger-than-needed raster (as opposed to SVG) piece images, which then would allow zooming without too much image degradation. E.g. the Diagram in the Minjiku Shogi article uses the 50x50 alfaeriePNG set, but has a 100x100 GIF image for the Fire Dragon. (This because the GIF, which I needed for animation, does not seem to support an alpha channel, which would cause a ragged outline, unless I make the browser smoothen it on demagnification.)

This 'contain' specification also stretches images that are too small to fill the cells, and apparently stretch the horizontal and vertical dimension independently.

The Diagram script was designed for using piece images of a uniform size. The easiest solution is probably to edit the images so they all get the same size. This is what I did for the 'Horizons' piece set used in the Stone Garden Chess article.

H. G.,

I've started working on a new version of your Interactive Diagram for Ultima that includes multiple piece sets, but I am having some issues with it. The first is that no pieces show up when the page loads. I have it set up to use the Motif set, which does show up when I hit the Motif button, but not when the page loads. The second issue is that the Abstract, Motif, and Ultima-Alt sets are being stretched to the borders of each space. My Interactive Diagram for Chess, which also uses Abstract and Motif, is not stretching the images, and I don't know why they're behaving differently. While the Alfaerie pieces are all the same dimensions, my Abstract and Motif pieces are not, because they don't include any extra surrounding space around the images. This is probably one of the factors involved, but the Interactive Diagram for Chess isn't having a problem with them.

According to the description with the animated illustration linked to on this page, the chameleon "can only capture Pinching Pawns by moving like a Rook."

Another question. Can a Chameleon capture Pawns with a diagonal move? Or, since Pawns move like Rooks, can it capture a Pawn only if it makes an orthogonal move?

In Zillions-of-Games, the Java applet, and the Interactive Diagram, it had to make an orthogonal move. So, I'll assume that's the rule unless it's overruled.

I recreated the same position in Zillions-of-Games, the Interactive Diagram, and Ed Friedlander's Java applet, and in every one of them, the Chameleon could not capture the Long Leaper. I'll assume this is the de facto rule unless Abbott chimes in otherwise.

I have a question about this position. If the piece on f5 were a Long Leaper, it could capture the Long Leaper on c2, and it would capture the Withdrawer on e4 along the way. But since the piece is a Chameleon, can it still move to b1 to capture the Long Leaper on c2? If nothing were on e4, it would be free to. Since it can't capture the Withdrawer by leaping over it, does that block it from being able to capture the Long Leaper? Or could it leap over the Withdrawer without capturing it and capture the Long Leaper on c2?

To answer my question, I looked up the chapter on Ultima in Pritchard's Popular Chess Variants, and he wrote, "An immobilized king can be mated by its rival moving next to it." So, unless Abbott has said differently somewhere, I'll take this as the rule.

Can an immobilized piece still check a King? If not, could a King move up to an immobilized King and checkmate it? I'm asking, because I'm programming it for Game Courier, and I'm getting ready to add code for the Immobilizer.

pieces are tramplers

I thought Nebiyu Alien can play Ultima too. (Under the WinBoard Alien Edition.)

I'll take the opportunity here to point out that quite a while ago I noted, as a comment on this CV's preset intro page, that the preset for Ultima on Game Courier appears to have a bug now. Even just trying to issue an Ultima invitation results in an error message page that's filled with coding.