New chess variant. Looking for players to play with.

lol, that is a very good point lol. Wow, didn't even give that a thought yet, thank you.

It's funny that great minds think alike. Coincidentally, in my version of your Variant, which you already know I'm developing (with your permission), I actually decided to use Queens in substitute of the Prince/Princess. The Titaness piece replaces the Original Queen in her original spot.

Thing is, I don't have to worry about what powers to assign the Prince and Princess, since I'm not actually using them. Two Queens do great justice in my version. ^-^

On another note, Ace, one thing you want to consider is that, it only takes 3 moves for the Seige Tower to capture your Prince and Princesses. Observe. You might to consider a modification for that. 

I made it take four. I found how to change castling so I can remove those damn 3 black squares. The rook must still be on the end. Yet I can make it work at any width now. Not just 10 wide. So I can finaly set it up the way I wanted a few weeks ago. More or less. I made the prince/ss the queen move rook/bishop capture. I have not tested the placements yet so not sure how well it will work.

I guess I'm not too sure what you mean until I see a new diagram.

What exactly are these "damn 3 black squares" that you're talking about, and what's their issue?

 The ones from the kings row you can't move to. To make it so I could castle without it messing up.

WinBoard is designed to interpret any sideway King move to a non-neighboring square as an attempt to castle, and it will then always castle with the piece in the corner, (or, actually, at the edge on the same rank), whatever that is. (Many Chess variants have no Rooks...) I remember this gave problems in Omega Chess, because of the definition of 'board edge': it was castling with a black square!

So I changed the definition such that being next to a dark square on the same rank qualifies as 'edge'. That worked for Omega Chess. Since then I encountered some other variants where it would not work, because there is a square beyond the Rook, and WinBoard would rather castle with the piece on that square than with the Rook. Perhaps I should always allow castling when a King looks straight to a Rook, no matter how far that Rook is from the corner.

A more robust way of entering castlings would of course be to drag yur King on top of the piece you want to castle with.

I figured out how I can move it, so it works for me. I don't mind the rooks on the end. I just wanted that row wider. Thank you. I agree that the mod you speak of, to add to winboard.  Would be a good addition.

So I spent the entire day plus several hours last night testing piece placement. After being able to open the castling row beyond 10.

I've been playing with the winboard p2p engine, and I have some questions.

Is there a way to specify multiple promotion zones, with different promotion options in each zone?

Is there a way to define a piece that moves first one way, and them another in the same move?

Well, p2p is just a communication adapter without any intelligence posing as an engine, and not a real engine. So it doesn't know any game rules. It makes use of the WinBoard feature that engines can redefine moves of pieces in 'engine-defined variants', by sending the contents of the custom.dat file to WinBoard, without having to know what it really means. This allows WinBoard to do some pre-filtering of the moves the user tries to enter (and generate better move notation). But the more subtle details of the game rules, such as promotion-zone size and piece choice were expected to be handled by an intelligent engine, in this design, which just refuses things (with an 'Illegal move' response) that you are not supposed to do (like promoting to Lion in Mighty-Lion Chess).

There is no way for an engine to re-configure any other rules than board size, initial position and piece moves (yet). Other than that it can select a 'parent variant' from which these rules are inherited.

I have been wondering if promotability should not be made indicatable in the piece commands, as an optional third item (next to 'piece' keyword, ID and move descriptor). But promotion rules can be quite complex. It might be optional (but that can be handled by including the piece itself amongst the choices), or conditionally optional (e.g. mandatory when you reach the last rank, as for Pawns in Shogi), in general location dependent (e.g. Q only on 8th, other choices already on 7th, or only to the piece type that started on the promotion square (Chaturanga)), or dependent on what you have captured so far (Grand Chess).

Now of course the move already assumes it is universally valid across the board, and the system does not allow location-dependent move rules (of which the confinement of certain piece types to a board area like in Xiangqi is a special case). Of course this could be added in a general way, by allowing any specification to actually be a list (say comma-separated) of area:item pairs, where 'area' could be a list of squares in braces, perhaps allowing ranges like a8-h8 for the 8th rank. That could then be used both for move and promotion choice. E.g. a Shogi Knight could have {a7-i7}:N+N,{a8-i8,i9-a9}:+N, indicating that deferral on the last two ranks is not allowed. Of course it might be convenient to have a default implied by the move, assuming that you should not be allowed to promote (or drop) so that you won't ever have any moves left.

In my web applet I adopted the convention that the promoChoice configuration parameter can prefix choices with * to indicate they must come from the holdings (collecting the pieces that were captured).

Shogi-style promotions, (i.e. only take-it-or-leave-it choice) both in the web applet and in WinBoard are effected by just adding a constant to the piece type. In the applet,which is tailored forone variant and the pieces can thus ordered as necessary, this isn;t a problem. But in WinBoard it is pretty inconvenient, because it does force pieces being grouped in (unpromoted, promoted) pairs. (E.g. a promoted Elephant always looks like a Hawk.) So it would be nice if each piece could explicitly specify its promoted form, rather than having some implied relation between the available pieces.

It requires a lot of thinking to design this right.

 I was going to ask something simular. So that answers that. I was thinking I needed a 'parent variant' to work with. That is the lastest thing I've been playing with in the custom data. So I wonder can I find an (think they are called GPU) engine with Chu-Shogi in it. Then add it to P2P in some way?
Which would have 28 icons for the pieces plus the multi king rule, as well as add promotion rules that might do strange things when applied to the custom.dat file, as a parent variant. Tho if I look at what promotes to what piece. Then use the corrisponding letter that represents that piece in my custom.dat. I should be able to use that to control it, to a degree. Not too sure there.

 Just I think unless that parent variant is added into P2P. A rondom engine with Chu-Shogi in it, would not have my queen castleing and jack promotions you added to the P2P for me, or the online P2P factor. Plus not sure some random engine would look for my custom.dat. By letting me sellect my game in variants.

So I'm thinking that parent variant of Chu-Shogi would need to be added to P2P. Just not having the best luck at figuring out how. I still can not find how to open most of this stuff, to edit and recompile it. Not that I really know what I'm doing. I just make a backup then play with things.

I still do not understand how Chu-Shogi overcame the 22 piece rule of xboard. Tho P2P does have 23. Also what's the difference between xboard and winboard? Are you the creator of xboard Muller? I see your name or initials all over the place when trying to look this stuff up. Sadly most is beyond my understanding.
I really like a lot of things about Chu-Shogi. Not a fan of how most the pieces move. Yet almost everything else rule wise I love. I really wise I could use this and all its pieces as a parent variant, in my custom.dat, on P2P.

http://www.gnu.org/software/xboard/whats_new/rules/Chu.html

LXIVC The link below, muller gave me some time ago. It will teach you most of the piece move rules you can create. Like the first move and so forth.

http://www.gnu.org/software/xboard/Betza.html

also how do I get this? It's a WB engine for Chu Shogi and other large Shogi variants made by you. I can not seem to find the download for it.

http://hgm.nubati.net/cgi-bin/gitweb.cgi?p=hachu.git;a=summary

Also how can I do this? Which file is it? Trying to look this up currently.

 "The standard distribution of WB works until 16x16. That is not a very hard limitation; by changing two numbers in the source code (it is open source!) and recompiling it you can enlarge that to anything you want. Of course you will run into limits as to what still will fit in your display."

The problem is number of piece images. The regular edition of WinBoard had until recently 'only' 2 x 22 pieces. (And then only in two of the 18 sizes.) Some years ago I made an experimental version of WinBoard called the Alien Edition. Its aim was also handling other games than Chess, in particular games with multiple captures such as Draughts, or several moving pieces per turn, such as Amazons.

Later, when I got interested in Chu Shogi and other large Shogi variants, it seemed logical to use that Alien Edition, as some pieces in these variants do multiple captures. These Shogi variants need huge numbers of pieces, though; Chu, which is the smallest, already has 39 distinguishable piece types. For some others it runs in the hundreds. So I extended the number of allowed piece types in the Alien Edition to 500.

Problem is that NONE of these new pieces had images for them. So I designed a 'mnemonic' piece representation, where for >95% of the Shogi pieces WinBoard would be able to generate the image itself, based on a table with moves. This works in two board sizes. For the other sizes it just prints the name of the pieces in Japanese in the squares.

Problem is that the Alien Edition is Windows-specific; everything was programmed with the Windows drawing method. So it did not work for XBoard on Linux. To make it possible for my Chu-Shogi engine to work on Linux, I needed to start from scratch. So I took the regular version of Win/XBoard, and doubled the number of allowed pieces there to 2 x 44 (which is enough for Chu Shogi). But I still had to do something for images. WinBoard and XBoard need different graphics.

So I made some 14 new images, often just slightly modified versions of existing piece images (like a Bishop without the cross on its mitre), as Chu has pieces that move the same, but just differ in whether they can promote or not. So the cross then means 'promotable'. Other new images were just existing pieces rotated 90 degrees (as most Chu pieces have asymmetric moves, and then often occur in such rotated pairs). So most of it was pretty easy, and the only hard part was to draw a Lion and a Leopard.

Of course I also had to equip the regular edition of Win/XBoard with double capture, but I managed to hack that in too. So XBoard could do Chu Shogi. I liked the Lion so much that I designed Chess variants Mighty-Lion and Elven Chess using it, which do not have very many other unusual pieces (or none at all). So they could be played easily with WinBoard as well, if I only had a bitmap of a Lion. So I torned the XBoard Lion image (which was an SVG file) into a black-and-white bitmap that WinBoard can use. So WinBoard now has 2 x 23 pieces, as the other 21 new pieces have no bitmap there at any board size.

Now WinBoard can use external bitmaps: if you put a lot of .bmp files in a folder, and define that folder as pieceImageDirectory, WinBoard will look for files with specific names (like q33b.bmp for a 33x33 pixel image of a black Queen), and use these to display the pieces. Problem is that these new pieces have not even names defined for them. This, however, would be relatively easy to remedy by allowing numeric names like x27_33b.bmp, which then would be used for piece nr 27, etc. Then the number of pieces could be extended indefinitely, and the burden of making images would fall on the user.

Of course there are other problems with large number of piece types as well. One is move notation: the Latin alphabet has only 26 letters. And many things on which WinBoard relies, such as encoding positions by FENs, would break if piece IDs are not a single letter. In Chu I could get away with that because the notation for promoted X in Shogi is +X, so only the unpromoted pieces need a letter.

In the development version of XBoard I am experimenting with allowing suffixes on letters to distinguish pieces. E.g. 'L' could stand for Lance, L' for Leopard and L! for Lion in the same game. Narrow symbols like ' and ! won't destroy readability too much, and already give you 3 x 26 possible combos, so that you don't have to start picking very silly ID's, like Z for 'Duck' because you have enough choice. So WinBoard 4.9 might support more piece types. (Except that I am not going to make many drawings, so most of them would have no built-in image. I did make a Wolf, Wheels and a Butterfly, however, for my web applet on Cashew Shogi: http://www.chessvariants.org/index/msdisplay.php?itemid=MScashewshogi . So those might end up in XBoard.)

So I do not fully understand the external bitmap thing. I understand what it is doing, just not the steps to do it. So I might have to wait for winboard 4.9. On winboard 4.9, would I just be using a different P2P, that looks at a custum.dat? That is set up slightly differently to account for the new features.

As for the drawings Do they need to be in SVG,  bitmap or both? I will happily draw, rip, or covert a whole ton of pics of anything you want. I will even make in 33x33 pixel imag. Plus what ever midcore & small are. I'll redo the lion for those to.

I have never used much but PNG for games. I think I can figure SVG & bitmap out easily enough. If you could give me a file of the lion to start with. It would help me find the best program I want to use. To draw and/or convert these with. A lot faster. Because I stiil can not find where to get them out of the game.

Will this work? If so I can make a ton of these. Not that I can even see what it is I made after converting it.

http://www.mediafire.com/download/e611d25dv3np92v/G_2_.svg

http://www.mediafire.com/download/10mj5fka29knmk5/New+folder.zip

here are some more pics in SVG 33x33. these are gray instead of Monochrome. Have options of;

For WinBoard you will need Windows bitmaps (.bmp files). In fact you will need 3 of those for each piece type. E.g. if you wanted to use an externally provided bitmap for Lion in boardSize middling (49x49 squares), you would have to supply the files

ln49s.bmp

ln49o.bmp

ln49w.bmp

These should contain, respectively, the 'solid' piece (used for black) on a white background, the 'outline' piece (used for white) on a white background, and the 'white' background (paradoxacally drawn in black against a white background) on top of which the other two will be drawn (to prevent the white pieces from being transparent).

So the way it works is that WinBoard first draws the w bitmap (which must be monochrome black&white) on the board to erase the board texture, and then on top of it draws either the o or the s piece (which can be full-color bitmaps).

I prepared a version of WinBoard 4.8 that also allows the user to provide bitmaps for the 21 pieces that come behind Lion (which is piece number 21) in the pieceToCharTable. E.g. to define an image for piece nr 22 you would have to provide the files

piece22_49o.bmp

(and corresponding s and w), put it in some folder, and then start WinBoard with 'Additional option' -pid FOLDERNAME (pid stands for pieceImageDirectory).

I will post it on my website soon.

To get an idea of what is required, you can go to my on-line source repository (  http://hgm.nubati.net/cgi-bin/gitweb.cgi ), select xboard.git, click on 'tree' for the latest (uppermost) commit (actually any commit would do, as this has not changed for ages). From the list of files you get to see select the 'winboard' directory. From the list of files in there, select the 'bitmaps' directory. This will show you a list of all o, s, and w bitmap files that are built into WinBoard. Click on the 'raw' link behind them to see the image they contain.

[Edit] I uploaded the adapted winboard.exe now, to http://hgm.nubati.net/winboard.zip .

I confirmed that it worked, by using an external bitmap (a black circle) for piece22. The easiest way to make the bitmaps is first draw the outline image in black, and save it as the 'o' file. Then to fill it with red using the paint bucket, change the color of all internal details to white, and then change the red to black, and save the result as the 's' file. Finally load the 'o' file again, fill everything with black, and save it monochrome as 'w' file.

Well that is a little more confusing & overwhelming...Than I thought it would be. Yet I am going to figure it out.  I found the bitmap page. and downloaded the new winboard horse exacuteable. I just need to play with this a bit to understand what you were saying about 'Additional option' -pid FOLDERNAME. That part lost me.

Oh, I see that in WinBoard 4.8 you can also set the piece-image directory from the menus, so their is no need to use -pid. Just go to the View -> Board Themes dialog, and provide a value for the 'Directory with piece bitmaps'. (You can use the browse button there.) The option is persistent, so once you set it WinBoard will keep using it until you unset it again.

Ok I look into what you just said. To see what you mean.

ok so doing the inverted black piece is hard. I can do white and full black all day. They look like crap on the black pieces tho. Going to try something else. I'm not getting this or something; "Then to fill it with red using the paint bucket, change the color of all internal details to white, and then change the red to black, and save the result as the 's' file." Will keep trying.