Comments by HGMuller

Fergus:
| Game Courier already has better graphics than the GUIs I've
| seen, such as Winboard ...

This cannot be true by definition, as WinBoard allows the user to define
any piece anyway he wnts it to look...

| and ChessV, and it supports many more games than these do. 

WinBoard groups most of these other variants under the name 'fairy'.
It is not very useful to includes variants in the list for which there are
no engines and no servers.

| Would this enhance Game Courier's abilities in any way?

How do you play two engines against each other using a browser? How do you
play an engine against the server? Can GC handle blitz and bullet games?

To Rich:

It seems that what you want and what Fergus wants is fundamentaly
incompatible. It seems you are striving for a situation like exists on
normal Internet Chess Servers, and to which I am used as well: At any time
a large number of games is gong on, and a large variety of opponents is
available for new games. GMs and beginners, commecial engines, dumbed-down
open-source engines, and people trying to test the engines they are
building. People play mostly quick games, like 5'+3' or 12'+5'.
Engines are usualy on line 24/7 and many people play them (providing a
good test bed for their developers.)

This variety makes the typical ICS a thriving community, where everyone
can find what they need (provided they play normal Chess or a very limited
range of 'variants' such as Crazyhouse, Losers/Suicide, normal Chess with
non-standard initial positions, Chess960, and occasionally Shatranj. This
is a situation I would also like to see for variants. Offering one variant
only, without providing engines, is not enough to make a viable ICS, as the
unspeakable server shows.

I would like to see something similar to an ICS like FICS or ICC, but then
for variants. My interest would be to find Human opponents for the engines
I develop. I don't have Zillions, and I do not have the slightest
interest in buying it, as it plays like cr*p. I am not interested in
playing games myself against other Humans, I just want to see how my
engines do, against Humans or other good engines, in fast games, (in order
to play enough of them). So that I can spot their mistakes and correct
them.

Game Courier has a much more limited scope. It is basically a medium for
playing correspondence Chess between Humans-only, and Fergus would like to
keep it this way. What would be interesting to me lies far beyond its
scope.

So I think we should forget about Game Courier, (and Zillions!), and try
to find a medium that is more suitable for interactivegame playing than
the http channel of a web browser. ICS protocol is unfortunately not
variant friendly, nd ven fails to handle Chess960 properly. Something like
the unspeakable server would be a nice start, (using a Java client that
auto-downloads through the browser Java plugin), except that this is also
proprietry software, and is buggy on the server side.

Well, different media need different protocols. Calling an engine that is a
DLL is different from opening a pipe to another proces, which is again
different from opening a TCP link to an internet server. In general, other
information has to be exchanged to get the thing to work. When connecting
to a server you will have to announce who you are (i.e. log in). When a
GUI starts up an engine, there is no need for that. That is just one
example.

Standard protocols do exist. WinBoard protocol is one of those, usable for
GUI-engine communication. ICS protocol is another standard, used for
client-server communication over the internet. Many hundreds of engines
use WinBoard protocol. Dozens of Internet Chess servers use ICS protocol.
Why not simply stick to the existing standards? If te answer is: 'but the
sites I want to connect to don't want to use those standards', then why
do you think they would use our standard if we develop a new one?

Btw, I heard that FICS might be convinced to provide the unspeakable
variant on their site. I hope this wil open ICS potocol to variants in
general.

Fergus:
| How does that work? Does WinBoard allow the use of graphic images for 
| pieces? Game Courier allows the use of GIF images for pieces. Does it 
| allow any customization of the board's appearance? Game Courier allows
| GIF, PNG, and JPG images for boards, and it can draw multiple kinds of 
| boards. If WinBoard can use images for boards and pieces, then I would 
| be happy to contribute some.

WinBoard can use arbitrary bitmap files for the square coloring (through
options /liteBackTextureFile=... and /darkBackTextureFile=... on the
command-line or in the winbord.ini file. For some examples, see:
http://usuarios.lycos.es/alexwbtm/Test/ or
http://www.open-aurec.com/wbforum/viewtopic.php?t=49439 (bottom).

The pieces cn be user-defined through the option /renderPiecesWithFont=...
and /fontPieceToCharTable='...', which can be used to select any
pictorial true-type font for piece rendering, and define the mapping of
pieces to font symbols. A good example of this would be the Superchess
font obtainable from http://www.superchess.nl.

Fergus:
| Software standards for integrating Game Courier with a GUI or
| a game engine would have to arise from an actual project of trying to
| integrate Game Courier with some actual piece of software, and I would
| have to work with the programmer on this,  ...

Well, so WinBoard is the GUI, and I am your man! :-)

| Furthermore, my greater interest right now is in helping a GUI gain 
| moreof the capability of Game Courier, especially in graphics and in 
| the capacity to handle more types of variants. 

It has always been my aim to develop WinBoard in this direction, and I
think I already made a very good start at this.

| Zillions of Games has  a great interface, but it is too weak for many
| games, especially Shogi-like games. 

Agreed. The level of Zillions is probaby perfect for beginners, but it is
no match for dedicated engines. And especially piece drops are a weak spot
in its search algorithm.

| My special interest is in having a strong Shogi program that can use 
| the graphics I have designed for Shogi and which can handle some of my |
Shogi variants, such as Kamikaze Mortal Shogi and the Hex Shogi games.

Building a Sogi engine is one of the things on my to-do list. I decided to
re-write my Chess engine Joker (and have actualy started working on that)
in such a way that it is more friendly to implementation of variants, e.g.
using a 10x10 board as basis (so that 8x8, 10x8, 9x9 and 9x10 can be
implemented as a subset, by filling a larger part of the internal 16x16
board with edge guards, besides the 3-wide guard band). Adding piece drops
to that would be a very good basis for a strong Shogi engine.

M. Winther:
| Whoever said that isn't aware that there are tweaked Zillions chess
| variants programs that play a fine game of chess. 

Well, as I have no Zillions, I cannot test that. What (computer) rating do
you think Zillions would have in (properly tweaked) normal Chess? Could it
beat Fairy-Max / micro-Max? I doubt that very much, and Fairy-max is only a
very mediocre engine, (what can you expect from a mere hundred lines of
code?), about 500 Elo weaker than a good engine, and about 1000 Elo below
the World top (=Rybka).

From the unspeakable World Championship, where Fairy-Max beat Zillions, I
got the impression that Zillions is tactically weak. It just doesn't
search deep enough.

Sure it would look better. But that is a moot point, as one cannot machine
S-shapes with a lathe, as they violate cylinder symmetry. The objective is to do the best one can within the imposed limitations of the production process, and so far I couldn't come up with anything better than this one.

'Zillions, on a modern computer, plays chess at, perhaps, Elo
2150-2200.'

That might be true against Humans in 5-min games, but I have strong doubts
that that has any bearing on how strong it is. Based on Zillions
performance in Gothic Chess I estimate its rating more round 1800 Elo.
When I had micro-Max play on the ICC server against Humans it also quickly
converged on a rating of 2260, but it seems that almost any computer
program, no matter how poorly it plays, does that. I once saw a report of
Tord Romstad, about his attempts to reduce the playing strength of his
engine Glaurung. At some point he had crippled it so much that it would
litterally score 0% against TSCP (an extremely weak engine, which
micro-Max would totally crush), and blundered away a piece or rook nearly
every other move. It still kept beating 2100-rated players on ICC!

Anyway, Zillions might suit your needs, it definitely does not suit mine.
I need computer opponents to test my engines, so it is not really relevant
how many variants Zillions plays, just that it plays the variants for which
I have built engines. And if even the most basic engine I build totally
crushes it, I can learn nothing from playing it against Zillions. My
reason for playing engines against each other is to test which one of
different versions is better. If all versions score close to 100%, I can
learn nothing from it. And if I would want to play a variant against a computer myself, I might as well configure Fairy-Max to play that variant.

Of course even if Zillions were strong enough, it would still be useless
to me, as it cannot play automatically against other engines at all...

M. Winther:
| Muller, which are the chess variants you are testing? Zillions is World
| Champion in several hundred chess variants. 

That does not really prove much about its strength if it was the only
contender... I have been testing games like Shatranj, Knightmate,
Capablanca, Superchess (as in Superchess & Monarch), Falcon Chess, Great
Shatranj. And I am testing many 'unofficial' variants consisting of one
or two unorthodox pieces embedded in a conventional setup, e.g. replacing
Knights with Cannons, Modern Elephants or Dababbas, or (pairs of)
Grasshoppers, Ferzes, Wazirs, Xiangqi Horses; Rooks with Nightriders,
Queens with Centaurs or Amazons. Usually in setups with different Armies,
on 8x8 or 10x8 boards.

| Rybka is only World Champion in one. Without Zillions, how would it be 
| possible to test and try Hexagonal Chinese Chess, recently invented by 
| L. Smith? It would take a century. 

Well, the game does not seem listed here, so it is hard for me to comment
on it. If I would be interested in it, I might configure Fairy-Max to play
it. If very exotic pieces that defy Fairy-Max' piece-definition format
would participate, and I was interested enough, I would hard-code the
particular piece in Fairy-Max, or add general support for the property
that made it impossible before. (I did this for the Falcon, for example.)
In general I am not so much interested in entire variants, as in
individual Chess pieces occurring in those variants.

| And it beats me easily in Xiang Hex when I try it. Zillions is
| very appropriate for 99% of all chessplayers. It's beyond me how 
| a person interested in boardgames can refrain from buying Zillions 
| at $20.

This is because I am not interested in playing against engines, but in
building them, and I already have developed engines that can do the things
I am interested in (piece value measurements) which I consider highly
superior to Zillions (w.r.t. playing strength). If I had teleport ability,
why would I buy a Rolls Royce?

To Fergus:

It seems that you have an application / need for the extra colors because
you are not just displaying the piece symbols, but are actualy trying to
create a realistic image of the game as it would be played with physical
pieces.

Personally I don't think this is very desirable; I would prefer to play
Shogi without th pentagonal outlines and Xiangqi without the circles.

The Linux version of Winboard, xboard, does have the possibility to have
user-defined graphics called 'pixmaps', and I am not sure there is any
limitation on the number of colors that can be used in them. (They have
the undesirable property, however, that they represent square and piece
together.)

What software do you use to scale the GIF files? I always get excessively
ugly reslults when I do that. Even when my browser scales a gif image of a
Chess poition, separation lines between board squares are randomly
disappearing, etc.

M. Winther:
| I bet you wouldn't be able to program certain of my most advanced 
| pieces in Fairy-Max.

As Fairy-Max is written in C, and C is a recurive language, and recursive
languages are equivalent to a Turing machine, and a Turing machine can
calculate anything that is calculable, you would lose that bet with
mathematical certainty!

Moves of Catapult pieces, for instance, are akin to castling moves, and it
would be fairly easy to built something into Fairy-Max that would allow
this type of 'castling'. If I had the motivtion to do it. The Catapult
pieces do not particularly appeal to me, as they violate what I consider
to be one of the defining characteristics of a Chess variant: that it
moves only one piece per turn.

Note that  am not in any way denying that what I do, could be done by Zillions. But the differences I want to measure do not result in 6-0 scores. A Pawn advantage in Chess results only in 18% advantage, and even less in Capablanca-type variants. I want to measure piece values to a precicion of at least a quarter Pawn, resulting in advantages of ~3%. To get the statistical noise below that I need 50-1000 games, so I cannot afford to let the engines spend half an hour on a game. They must play 1-min games, and play them at a sufficient high quality for the results to be meaningful. So I want the best engine I can get, and I doubt Zillions would qualify as such. But you can convince me by showing that Zillions can beat Fairy-Max in, say, Knightmate.

Fergus:
| We each have our preferences. In general, your program will appeal to 
| a broader base when it can accommodate more preferences than just your
| own. For example, Game Courier uses some graphics I don't like and 
| supports many games I have never become interested in, but it is more 
| popular than it would otherwise be because I didn't limit it to my own
| preferences.

Before I invest in that, I would want to be sure that there are actually
people that want to use this feature at all. The user base of WinBoard
seems to be far more interested in the games they use it for, and how well
and reliably it supports the rules of those, than in having multi-colored
pieces. They don't use WinBoard for generating artwork to hang on their
walls...

The way you scale the entire board, if I could find  similar function in
the Windows graphics library, does sound like it might be very expensive.
Doesn't anti-aliasing involve Fourier transforming the image back and
forth? You would have to do that every time the board changes (i.e. every
move). Anything CPU-intensive is a no-no in a GUI that run on the same
machine as the engines. There are already people that are complaining
WinBoard currently uses more CPU time than they can afford fo their
purpose (wich is playing sub-second games).

Although there i a general truth in the things you say, I still think it
is good to keep well-defined priorities. There is still so much that can
be done. I think the risk that there are people that say: 'I am not going
to play Shogi, as the pieces have only a single color' is very small. They
are either interested to play Shogi, and would do no matter what to achieve
that, or they don't.

In fact there is a lot that can be done with just outline and inner color.
The Xiangqi pieces you show are in fact just that. The outline and the
(solid) piece symbol are one color, the inner regions another. The
WinBoard system could easily handle that. You could have designed the
Shogi pieces similarly.

To Rich:
Indeed, I think it is good to have diversity. There is no point whatsoever
in giving WinBoard and GC all the same capabilities, as one of them would
then be superfluous. The requirements for a GUI are entirely different
from the requirements for a game-play server. GC wil never make a useful
GUI for engine-engine play, and WinBoard will never make as versatile a
client to a server that can prepare html pages as a browser. In the areas
where the tasks they can perform overlap, it only enriches the world that
they are different. People can then choose what they like best.

I would very much like to have an easier way of scaling the size of the
display, but if it is computationally too expensive, the efficiency
requirement hould take clear priority.

I am a firm believer in the 'maximum flexibility, minimum usefulness'
principle. Therefore I refrain from trying to make WinBoard do everything.
If there are tasks that have too little in common with what there is now,
it would be of no benefit to cram those into WinBoard. I would, for
instance, never teach it the rules of Checkers, Othello or Go to make it
possible to use it as a GUI for those games. There is too little synergy
to make that pay off.

| There's me for one. 

The keyword in this phrase is 'one'... :-)

| I don't use Winboard, because it has poor graphics, and I don't think
| it yet supports any games I'm interested in well-enough that I can't 
| play with another program that has better graphics. 

Well, if that is your opinion then I am happy you do not use it. If there
are other programs with graphics that you like better, then I could only
win you over by providing similar graphics. That would be a total waste of
time, as I would be making something that apparently exists already.

I have absolutely nothing to gain by competing with other programs in
their own niches through mimicry. WinBoard is not a commercial program,
and I therefore don't care how small it user base is. What I care about is that it provides opportunities to its users that they cannot find anywhere else.

| For now, I prefer to use ChessV, which plays many games well and 
| includes some of my own graphics with it. 

I have no experience with ChessV, as it does not support automated play
against other engines. In the Unspeakable World Championhip 2007 it ended
well below Fairy-Max, but Gregory told me that this was an obsolete
version used without his permission, not representative of the strength of
current versions.

| I have a good Shogi program that came in a commercial suite that also 
| includes Chess and Xiangqi, though I prefer other programs for those 
| games, such as Chessmaster and Coffee Chinese Chess.

Well, nice for you. Just play the Kamikze Mortal Shogi with that one, then. But it is of no use to me, as the Shogi program is no doubt not capable of automated play against, say, TJshogi or GNUshogi, or to the Shogi engine I will be developing.

| Yes, probably because the poor graphics turn off those who care about 
| such things. My point is that you can expand your user base by allowing
| easier customization options for graphics.

Well, I have never heard any complaint about this before, and current
users are eager enough to complain about many other aspects they don't
like, so it doesn't seem to be true in general that perceived
shortcomings immediately deter them from using it.

| I'm no expert on how anti-aliasing is done. I just use a function 
| supplied by the GD library. But I can tell you it is done very fast, 

Very fast is a relative notion. Something that needs to be done 60
times in a 1-min game doe not have to be visibly slow before it starts to
soak up a sizable fraction (say 5%) of the CPU time. Correspondance Chess has other standards.

| and I expect Winboard would have to do only between moves, not when it
| needs all the CPU power for calculating a move. 

The problem is that in engine-engine games you always need all CPU power
for calculating move, as when it i not engine A's turn to move, engine B
should start thinking. Plus that these programs often want to think in the
opponent's time as well.

| Anyway, resizing boards is not as important as just allowing bitmap 
| images to be used for boards and pieces. It makes a difference only 
| for large variants that don't easily fit on the screen. 

Well, it doe to me, and many like me: a I have a dual-core PC I play two
games simultaneously, and would like to fit both WinBoard displays next to
each other, together with the control windows of the corresponding two
tournament managers. And soon I will have a quad (or, when I get my way,
even an octal core or dual quad)...

| Game Courier's boards and pieces are at a scale that normally fits 
| the screen for most games and usually don't need to be resized.

Yes, if you only want to have one game on screen, and not four.

| I'll still play Shogi, but if Winboard plays Shogi only with shoddy 
| graphics, I will play Shogi with another program. The issue here is 
| not whether people are sufficiently interested in Shogi but whether 
| your program would be a more appealing option than some other program.

Well, to some it is. To me it is. That is enough for me.

| Shogi is a good reason for including multi-color pieces. In Shogi, 
| the promoted sides of pieces are normally red rather than black. 
| This makes it easier to tell promoted pieces from unpromoted ones, 
| and it is crucial when you are using a westernized set in which the 
| promoted pieces use the same images as the unpromoted pieces.

Well, there is no red in the Japanese set I have, that's for sure. Using
the same image for the promoted and unpromoted piece is just bad design of
the piece set. By the same token you could represent all Chess pieces by
Pawns, and then complain how essential it is to have their heas rendered
in all different colors to distinguish a Knight from a Queen...
The built-in winBoard representation does not suffer from this. Promoted
pieces are clearly distinct from the unpromoted versions there. They look
like the piece they promote to, while stil betraying their origin.

M. Winther
| Muller, to get piece values at ~3% exactitude you would need to 
| presuppose that piece values are static properties. But they are 
| really changeable with regard to tactical and strategical context. 

Not necessarily. I always measure piece values in a well-defined context,
e.g. opening values, end-game values. Piece values are by definition
strategic quantities, I avoid starting in tactical positions, and for an
accurate measurement I average over many non-tactical initial positions
with similar peiece makeup. This usually gives quite consistent results,
when you keep the number of pieces and the total value of present material
approximately constant. (i.e. the difference of the performance of two
diffent pieces is hardly dependend on the details of the makeup of the
opponent or its allies.)

That piece values change as the board empties, because. e.g., Rooks get
more freedom of movement and Cannons can find fewer platforms, is
something that can be measured separately. If the piece values found for
the various qualitatively different situations differ, you can try to add
material-interaction terms in the evaluation. (The best known example of
such a term in normal chess is one proportional to the product of the
number of Bishops and number of Pawns, making the effective B-N difference
dependent on the number of Pawns.)

| This means that you would probably have to foresee the future in, 
| say, ten moves in order to get a ~3% exactitude. 

I am not sure what you mean by 'forsee the future'. By playing out the
game until checkmate or legal draw, I effectively make a Monte-Carlo
sampilng of all plausible futures. But it is important that the sample is
generated under conditions of reasonabe tactical accuracy, or you would
not be sampling a representative set of realistic positions, which then
would distort the results.

| One obvious example is XiangQi. Chinese Chess masters are hard pressed
| to reveal the relative values of pieces. Those pieces which are 
| completely lousy, like the elephant and the mandarin, are sometimes
| very valuable while they provide protection for the general, function 
| as screens for the cannon, or can block enemy pieces. So, in a certain
| context they become very valuable. 

I have not built an engine to play Xiangqi yet (I am in the preliminary
design stage now of an engine that could play Shogi, Chess and Xiangi with
arbitrary Chess men on boards upto 10x10.) So I have not done any
measurements for tuning. Quite possibly the material-interaction terms in
Xiangqi are much larger than in Chess, due to the peculiar capture mode of
the Cannon and the restricted access pieces have to the board. It seems to
me that the effects you describe can be described reaconably well by
cross-product terms of number of Cannons and number of other pieces. This
transcends pure piece values, but can be measured just as easily.

| Ten moves later, the elephant or mandarin is useless. Probably, in 
| chinese chess, only a human is capable of evaluating a piece.

Such a fast change is usually tactical, and then has little to do with
strategic piece values. Unles the strategic situation completely changed
in those ten moves, e.g. because all heavy material got traded, or all
hoppers got traded. But in that case such differences can easily be
expressed by terms that are proportional to the amount of heavy material /
number of hoppers.

I doubt if Humans could do this job better than computers. This is why I
would like to build a Xiangqi engine, so that I could do similar tests on
piece values as I am doing now for Chess.

| If it could. Otherwise, it might be enough to call an engine on 
| another server. But I do want to look into the possibility of 
| running an engine on the server. I know this website runs on a 
| FreeBSD server. Would Fairy-Max run on a FreeBSD server?

Fairy-Max is available in source (this is included in the WinBoard_F
download), and the source can be compiled both for Windows and Linux. You
have to define the macro LINUX to make it use a Unix-like call for reading
the clock. I suppose this would also work on FreeBSD.

| Right now, I need to know what the most basic steps would be. I need 
| to know where to put the engine, what protocol to use to communicate 
| with it, and how I could do this through PHP.

WinBoard engines are normal console programs that communicate in plain
text. So it is fairly easy to run them on another machine, using a remote
shell there to which GC connects.

| No, that doesn't follow. You could win me over by providing better 
| graphics. Besides, all I want is the ability for me to provide you 
| with better graphics. I am not asking you to provide any additional 
| graphics. I have the graphics. I want the ability to use them with 
| Winboard.

It would be very nice to add other graphics to WinBoard, but I want to
avoid unlimited bloating, so I think te requirements should stay within
reason. In particular I want to avoid providing a zillion different
mechanisms for doing exactly the same thing, especially if each of them
would only work in different situations. (E.g. colors working only with
bitmaps, and scaling working only with fonts.)

| No, it would not be a waste of time at all. The only programs with 
| the kind of graphics capability I want are Zillions of Games and a 
| couple Chinese Chess programs with customizable graphics. Everything 
| else comes up short, even ChessV, because it doesn't use images for 
| boards.

Well, non of the graphics code in WinBoard is of my own hand, but I have
taken a peek at it. At the WinBoard part at least. This code is platform
dependent, and the Linux version, xboard, has completely different code
for this. WinBoard has built-in bitmaps (2-color for black pieces, 3-color
for white, one of the colors being 'transparent') for each size, and
scalable tri-color font-based pieces which are customizable. Xboard has
2-color built-in 'bitmaps' (transparent + color; no outline), and
4-color 'pixmaps' (including the square in the 4th color, so that a
duplicate set is needed), both non-scalable, but both customizable.

I consider it a very undesirable that WinBoard and xboard are so different
here, but phasing out customizability options in which sers might have
heavily invested is something that is 'not done'. My prevference would
be to switch to a single, platform-independent graphics package and format
for internal use (built-ins), and convert the obsolete customization input
formats to this internal format. In WinBoard things basically lready work
that way, MicroSoft monochrome bitmaps being the internal format (using 2
layers to create the white pieces), and font-based rendering converting
the given font to such bitmaps.

In the WinBoard graphcs code, there seems noting that resticts it to
monochrome bitmaps; the number of colors is part of the bitmap definition
in MicroSoft format. I am not sure if the MicroSoft graphics library
supports transparent color. Currently this is emlated by anding and orring
bitmaps together, wchich in black and white has a well-defined effect, but
with multiple bits per pixel might not always do what you want. If a
solution can be found for this, there would be nothing against using
many-color bitmaps as internal format.

Such bitmaps would then also be suitable as customization input (like
xboard already does for monochrome bitmaps), PROVIDED an acceptable way
for scaling the user input to the current disply size can be found.

Of course people having very special desires that are to uncommon to make
it likely to be supported can always customize their own private version
of WinBoard by changing the built-in bitmaps, and recompiling it. WinBoard
is open source.

| That is not an option. It is a commercial program that only plays Shogi
| and does not include any graphics for the Kamikaze piece.

That is what I mean. If WinBoard were the only program that remotely
supports what you want to do, you would use it despite the perceived minor
shortcomings.

| Since Winboard already supports fonts, you do have the option of 
| using fonts instead of rescaled bitmaps. Adding a new feature to 
| your program does not force you to use it. And if you added the 
| feature, you could avoid the need to rescale altogether by creating 
| some smaller bitmap pieces.

Like I explained above, I don't want to add too many features aimed at
doing the same task.

| That depends on the set. I would not use the same images for a 
| Japanese set, and my Symbolic set uses different images, but the 
| set I based on the Chess Motif font uses standard Chess piece images, 
| and it makes sense for this set to just change the color for the 
| promoted pieces.

I don't understand this. Promoted pieces in Shogi move completely
different from their unpromoted counterpart, so the symbol for a
corresponding standard Chess piece would be completely different. I would
think it made sense to represent pieces that move the same by the same
symbol.

| I would not know if this is true, because Winboard would not let 
| me make a single move when I tried to use it for Shogi.

This is strange. Was that because you could not select Shogi at all,
because you had no engine? If you click 'view or edit games' in the
startup dialog, you should not need any engne, and it sould accept all
moves. Be sure to use board size middling or bulky if you want to see al
the pieces, though, as for Shogi, not all sizes have built-in bitmaps.

M. Winther:
| Another method is when I pit the new piece(s) against a different 
| army of known pieces. If the result is equal after a number of games, 
| then I regard the piece as equally valuable as its counterpart in the 
| other army. So this is a practical testing method of determining piece 
| values, which I let Zillions do automatically.

This is essentially the same way I do it. (Except that I do not use
Zillions, but Fairy-Max or Joker80.) Try to set up nearly equivalent piece
combinations, by making as few substitutions as possible in the array
defining the context. If a side wins modestly, I give it additional Pawns
odds to swing the balance, and gauge the remaining difference compared to
the Pawn value.

| I have found that when a piece is valued, perhaps, 2.5, or 3.5, 
| then it tends to converge around the piece value 3, e.g. the same 
| as a bishop or knight. The point is, namely, that the new piece can 
| threaten exchange, or vice versa. And the threatened party cannot 
| withdraw for strategical or positional reasons. 

This effect is certainly present to a certain extent, but not as large as
you make it out to be here. A difference of 5 centiPawn often occurs, and
is very rea. Thi is well confirmed in normal Chess, where the value of the
first Bishop to be captured is 50cP (the B-pair bonus) above that of any
Knight. This can be based on GM games, and it is also what I find in
computer self-play. On 10x8 a 50cP difference exists between B and N even
in absense of other Bishops, and not telling the computer they were equal
caused a neary 100 Eo drop in playing strength in results against other,
unrelated engines.

But it is true that for much smaller differences, like 20cP or less, a
computer often performs better if you make it underestimate the
difference.

| Hence the piece values converge around the nodes of 3 and 5. Remember 
| that also the formally higher valued piece can often threaten exchange 
| to achieve a positional or tactical goal. 

The tendency to control willingness to sacrifice should not be tuned by
the piece values, but by the value of the positional goal.

| So, they are worth the same due to practical factors, while they are
| *practically* interchangeable*. Obviously, in an equal army variant 
| both players can exchange the new piece, and the remaining position 
| is still equal. Hence, the new piece is equally valuable as a light 
| piece. 

I am not sure what you want to say with this.

| To really introduce a different valued piece, then it must by 
| pinpointed at 4, I suppose. 

I think the B-N base-value difference in Capablanca variants clearly shows
that this is not true. Ignoring a difference of 50cP really causes a large
drop in strength.

| I don't know if this phenomenon can be mathematically represented. 
| It depends on the piece congestion, i.e. size of board, and whether 
| the nearly equal valued pieces are long-shooting, i.e. whether they 
| can easily be used to make an exchange.

All these effects are included in the empirical value determination by
playing games. Fortunately self-play results are not very sensitive to
wrong piece values (unlike playing wrong piece values against correct
ones, wich makes you take a big hit). So if the values change in later
game phases, so that values tuned to the starting position no longer
strictly apply, the results are not significantly corrupted by this. So
although it would be better to use an engine with  very advanced
evalution, taking material-interaction terms into account next to the
piece values, this is not strictly needed for measuring the piece values.
(But it would be essential for measring the more subtle interaction
effects; if these are not recognized at all, they are simply randomly
squadered, and an initial unrecognized advantages might not survive long
enogh to affect the result. E.g if you play paired Bishops against
unpaired Bishops (i.e. on the same color) with in engine that does not
score the B-pair, the first Bishop is very likely to be traded so early,
that the B-pair advantage does not get the time to affect the score.

Does Zillions recognize and award the Bishop pair? Or do the values you
give represent an average of the paired nd unpaired Bishop?

Exchanging the first B (so you break the pair) against N+P turned out to be an equal trade in Capablanca. It seems strange that the difference goes down. Based on GM games in normal Chess, the B-N difference increases as more Pawns disappear (as one would expect towards the end-game), exact equality occurring if each side has 5 Pawns.

Fergus:
| If you do add support for bitmap images to Winboard, you might want to 
| do it with OpenGL, which is supported by both Windows and Linux. A 
| good image file format to use is PNG. It's a cross-platform compressed
| lossless format, similar to GIF but capable of supporting true color 
| images. Like GIF, it can support transparent images. Zillions of Games
| supports Windows bitmap images, and instead of having a transparent 
| color, Zillions treats green (#00FF00) as transparent. Game Courier 
| follows the same convention for when it can't make use of an image's 
| transparency, such as when it is using it as a brush for drawing a 
| single board image.

OpenGL would suit me, as my purpose is to unify WinBoard and xboard as
much as possible. But it will be a major ndertaking, as I know little 
about the grapics code of WinBoard, and nothing about that of xboard, 
and  nothing about graphics in gneral at all. All programs I have ever 
written were text-mode console appications. So I hope that someone else 
that is better prepared than I am can do this job.

On the short term, I found out that there is a routine stretchBlt in 
the graphics package winBoard uses, which allows scaling of the entire 
board after it is put together. The results do not look too bad if the 
original bitmaps did not have thick enough outlines. Unfortunately it 
seems to totally mess up the color pallette of the background texture, 
apparently reducing the number of colors. I have no idea why it would 
do that... I am not sure scaling the entire board is a solution. With 
'animate moves' on it causes all kind of problems, and it would have 
to be done ~20 times for each move.

Scaling individual bitmaps might also cause problems. An anti-aliased
scaling blurs the edge of the symbol, and mixes it with the background 
it had during scaling. This would make it difficut to cut it out and 
copy it over a varying background. A solution might be to scale the 
symbols on two different backgrounds, representative of a light and a
 dark square, as well as on a white background. A floodfill of 
everything within the white would then define the contours of the 
piece symbol with some spillover due to the anti-aliasing blurring
the piece. But the spillover does not hurt if the too-large mask is 
used to cut out a symbol on an approximately correct background. On 
evenly colored background you would not see it at all, and most 
textures contain an element of randomness that would not make it very 
obvious either if an 'halo' of 2 or 3 pixels around the piece would be 
overwritten by some background that came with the piece. So after the 
scaling the same procedure could be used as now for the font-based 
pieces: a mask would cut a black hole in the background, and a multi-
colored bitmap exactly fitting the hole would be ORed into it. It
would just be a matter of preparing the required bitmaps in duplicate 
through scaling the originals, which needs only be done when you 
change board size.

Could you provide me with some Windows bitmap files for pieces, on 
which I could try this out? I only want to demagnify, as magnifying 
is likely to produce ugly results, so I would need pretty large format, 
something like 129 x 129 (the largest square size WinBoard supports). 
It should be possible to scale them down to a square size lke 33x33, 
so make sure all lines are at least 4-5 pixels thick.

| While it would be nice for Winboard to support customized graphics, 
| I might be able to use Andreas Kaufmann's Winboard Adapter for 
| Zillions with the games you write Winboard engines for.

This should in theory be posible. I did not really extend WinBoard
protocol when adding the variants, except adding some new variant 
names, and allowing variant FENs in the setboard command. So if the 
adapter implements enough of WinBoard protocol it should work. It 
might refuse to pass moves in Shogi notation, though, which would be 
essential for communicating with GNU Shogi. I believe that TJshogi 
uses normal board coordinates, though. Of course the adapter might 
still choke on files>h or ranks>8...

| I have two installations of Winboard. One is Winboard_F, which 
| had Fairy-Max but no Shogi engine. The other is your demo package, 
| which includes a Shogi engine that shows the opponent's pieces as 
| reversed. When I tried to move pieces with it, it rejected every 
| move I tried. 

That demo pack was made more than a year go on another PC as I have 
now. Problem is that I can no longer run the GNU Shogi it contains, 
so I cannot test anything. What happens when you try to move? Does 
WinBoard ignore it when you try to grab a piece, oes it complain that 
it is not white's turn, does it reject the move as illegal, or does 
it pass the move to the engine and does the engine then rejects it as
illegal, so that WinBoard takes the move back? Come to think of it, 
did you try to play the white pieces or the black? In WinBoard 'white' 
is synonimous for 'sente', so it expects white to start.

Anyway, if the only purpose is to see the piece symbols, just start 
up the most-recent WinBoard without any engine, and select 'File -> 
New Variant... -> Shogi'. Then you should be able to move for the
STM.

M. Winther:
| Muller, I haven't bothered to figure out Zillions's piece evaluation
| method. Of course, in the initial position the knight is placed at the 
| rim and threatens only 3 squares. Closer to the centre it threatens 8 
| squares. I suppose this is why its value increases more than the
| bishop.

Ah, OK. You were speaking on the very short term, after development but
before material got traded. I consider that positional evaluation, not
part of the piece values. In the opening the positional evaluation is not
a strategic feature: all pieces are placed very poorly, but the opponent
does also have no means yet to prevent you from moving them to average
locations. A minimax search from the opning will thus be able to reach
leaves where the piece placement is more typical, and the score of such a
search does properly include the strategic part of the positional
evaluation, where the evaluation of the single position would not.

If you have not figured out Zillions evaluation, how did you obtain the
numbers you quote? Does Zillions print its total evaluation of the root
position, or can one specify a fixed search depth and print the score of
that? In that case you could simply delete a Knight from one side and a
Bishop from the other, and note the score imbalance this creates (in, say,
a 10-ply search), and then delete another Bishop on both sides and repeat
the experiment, to see if the the imbalance is affected. In case 1 you
would have BB-BN, which involves B-N difference plus B-pair bonus, while
in the second case it would be B vs N, only dependent on the B-N
difference.

| On 10x10 boards this is an even greater problem. The difference 
| between a bishop and a knight corresponds, perhaps, to a pawn. Of 
| course, there are important strategical aspects to this. One cannot 
| trade a bishop for a knight easily. 

Well, so you trade it for N+P. Pawns are abundant, and in the beginning
usually the sole defendants of Knights. So opportunities for trades like
that occur often enough. The situation is not worse as in Capablanca,
where you would effectively lose a full Pawn on trading your first Bishop
for a Knight. If the Bishop gets worth even more, trading B+P vs R (about
neutral in Capablanca, for the first Bishop) would be a natural channel.

Btw, I doubt that 10x10 would really affect the Bishop value so much. It
is mainly the increased width of the board, allowing the Bishop more
forward moves, that causes its value to increase.