SjaakII 1.0 RC1

[Evert]

I was trying to find out yesterday how I would configure Wa Shogi and whether there is enough pieces. There are only 17 types not including promotions so I guess we are good to go. A working Tenjiku would be great as there is English documentation to play it. But I never have.

SjaakII wouldn't be able to play this (it can only handle 16 piece types), but the following patch against SVN 358 should allow you to extend this to 32 piece types, which should be enough for Wa Shogi if you want to try making a variants.txt configuration for it (you still need to assign a single character to each piece though, but since half of them are actually promoted pieces that should be enough).

Code: Select all

Index: ../include/pieces.h
===================================================================
--- ../include/pieces.h	(revision 358)
+++ ../include/pieces.h	(working copy)
@@ -21,14 +21,14 @@
 #include "moveflag.h"
 
 #define MAX_PIECE_TYPES    32 //16
-#define PIECE_BITS          4
+#define PIECE_BITS          5
 
 #define MAX_STEPPER_TYPES  16
 #define MAX_LEAPER_TYPES   16
 #define MAX_HOPPER_TYPES   16
 #define MAX_SLIDER_TYPES   16
 
-typedef uint16_t piece_bit_t;
+typedef uint32_t piece_bit_t;
 
 /* Bitfield colours */
 typedef enum side_t { NONE=-1, WHITE, BLACK, NUM_SIDES } side_t;

[Evert]

Actually, use revision 360 (http://www.eglebbk.dds.nl/program/downl ... src.tar.gz) and the following patch:

Code: Select all

Index: ../include/pieces.h
===================================================================
--- ../include/pieces.h	(revision 360)
+++ ../include/pieces.h	(working copy)
@@ -21,14 +21,14 @@
 #include "moveflag.h"
 
 #define MAX_PIECE_TYPES    32 //16
-#define PIECE_BITS          4
+#define PIECE_BITS          5
 
 #define MAX_STEPPER_TYPES  16
 #define MAX_LEAPER_TYPES   16
-#define MAX_HOPPER_TYPES   16
-#define MAX_SLIDER_TYPES   16
+#define MAX_HOPPER_TYPES   32
+#define MAX_SLIDER_TYPES   32
 
-typedef uint16_t piece_bit_t;
+typedef uint32_t piece_bit_t;
 
 /* Bitfield colours */
 typedef enum side_t { NONE=-1, WHITE, BLACK, NUM_SIDES } side_t;

This has a more efficient re-use of the movement tables for leapers and steppers (so all duplicated pieces use the same tables, instead of copies).

[myfish]

Link to SVN is broken. Only getting incomplete tar.gz

Also, does this revision include the patches further back in the thread ?

<EDIT> You answered as I was typing regards the first issue.

[myfish]

SjaakII wouldn't be able to play this (it can only handle 16 piece types), but the following patch against SVN 358 should allow you to extend this to 32 piece types, which should be enough for Wa Shogi if you want to try making a variants.txt configuration for it (you still need to assign a single character to each piece though, but since half of them are actually promoted pieces that should be enough).

OK, patch applied, sjaakii built.

So these are single variables that you've extended, not anything to do with the extra character extensions you guys were discussing earlier?

All I have to do is assign ANY single character to the piece string and configure game play as usual right?

I'll start with a Wa Shogi config to test things.

[myfish]

BTW

Here are my configs for Goro, Goro with knight and lance in hand and, Yari.

I keep tweaking the piece values but they do play without it being silly wrong.

Code: Select all

#################
# Goro Goro Shogi #
#################

Variant: GoroGoro Shogi (5x6)
Board: 5x6
FEN: "sgkgs/5/1ppp1/1PPP1/5/SGKGS"
XBoard pieces: "P....S...G.+....+Kp....s...g.+....+k"
XBoard parent: "shogi"
Zone: white_promotion = a5,b5,c5,d5,e5,a6,b6,c6,d6,e6
Zone: black_promotion = a2,b2,c2,d2,e2,a1,b1,c1,d1,e1

# Define the pieces

Piece: Silver general
Move: aleap (0,1)|(1,1)|(1,-1)|(-1,-1)|(-1,1)
Symbol: "S", "S,s"
Promotion: white_promotion, black_promotion, "+"
Value: 375

Piece: Gold general
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Symbol: "G", "G,g"
Value: 450

Piece: Pawn
Move: step N
Symbol: "P", "P,p"
Promotion: white_promotion, black_promotion, "+"
Flags: drop_no_mate, drop_one_file
Value: 80

Piece: Promoted Silver
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Symbol: "+S", "+S,+s"
Value: 490

Piece: Promoted Pawn
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Symbol: "+P", "+P,+p"
Value: 530

Piece: King
Move: leap (0,1)|(1,1)
Symbol: "K", "K,k"
Flags: royal

Rule: keep capture, allow drops
Rule: repeat4 = draw
Rule: perpetual4 = loss

Code: Select all

##################################
# Goro Goro Shogi Knight & Lance Drop #
##################################

Variant: GoroGoroNL Shogi (5x6)
Board: 5x6
FEN: "sgkgs/5/1ppp1/1PPP1/5/SGKGS[NLnl]"
XBoard pieces: "PN..LS...G.++..++Kpn..ls...g.++..++k"
XBoard parent: "shogi"
Zone: white_promotion = a5,b5,c5,d5,e5,a6,b6,c6,d6,e6
Zone: black_promotion = a2,b2,c2,d2,e2,a1,b1,c1,d1,e1

# Define the pieces

Piece: Silver general
Move: aleap (0,1)|(1,1)|(1,-1)|(-1,-1)|(-1,1)
Symbol: "S", "S,s"
Promotion: white_promotion, black_promotion, "+"
Value: 375

Piece: Gold general
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Symbol: "G", "G,g"
Value: 450

Piece: Pawn
Move: step N
Symbol: "P", "P,p"
Promotion: white_promotion, black_promotion, "+"
Flags: drop_no_mate, drop_one_file
Value: 80

Piece: Knight
Move: aleap (1,2)|(-1,2)
Symbol: "N", "N,n"
Promotion: white_promotion, black_promotion, "+"
Value: 250

Piece: Lance
Move: step 5N
Symbol: "L", "L,l"
Promotion: white_promotion, black_promotion, "+"
Value: 250

Piece: Promoted Silver
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Symbol: "+S", "+S,+s"
Value: 490

Piece: Promoted Pawn
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Symbol: "+P", "+P,+p"
Value: 530

Piece: Promoted Knight
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Symbol: "+N", "+N,+n"
Value: 500

Piece: Promoted Lance
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Symbol: "+L", "+L,+l"
Value: 480

Piece: King
Move: leap (0,1)|(1,1)
Symbol: "K", "K,k"
Flags: royal

Rule: keep capture, allow drops
Rule: repeat4 = draw
Rule: perpetual4 = loss

Code: Select all

#############
# YariShogi #
#############
Variant: YariShogi (7x9)
Board: 7x9
FEN: "rnnkbbr/7/ppppppp/7/7/7/PPPPPPP/7/RBBKNNR"
XBoard pieces: "PNBR.......++++Kpnbr.......++++k"
XBoard parent: "shogi"
Zone: white_promotion = a9,b9,c9,d9,e9,f9,g9,a8,b8,c8,d8,e8,f8,g8,a7,b7,c7,d7,e7,f7,g7
Zone: black_promotion = a3,b3,c3,d3,e3,f3,g3,a2,b2,c2,d2,e2,f2,g2,a1,b1,c1,d1,e1,f1,g1

# Define the pieces
Piece: YariKnight
Move: aleap (1,2)|(-1,2)
Move: step 9N
Symbol: "N", "N,n"
Promotion: white_promotion, black_promotion, "+"
Value: 300

Piece: YariBishop
Move: aleap (1,1)|(-1,1)
Move: step 9N
Symbol: "B", "B,b"
Promotion: white_promotion, black_promotion, "+"
Value: 400

Piece: YariRook
Move: slide (H)
Move: step 9N
Symbol: "R", "R,r"
Promotion: white_promotion, black_promotion, "+"
Value: 550

Piece: Pawn
Move: step N
Symbol: "P", "P,p"
Promotion: white_promotion, black_promotion, "+"
Flags: drop_no_mate, drop_one_file
Value: 80

Piece: YariSilver
Move: aleap (0,1)|(1,1)|(-1,1)
Move: step 9S
Symbol: "+P", "+P,+p"
Value: 375

Piece: YariGoldKnight
Move: aleap (0,1)|(1,1)|(-1,1)|(0,1)|(0,-1)
Move: step 9S
Symbol: "+N", "+N,+n"
Value: 425

Piece: YariGoldBishop
Move: aleap (0,1)|(1,1)|(-1,1)|(0,1)|(0,-1)
Move: step 9S
Symbol: "+B", "+B,+b"
Value: 425

Piece: Rook
Move: slide (H,V)
Symbol: "+R", "+R,+r"
Value: 650

Piece: General
Move: leap (0,1)|(1,1)
Symbol: "K", "K,k"
Flags: royal

Rule: keep capture, allow drops
Rule: repeat4 = draw
Rule: perpetual4 = loss

[Evert]

So these are single variables that you've extended, not anything to do with the extra character extensions you guys were discussing earlier?

Correct.
All I've done is extended the number of possible piece types to 32, and I made it a bit smarter about not duplicating piece tables unnecessarily (which will translate to a small performance enhancement for Shogi-like games).
I also fixed a couple of bugs, but that's not as relevant.

All I have to do is assign ANY single character to the piece string and configure game play as usual right?

Yes.

I'll start with a Wa Shogi config to test things.

Let me know how it goes!

[Evert]

BTW

Here are my configs for Goro, Goro with knight and lance in hand and, Yari.

I keep tweaking the piece values but they do play without it being silly wrong.

For fun, these are SjaakII's heuristic values for the different pieces:

Code: Select all

#[GoroGoroNL Shogi (5x6)] 0w>pieceinfo
 0 Silver general S (S, s)
   Value             [103 103]
 1 Gold general G (G, g)
   Value             [111 111]
 2 Pawn P (P, p)
   Value             [16 20]
 3 Knight N (N, n)
   Value             [52 52]
 4 Lance L (L, l)
   Value             [43 43]
 5 Promoted Silver +S (+S, +s)
   Value             [113 113]
 6 Promoted Pawn +P (+P, +p)
   Value             [138 138]
 7 Promoted Knight +N (+N, +n)
   Value             [128 128]
 8 Promoted Lance +L (+L, +l)
   Value             [131 131]
 9 King K (K, k)
   Value             [0 0]

and

Code: Select all

#[YariShogi (7x9)] 0w>pieceinfo
 0 YariKnight N (N, n)
   Value             [114 114]
 1 YariBishop B (B, b)
   Value             [160 160]
 2 YariRook R (R, r)
   Value             [162 162]
 3 Pawn P (P, p)
   Value             [16 21]
 4 YariSilver +P (+P, +p)
   Value             [139 139]
 5 YariGoldKnight +N (+N, +n)
   Value             [144 144]
 6 YariGoldBishop +B (+B, +b)
   Value             [146 146]
 7 Rook +R (+R, +r)
   Value             [174 174]
 8 General K (K, k)
   Value             [0 0]

[hgm]

I was trying to find out yesterday how I would configure Wa Shogi and whether there is enough pieces. There are only 17 types not including promotions so I guess we are good to go. A working Tenjiku would be great as there is English documentation to play it. But I never have.

XBoard could do draw without drops, and HaChu could be programmed to play that. (Although HaChu is not configurable like Sjaak, it is reasonably easy to add variants to it, and then recompile). But I understood Wa without drops is not very popular.

The problem of Wa with drops is that the number of droppable piece types is larger than the board height. So there is no way to display the holdings in XBoard. In addition, Shokidoki could never be programmed to play it, because of its internal board representation, which could not be stretched to a size of 11x11 without exceeding 255 as maximum square number. (Currently the board is 18x12.) Also the number of piece types is limited to 7 promotable plus 8 promoted/non-promotable. None of that is easy to change.

As for Tenjiku: The WinBoard Alien Edition already supports Tenjiku, but part of that is implemented in the front-end, (because the list indicating how pieces move is tightly coupled to the generation of the piece glyphs), and thus will not work in XBoard. For the XBoard standard edition the problem is not only the number of piece types (which is now barely enough to handle Chu), but also the side effects of the Fire-Demon move. HaChu already implements most of Tenjiku Shogi; only the area moves are missing.

[Edit] I guess a work-around for the holdings problem would be to define the hight of the board based on the holdings size, and then make part of the real board inaccessible by defining it as dark squares. E.g. when you need 13 piece types in the holdings, and the board is 11x11, you could define an 11x13 board, and in the FEN of the initial position mark all squares on the 1st and 13th rank as *.

[myfish]

The problem of Wa with drops is that the number of droppable piece types is larger than the board height. So there is no way to display the holdings in XBoard.

Wow, I never considered this.

Can't the holdings create a '2 wide' area ?

So on an 11x11 board we get 22 potential piece types?

[hgm]

See my edit of the previous message. 2-wide holdings would require massive changes in the way XBoard works, which is not worth it just for Wa. I know no other games that have this problem.

The work-around has the downside that it affects notation, unless you would black out only the highest ranks (12th and 13th in the example). Which is a bit ugly for symmetry reasons. I guess it could be of general use to introduce a new option -rankOffset, which could be used to force the first non-blacked-out rank to be denoted as 1. That would also be nice for Omega Chess and the like, where the white Wizard squares would then become rank 0. Not obvious how you could do the same thing for files, though, as there is no natural letter before 'a'. But for the holdings kludge this is not an issue.

22 base types and 22 promoted types is fine if you use Chu as parent variant.