Comments/Ratings for a Single Item

In the text the flying cat is said to be fN but it's moves are fDfA.

Nice spot. Turns out it was also in Dai Seireigi. I fixed both.

Chu Seireigi is ready

The new version of Chu Seireigi is ready.

Two critiques:

1. In keeping with the Running Wolf and Running Leopard, the Running Rabbit probably should have the Wind modifier behind it (rabbit--wind).

2. I'm not sure that a piece should promote (when promotion is at the far end of the board) to something whose primary move is forward, as the Gold General does into the Great Elephant. (I'd suggest Phoenix instead, but then you'd probably have to change Silver General to promote to Kirin for symmetry's sake.)

Otherwise, I'm loving what I'm seeing.

@Bob Greenwade,

Here is my response to your two critiques, in the order that they are listed in your comment.

1. In keeping with the Running Wolf and Running Leopard, the Running Rabbit probably should have the Wind modifier behind it (rabbit--wind).

1A. Now that I think about it, I think it may actually make more sense to not have modifiers on unpromoted pieces where possible. The most important part of the graphics are the animals (except when pieces are not animals, such as with the Rook and Bishop) for obvious reasons.

2. I'm not sure that a piece should promote (when promotion is at the far end of the board) to something whose primary move is forward, as the Gold General does into the Great Elephant. (I'd suggest Phoenix instead, but then you'd probably have to change Silver General to promote to Kirin for symmetry's sake.)

2A. The main refutal of this critique comes from H. G. Muller in his critique of an early version of Seireigi. In that comment, he quotes Hidetchi in a response to an old proposal to have Golds promote to non-royal Kings. Hidetchi replied that this was pointless because it doesn't provide anything of substance with which to check the enemy King with, and the act of dropping a general in the zone, promoting it and then moving the resulting promoted piece takes unaffordably long. Hidetchi's point is that he King tends to stay in the back for the majority of the game, and would never expose itself willingly. As such, forward-facing moves are needed in order to force the enemy King to an area where he can be checkmated.

Also, having such pieces is perfect for promotion chains, as they can serve as an intermediary between a weak piece and a strong piece that exclusively appears with promotion. For example, in Dai Seireigi I can have the Free Pup and Treacherous Fox in the initial setup and promoting to something stronger.

However, even if both of these reasons were to be completely untrue, the pieces that promote to them mainly serve as defensive pieces since their moves are weak but maneuverable and are effective at stopping Lion attacks, so they are unlikely to occur anyway.

I have decided to rename the Free Pup to Whale, to include a marine animal and balance out the number of dog and cat piece types (bears are dog-like).

This change also applies to Dai Seireigi.

the description of Treacherous Fox needs an update

As far as I can tell, the only typo I made was not changing Great Stag to Treacherous Fox in the move description.

@François Houdebert,

I saw your Jocly implementation for Chu Seireigi. It works much better than it used to.

I went through and tested everything, and here is a comprehensive list of all known errors that I found:

-------------------------------
Piece Movement/Promotion Errors
-------------------------------

Ram's-Head Soldier and Prancing Stag are not forced to promote when reaching the last rank (these pieces must promote on last rank)

Strong Bear (Starting and Promoted) still has its old move (should move one square diagonally or sideways)

Whale is missing its forward orthogonal step

Flying Swallow is not forced to promote when reaching the last two ranks (this piece must promote on last two ranks)

White Golden Bird is missing its sideways orthogonal leaps, Black Golden Bird is missing its (1,-2) leap from White's perspective

Kirin promotes to Lion (should promote to Bishop) and White Kirin moves has extra (2,2) leap in all directions (should move as in Chu Shogi)

Phoenix promotes to Queen (should promote to Rook)

-------------------------------
Board Setup Errors
-------------------------------

There currently aren't enough spaces in the hand to accommodate all the droppable piece types (there are 19 in total). You will need a second column of hand spaces on each side to account for this.

Black Running Leopard and Black Running Wolf are swapped from where they should be in the initial setup.

Most of the Movement/Promotion adjustments have been made. The only point I'm having trouble with is finding a way to extend the number of places for hands. I'd probably have to override the drop model, but I'm not sure I could do it quickly on my own. Anyway, for the time being, it's a good way to get familiar with the rules.

Thanks. Hopefully we can also upload your implementations of Hectochess and Seireigi to the site soon.

I have tested the new moves and will update you on bugs to be fixed. Here are the errors I found as of the writing of this comment.

-------------------------------
Piece Movement/Promotion Errors
-------------------------------

Whale is missing its backward slide

White Golden Bird is missing its sideways orthogonal leaps

For some reason Flying Swallows that are dropped from the hand (not the ones present initially) have their move reversed

-------------------------------

As for the trouble with the hand spaces, maybe ask H. G. Muller about that? He is the one who made the original model if I remember correctly. It shouldn't be that hard for him to figure something out.

As far as I can tell, you should only need a second column of hand spaces on each side, but of course, it's probably not as simple as I am making it out to be.

I think I've corrected the bugs you mentionned.

If HGM has the time and the possibility to add the parametrisation of the hand space in the drop model, of course I'll use it, but I don't know if it's that easy to do.

I can share a zip if you want, with these 3 compiled games (Hectochess/Seireigi/Chu Seireigi)?

Looks like you fixed everything, save for the hand spaces of course, but I won't bother you on that too much until you are ready to test the solution.

I would at least like the ones for Hectochess and Seireigi. Ideally, the files should be placed in such a way so that I know which files go where.

You may include Chu Seireigi if you wish, but I am doing one last update to make it easier to defend against a Lion:

• Renaming Prancing Stag to Running Rabbit (fBfR), which promotes to Prancing Stag (fBsRvW)
• Strong Bear moving the same as Chu Shogi Drunk Elephant

I had your Jocly implementation play out several games, and even though it played rather poorly (for obvious reasons), it was clear that there needed to be more defense.

P. S. I'm surprised you changed the Whale's symbol to a trident. I guess it makes sense if you take into account Greek mythology. I think the whale tail symbol you used before would look more accurate, but it really comes down to personal preference here.

In general, I try to associate a visual with a movement whatever the game in jocly. I don't know if it's the same for everyone, but I have to adapt a lot when the movements of a known piece change. That's why I used the trident that had been envisaged for the whale in chu shogi. I realized that the movement differed from that of the whale in chu shogi when I was making the documentation, and it seemed preferable to me to avoid confusion.

It would be interesting to add mnemomic sprites as an alternative. I don't know if you'd be interested in making such a file.

Here's an SVG seireigi set if you want to test the creation of a physical game. Example in plywood (compact / cheap and quick to make but rather simple), the color code for laser cutter is red/cutting, blue engraving recto, yellow engraving verso.

Here's a link to the jocly seireigi and hectochess implementations. It would require to code evaluation function to improve the level of the engine  which still needs to be done, and will probably require some expertise. Personally, I don't mind the computer being beatable.

Here's a link to the jocly seireigi and hectochess implementations. It would require to code evaluation function to improve the level of the engine  which still needs to be done, and will probably require some expertise. Personally, I don't mind the computer being beatable.

The link is broken, it seems... Actually, do include the Chu Seireigi implementation. Testing with it will be valuable.

In general, I try to associate a visual with a movement whatever the game in jocly. I don't know if it's the same for everyone, but I have to adapt a lot when the movements of a known piece change. That's why I used the trident that had been envisaged for the whale in chu shogi. I realized that the movement differed from that of the whale in chu shogi when I was making the documentation, and it seemed preferable to me to avoid confusion.

Okay, makes sense.

It would be interesting to add mnemomic sprites as an alternative. I don't know if you'd be interested in making such a file.

Here's an SVG seireigi set if you want to test the creation of a physical game. Example in plywood (compact / cheap and quick to make but rather simple), the color code for laser cutter is red/cutting, blue engraving recto, yellow engraving verso.

Maybe, once I finalize everything.

I am currently testing the KNAD move for the Lion. Unfortunately, I am no carpenter, but your set looks good (though you did forget the Coppers in the plywood example.)

Here is a link in https for the implems of hectochess-seireigis to avoid complains from some Browsers

The Coppers are not in the pictures but are in the svg. With inscape you might have to zoom to see all the drawings because of the various thichness of the lines, but laser cutting software can handle this king of file.

If HGM has the time and the possibility to add the parametrisation of the hand space in the drop model, of course I'll use it, but I don't know if it's that easy to do.

In the current drop-model.js you can request extra ranks for hand pieces above and below the board, in case there are more piece types that can go in hand than there are board ranks. Does that satisfy your needs?

I'm going to give it a try and see what it does, but how do I go about it?

Do I need to specify anything in the model to the cbDropGeometry?
Or in the view at the boardLayout?

It should be explained in the commit message of the drop model. Unfortunately that is not easy to access now that GitWeb is disabled on my website (I haven't had time to fix that yet). But if you have pulled the pullreq branch you should be able to see it on your local machine.

I found it. I understood that the 3rd parameter of

cbDropGeometry(files, ranks, bottomHoldings) can be used to add rows

I will test it

I made a first draft. It seems to work.

I still need to find a way to adjust the sprite sizes. Is it possible to display a grid? maybe it's hidden by size issues.

I actually found a better replacement for the Old Kite with the Running Rabbit (fBfR).

Thankfully, this is the last time I will need to make any changes.

Here are all the errors I found in your draft:

Piece Movement/Promotion/Drop Errors

Old Kite should be replaced with Running Rabbit, which slides in any forward direction (fBfR)

For Pawn, Lance, Ram's-Head Soldier, Running Rabbit (currently Old Kite), Knight, Flying Swallow, White's promotion is always forced, while Black's promotion is never forced

When captured, White Kirin is not being placed in Black's hand

Board Setup Errors

White King and White Great Elephant are swapped from where they should be in the initial setup.

Other

The grid seems a little off, but you probably already knew that.

I fixed it from the rabbit / kirin / elephant : current dev version

For the grid display, it's going to take a little time, I need to understand how it works quietly.

The forced promotion issue is fixed for White's forward-only pieces (Pawn, Lance, Ram's-Head Soldier, Running Rabbit, Knight, Flying Swallow) but not for Black's.

Updated !

Is it Better now?

Much better.

The only improvements I can think of are reintroducing the 3d pieces, naming the game Chu Seireigi instead of Chu Seireigi Shogi (for the same reasons as with normal Seireigi), and maybe having the hand spaces all colored solid brown. But for the latter the wood is colored similarly enough that it doesn't really matter whether you do it or not.

Also, could you update that SVG for the laser cutter? I might want to make a plywood set in the future. But for now, the cutouts I made will do.

I've updated the title and will try to update the svg a little later, I'll be a little less available.

Bringing back the kanjis would be interesting to give a Japanese aesthetic, but I feel that to play a mnemonic skin would be a better alternative from my point of view.

The 3d pieces are back. here the seireigis and hectochess updated.

I saw that the wa shogi was also a medium shogi with drops having a running rabbit (FfRbW) and a Treacherous fox(FAvWvD).

I was surprised that they didn't have the same movements. I wondered whether a different adjective might be better to distinguish them: e.g. cunning fox and vigilant rabbit, Same for the whale with chu shogi.

I saw you added the 3d Kanjis back to Chu Seireigi. I went through and tested everything, and here are the errors I found

Incorrect 3d Kanji Readings

• Unpromoted Great Leopard (should say 大豹)
• Promoted Knight (should say 天馬)
• Promoted Silver (should say 走狼)

Other

• Promoted Lance, Gold seem to crash/softlock the game
• Promoted Copper General (大豹), Promoted Running Wolf (奔猪) assets doesn't load
• Promoted Kirin (角行), Promoted Phoenix (飛車) indistinguishable from unpromoted counterparts (kanji should be colored red)

P.S.

I was surprised that they didn't have the same movements. I wondered whether a different adjective might be better to distinguish them: e.g. cunning fox and vigilant rabbit, Same for the whale with chu shogi.

That was because I found the Wa Running Rabbit to be too similar to the Lance, and knew that it would add too much defense after testing with the Old Kite. So I gave the Running Rabbit the ranging moves from its Taikyoku counterpart while omitting the stepping moves. The reason it has the same name as the Wa Running Rabbit is because it is one of only two Taikyoku pieces to be a rabbit, and I thought the running kanji fit better. As for the whale, its backward bias was a problem, so I replaced that move with the current one.

I made some corrections.

ctrl+f5 : may help to reload scripts in case of cache issues

Here are the errors I didn't find before or are new:

Incorrect 3d Kanji Readings (all should be colored red)

• Promoted Lance (should say 奔虎)
• Promoted Gold General (should say 大象)
• Promoted Kirin (should say 角行)
• Promoted Phoenix (should say 飛車)

I hope it's ok now

Looks like everything works properly.

Can you send me the updated files for Seireigi and Chu Seireigi (I have already taken care of Hectochess)?

here you go

Thanks.

Note that it is possible to control the way the captured pieces are placed next to the board by defining arrays Model.Game.handLayout[color][handIndex]. This array should contain the square numbers where you want the first captured piece of the given color (1 or -1) and hand value to be placed. (A second piece will be placed at sqr+color, and after that counters will appear between the two shown pieces.)

Currently the default assignment is used, which places the white pieces on the first 'file' on the right of the board, the hand number equal to the rank number (which starts at 0). By defining a handLayout you could also use the ranks under or above the board to place pieces, thus requiring fewer extra ranks.

E.g. with a single extra rank (instead of the 4 you have now) you could place 6 white pieces below the board, and 14 white pieces to the right of the board.

It's good to know that you can use the bottom squares for that. Does it mean that we have to specify something like Model.Game.handLayout[1][{2:18,4:17}]; // eg : square 2, hand 18 for the white for each piecetype?

No, you have to write something like

Model.Game.handLayout[1] = [0,2,4,6,8,10,12,14,30,46,62,...];

if you want the first 8 'hand squares' for white to be at the bottom, and the rest along the right edge.

I gave it a try here. I think It looks better this way.
@Adam: apart from the adjustments linked to the changes, what do you think?

I guess the drop model still needs some tweeking. The square painting on the hand ranks should be the same as that of the other hand squares. Now there seems to be no coloring at all, so that the rim texture shines through. I suppose the logical way to do this is that the square-painting array that has to be defined in the game's view file should include the extra ranks.

It is also not clear to me why the 'counter piece' in the lower-right corner is larger than the others.

[Edit] The array boardLayout defined in the view file is accessed in two places in grid-board-view.js, inside nested loops over rows and columns. The loop over rows was modified to skip the extra hand ranks. I suppose this was a bad idea; especially in the 'paintCells' function it should have run over all ranks, requiring the boardLayout to also specify how the cells in these extra hand ranks should be colored. There is a second routine 'paintInCoordinates' that also loops over all cells, which does more complex things and might need more subtle modification than just changing the loop limits. But it seems this function is not normally used.

The handLayout[-1] in the view file appears to have a 16 where there should be a 17, which causes misplacement of the 'counter piece' on 15 rather than 16.

The change in paintCells was necessary because the grid wouldn’t display. May be that a better modification is possible, but I don't think I'm in a position to make it.

After a few modifications, current result

I don't know if you'd like to have a look at sources : latest to check grid-board-view.js

Your current setup for this game looks way better, but I did notice a few errors were made while making the new version. I also noticed a bug in the Hectochess implementation.

---------------------
Chu Seireigi Setup Errors
---------------------

White Kirin and Phoenix are swapped from where they should be in the initial setup

Black King and Great Elephant are swapped from where they should be in the initial setup

---------------------
Chu Seireigi Promotion/Drop Errors
---------------------

Pawn, Lance, Running Rabbit, Knight, Gold General, and Great Elephant are currently allowed to promote immediately if they are dropped into the promotion zone (this should not be the case)

White Copper General is put in same place as Black Lion in hand spaces, resulting in the hand space setup looking asymmetrical (White Copper General should be placed between the Great Elephant and Running Wolf)

(Also, because of this bug, a "King" may sometimes appear in current hand space of extra White Copper Generals/Black Lions for some reason...though this thankfully doesn't affect anything)

---------------------
Hectochess Castling Error
---------------------

When attempting to castle, the Champion's starting squares (b2/b9 and i2/i9) and queenside Knight starting squares (c2/c9) are not checked to see whether a piece is occupying them or not.

I think that all that is needed is to make the 'row' loop run from 0 to NBROWS, and remove the -NBVHND from

this.cbView.boardLayout[NBROWS-NBVHND-row-1][col]

 And then putting the extra hand ranks in the boardLayout defined in the game's view file. I don't think there are any other games yet that use extra hand ranks. I implemented that feature with Wa Shogi in mind.

The paintCells function is not involved in drawing the grid.

I had already looked at the sources, by looking at the chu-seireigi-view.js of the compiled version. Since you build Jocly without uglification all used source files are in there unmodified.

In that case : I get in 2d with pictos

Uncaught TypeError: this.cbView.boardLayout[((NBROWS - row) - 1)] is undefined
    paintCells chu-seireigi-view.js:1509
    paintChannel chu-seireigi-view.js:1530
    draw chu-seireigi-view.js:941

Would this come from using the draw function wrongly in my view : chu-seireigi-view.js ?

Note that I have the impression that with the modified version the result is satisfactory with or without extra hand ranks.

That's why I'd like your opinion on grid-board-view.js, because I thought it would be useful to transfer this modification to the pullreq branch for jocly.

If you'd like to make an implementation of wa shogi, here are some unused jocly-compatible sprites that might come in handy.

To be seen if useful

Uncaught TypeError: this.cbView.boardLayout[((NBROWS - row) - 1)] is undefined

This sounds like an out-of-bounds access on boardLayout. Are you sure you defined that array with sufficiently many ranks? To further diagnose the problem you could add console.log(NBROWS-row-1); just before the access to boardLayout in paintCells; then you could see in the console  what the offending value is.

the array length is 19

NBROWS-row-1,row: 13, 0

Strange. 13 should be a valid index for an array of length 19. That means the array should have some internal elements that are undefined. What happens if you print

console.log( this.cbView.boardLayout )?

19 is the size of handLayout

boardLayout :
0: "##............##" ​
1: "##............##"
​2: "##............##"
​3: "##............##" ​
4: "##............##" ​
5: "##............##" ​
6: "##............##"
​7: "##............##"
​8: "##............##" ​
9: "##............##" ​
10: "##............##" ​
11: "##............##" ​
length: 12

Should I add : Should I add " ##############" before and after?

Should I add : Should I add " ##############" before and after?

Indeed, you should, because you want the extra hand ranks to be colored black as well.

thanks for the advice.

I have modified accordingly

Looks good, save for a few errors:

---------------------
Setup Errors
---------------------

White Kirin and Phoenix are swapped from where they should be in the initial setup

Black King and Great Elephant are swapped from where they should be in the initial setup

---------------------
Promotion/Drop Errors
---------------------

Lance, Running Rabbit, Knight, Gold General, and Great Elephant are currently allowed to promote immediately if they are dropped into the promotion zone (this should not be the case)

Both Pawns in the hand spaces can be selected when multiple Pawns are in the hand)

It should be ok now

Looks like it. I have uploaded the new version to the site and have adapted them so the implementation will work properly with the CVP files.

Note that the SVG for laser cutting is updated with a rabbit.

Also the doc has been improved a bit in jocly.

Thanks.

Out of curiosity, what program did you use to make the Seireigi Jocly sprites?

I am trying to fix a visual bug involving the 2d Kanji kings in Seireigi's implementation. The King with the extra stroke in the 2D Classic set is used for the player that moves second, when it should be used for the player that moves first.

I use gimp. if the general of jade should be white (player a), it could be changed in seireigi-shogi-model.js

keep me posted I'll have to make the change too.

You should only have to swap the King kanjis in the 2D Classic Seireigi sprites.

For the 3D pieces its as simple as swapping "sh-king" and "sh-jade" in the 3D piece definitions in the *-view.js files, so no problem there.

P.S. What I said above also applies to the Shogi Jocly implementations that use the King kanji on the biscandine site.

P.S.S. Also you have two extra rooks in your laser cutter SVG.

you can also swap the 2d in the same *-set-view.js

It not clear to me, when there's an apostrophe, it's the general of jade that corresponds to the blacks, right?

It not clear to me, when there's an apostrophe, it's the general of jade that corresponds to the blacks, right?

In kanji sets, the player that moves first always has the King with the extra stroke. And it is true that the player who moves first is called Black (or Sente) in Shogi. It's just that in Jocly and the Mnemonic sets by H. G. Muller, the player that moves first has the white piece images by convention to make it easier for chess players.

I made the modification on my branch,

I'll wait to see if HGM wants us to do the same on the branch that will go into jocly.

The Wikipedia has it that the player with the weakest player has the Jade General, and the strongest player the King. I am not sure if and how we should implement that in Jocly.

I'll send you an updated pictogram spritesheet that you can use. Currently, the pictogram images still have the Kanji for the Kings since they are pulling from those locations.

Here is my updated version of your spritesheet. (For best results, clear browser cache before downloading)

I also took the opportunity to clean up stray pixels in your other shogi spritesheets.

www.chessvariants.com/membergraphics/MSchuseireigi/jocly-shogi-sprites.zip?nocache=true

do you want me to replace the sprites Adam just sent for shogi on the pullreq branch?

ok, taken into consideration

I also updated the seireigi-sprites file one more time so that the promoted Kanjis are all facing the right way.

www.chessvariants.com/play/jocly/dist/browser/games/chessbase/res/shogi/seireigi-shogi-sprites.png

P. S. GIMP is awesome.

I have done it but not sure it is a good idea because if you use "view as player B". It won’t be correctly oriented.

I have done it but not sure it is a good idea because if you use "view as player B". It won’t be correctly oriented.

Well, that problem was kind of already baked in to begin with, unless you used a separate piece style like you do with the Shogi Motif pieces on the biscandine site.

The point is to make sure all the 2D Kanji are oriented correctly on the biscandine site. Anyone who has played Shogi long enough would immediately notice something was wrong with the second player's promoted minor pieces if they used the 2D Classic set for Seireigi.

The author, A. M. DeWitt, has updated this page.