Check out Symmetric Chess, our featured variant for March, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

Later Reverse Order Earlier
MShook-shogi[All Comments] [Add Comment or Rating]
A. M. DeWitt wrote on Fri, May 14, 2021 08:43 PM UTC in reply to H. G. Muller from Sat May 8 07:53 AM:

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.


H. G. Muller wrote on Sat, May 8, 2021 07:53 AM UTC in reply to A. M. DeWitt from 12:28 AM:

However, it is important to keep in mind that if the descriptions for the pieces are all kept within the diagram itself on a CVP article, then people might not know where to find the moves of the pieces, even when the text used to open/close the table mentions descriptions.

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.

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.


A. M. DeWitt wrote on Sat, May 8, 2021 12:28 AM UTC in reply to H. G. Muller from Mon Apr 20 2020 06:35 PM:

When I replied to this initially on the interactivce diagrams page, I should have posted it here...so here is my response in the proper place.

It's a good idea to think about. The main problem lies in describing very complex pieces such as those in Ko Shogi, but most variants don't have pieces that complex.

The main issue with implementation is where you would put the description. I would put it at the end, as a description is entirely optional. You will want to make a distinction b/w the pieces in hand and the description, though this is likely very easy to implement.

However, it is important to keep in mind that if the descriptions for the pieces are all kept within the diagram itself on a CVP article, then people might not know where to find the moves of the pieces, even when the text used to open/close the table mentions descriptions. This is why I always have, and always will, keep all piece descriptions in the Pieces section of my CVP articles, which is meant to fulfill this purpose. As a result, having descriptions in the table would actually benefit other sites more than it would benefit this site. Even so, the benefits of such a feature are worth considering.


H. G. Muller wrote on Mon, Apr 20, 2020 06:35 PM UTC:

Nice application of the Interactive Diagram. I didn't try to digest this game yet, but I have a general question about your presentation. Your article contains this list of piece descriptions in English. Do you think it makes sense to have the Interactive Diagram, or perhaps the Design Wizard for the diagram, produce such a list automatically? For most pieces it will not be that difficult to 'rephrase' a Betza move description in English. And your list for these games could serve as guidance for what we want a description to say. (E.g. for Gold = WfF, should we make it say "moves one step orthogonally, or one step diagonally forward", or "moves one step in all directions, except diagonally backwards".)

If the Design Wizard would generate such a list, the author could just copy-paste that in his article, and perhaps add some further explanations for the more complex pieces, or change any wording he did not like. The first column should really be images, I think. Just having the piece name there, and then starting the description also with the piece name, is a bit double. It would already be helpful if a table was generated with all piece images in the first column, and the name in the second, so that the author could write the move decription after the text. But for simple pieces also generating a reasonable text should not be too difficult.

What do you think?


🕸Fergus Duniho wrote on Mon, Apr 20, 2020 02:22 AM UTC:

TL;DR, but I skimmed over it, and it looks in order. I do not know Betza notation well, but you did include English descriptions of the piece movement too, and you identified the location of each piece, which is all good. I will leave this to our Chu Shogi fans to scrutinize more closely.


5 comments displayed

Later Reverse Order Earlier

Permalink to the exact comments currently displayed.