Enter Your Reply

I did not mean to propose hiding the table like the piece legend for the diagram is hidden by default. Or even have the diagram generate it 'on the fly' in the client's browser. (Noe that the diagram can make the piece table appear anywhere on the page, in a place of your choice, through the satellite parameter.) The problem with the latter is that it would not work for people that have disabled JavaScript in their browser.

So I can see why you, and presumably many others, want such a list in your articles. So my proposal was actually: given the fact that the piece names / images / moves already have to be specified to create a diagram, couldn't we make life easier for the author by offering him as a free side effect the HTML for an (almost complete) table, which he just has to copy-paste into his article in the place where he wants it to appear? Most people would create the diagrams through the design wizard or the play-test applet, and would then copy-paste the provided HTML for the diagram into their article. They could do the same for a table with textual descriptions, which the design wizard would show in another text-box (or perhaps in the same box, after pressing a button "Piece Table".

And it doesn't matter whether the descriptions for complex pieces like Lions or Hook Movers would be inaccurate, clumsy or missing; there will be only few of such pieces, and the author can edit their description by hand after he copy-pasted the table into his article.

That is a genius idea. I would love to see something like that.

As to the format of the table - What I meant was this:  In the article above you use the piece names in the first column. E.g. "King", and then the text says "The King moves one step in each direction". Mentioning "King" twice here is redundant; you could have said "Moves one step in each direction", because people already know it pertains to the King from the first column. But I think it would be better to keep the piece name in the move description, as you had, and replace the name column by an image column. Presumably you did not do that because it is a lot of work to write all the HTML image tags with the URLs of the images. But when generated automatically that would not be an issue. It would also not be an issue to attach a handler to the table cells so that clicking on them would evoke some response (for those with JavaScript enabled). E.g. like opening/closing a normally hidden able row right below the one clicked, which by default would be empty, but which the author could use to provide a hand-made move diagram.

Actually, the reason I did the table the way I did for this game and Taishin Shogi rather than using the format I used for my smaller shogi variants (the piece images and the name in a column within the cell) is because of the size limit for the HTML editors. There is an actual limit programmed into the HTML editors on the site for how big a HTML script can get, and using the format for my smaller games exceeded that limit for both this game and Taishin Shogi because the piece list was so big. However, when I took out the images, it worked just fine, so I decided to just leave the images out. Automatic table generation is a good idea, but the size limit might make it unfeasible with images, depending on the size of the script.

I also wanted to keep the format between my Shogi variant pages as consistent as possible. Indeed, making the list is a lot of work, but a consistent format across pages makes it much easier by letting me copy-paste the text for each piece into the appropriate cell.

Also, the redundency may not actually be a bad thing. I've seen quite a few CVP articles by other people that have the piece name in both the image and the move description.