Ratings & Comments

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.

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.

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.

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 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.  ...

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.

Perhaps an editor who knows how to do this can move this comment to the Dating Chess discussion? Currently it is an off-topic comment on Pink Chess.

In between I had the thought to make a distinction to the position of the king, then I lost sight of it.

In the description of my variant, a distinction is now made between variant 1 (king without special status) and variant 2 (king with special status).
Thanks for the hint.

Should I presume that in variant 1, a King may move to or stay on an attacked space, and in variant 2, a King may not move into or remain in check?

Saying a captured piece returns to the 'starting position' is a bit confusing, as one could easily understand it to mean 'the square where it was in the initial setup'. Better just say that a captured piece is 'put on the square its capturer came from'.

The name of the variant seems a bit lengthy. Perhaps you should call it just 'Conquer'. (Or perhaps 'Abduct', 'Convert' or 'Bribe' would describe it better.) That you would be fighting the opponent's army is sort of self-evident.

This way of recycling pieces is a nice alternative to piece drops. It does seem to invite perpetual recapture, though. E.g. if a Rook is attacked as well as protected by a Rook, these Rooks could continue capturing to the same square forever, while not capturing could leave you down a Rook. Perhaps some rule against repetition is needed. Like that you cannot make the same move as the previous times the same position occurred.

I suggest Shako