Comments by HGMuller


| Zillions always shows the current value of a piece if you right- | click on it. And apparently the positional value is included in this, as a Knight clicked on g1 gives another score than when you cick it on f3? Does it also report a different value for the Knight on g1 if you delete all Pawns from both sides (turning the position from closed into open)? Does the value of a Bishop clicked on f1 depend on if you delete the second Bishop? | It is easy to change the value by tweaking. Anyway, strategic piece | values are problematic. The bishop pair, in closed positions, holds | no advantage. It remains to be seen if this is due to a decrease of the B-pair bonus, or simply a consequence of the drop of the Bishop base value in closed positions cancelling the B-pair bonus. A lone Bishop is also inferior to a lone Knight in closed position. Kaufman found that in GM play a Bishop is worth 1/8 Pawn more than a Knight with 4 or fewer Pawns per side while with 6 or more Pawns the Knight is 'slightly' stronger. Assuming that the later would mean ~1/16 (I doubt he could see differences smaller than that), it means the Bishop can lose 19 cP in a closed position, so 38 cP for two of them. This is hardly less than the B-pair bonus. | A knight is often more valuable than a bishop in closed positions. | A knight is regularly more valuable than a bishop in king + light | piece endgames when all pawns are on the same wing. I doubt Zillions | takes all this into consideration. This is Rybka stuff. Well, end-games is a different matter. I agree tht to get accurate empirical end-game values, you should actually use an engine that pays attention to such details when generating the games. This is why I have now started to design a variant-capable engine much stronger than Fairy-Max (which is about the most minimalistic engine in existence). I think most engines about 500 Elo below Rybka already pay attention to things like this. But I would indeed be surprised if Zilions did. It should not be too difficult to have a satisfactory general rule for this, upping the Pawn-structure evaluation for spread Pawns if the opponent only has short-range pieces. I doubt that Zillions has much Pawn-structure evaluation in the first place. As I am mainly interested in piece values in the context of normal Chess, with normal Pawns, I would like to do these determinations with an engine that understands orthodox Pawns well (scoring at least passers, (with bonuses for defended, or connected passers), backward and isolated pawns. | Together with Axiom, Zillions is quite powerful, although not very | strong. Axiom is a universal game engine that works in conjunction | with the Zillions of Games (ZoG) product. Specifically, Axiom consists | of a ZoG plug-in DLL and a set of scripts written in the Axiom | language. Similar to the way in which the ZoG 'zrf' language is based | on the Lisp language, the Axiom language is based on the Forth | language. Unlike ZoG, Axiom supports the ability for game developers | to specify the AI and therefore it has certain capacities that | Zillions lacks. Any sufficiently powerful language an be used to program an engine, and I prefer to use plain C. Apparently the protocol used to interface between the ZoG and its engines is an open standard. The problem is that people have developed engines for this protocol, and adapters to connect WinBoard engines to this protocol. But there are no alternative GUIs for this protocol, or adapters that allow you to connect a ZoG engine to a standard GUI. While (as far as I understood) it is actually the ZoG GUI that is most wanting, as it is not able to play two different engines against each other.

OK, Fergus, I sent you the piececlopedia article again, so you should have my e-mail address now. Please send me some BIG multicolored piece bitmaps, and the biggest Alfaerie available, then I will make a quick attempt of brewing something with it. I am skeptical that 50x50 will be big enough. Normally people that use WinBoard to play make its main window screen-filling, which even on the narrow screen of my laptop gives 72x72 squares. When I want to display two Capablanca games side by side on the monitor of my desktop, I use 49x49. I would consider that annoyingly small if I had to play myself. So it seems that on the average, WinBoard will have to blow up the graphics you can deliver by a pretty large factor, and we should hope that the result will not be too ugly.

Yeah, sure. And if you write Piececlopedia articles in Swedish, you can run them through Babelfish to translate them to English, and out come all the great plays of Shakespear... :-)))

Fergus, I experimented a bit with a colored bitmap that I snatched from the GC pages. The bitmap was only 35x40, though, so I put it in a square of 45x45, and I have to magnify it for any WinBoard board size larger than 'mediocre'. The bitmap itself was nicely anti-aliased, with clean edges (no doubt because you made sure the transparancy left no rags on the outside). The graphics routine I use (StretchBlt) seems to do the (de)magnification by sampling. For small demagnification factors this means it now and then skips a scan line, making ugly dents in the piece outlines where these make a small angle with the vertical or horizontal axis. If the original bitmap would have been larger, this effect should becom much smaller, as it always skips lines at these large demagnifications, and the difference between skipping 2 or 3 lines is a lot less obvious than between skipping 0 or 1. At the large sizes, it duplicates lines, leadng to a 'blocky' appearence: te individual pixels are blown up to squares. This effect would also disappear if we start from larger images. It would be conveient if these larger images are already filtered so that the upper 1/2 or 2/3 of the spatial frequency components would be suppressed. This would make the larger sizes a bit 'smeared' in apperance, but not blocky. The demagnified pieces will then automatically be anti-aliased. Perhaps 100 x 100 would be a good size to start from. If you want to look at the efect at different board sizes, I put a test version at http://home.hccnet.nl/h.g.muller/color.zip . Note only one piece is displayed, as I only built in one colored bitmap.

Geo-thermal is when they drill for steam near volcano's, not?

M.Winther: | Muller, why don't you make use of the immensely strong and cunning | Gambit Fruit, written in C, convert it to Forth using c2forth? Because it does not play any variants, for one. Strong Chess engines (including my own stronger engine, Joker) normally achieve their superior performance by exploiting all kind of knowledge on special properties of the FIDE army (like maximum number of different pieces, the fact that all leapers except King are automaticaly Knights, and that you have only one King, that pins can only occur on ortogonals and diagonals, and that in such a case you can always move along the pin line). And of course a large part of their strength derives from a lot of strategic knowledge on the orthodox pieces, (e.g well-tuned Piece-Square Tables) which would be totally lacking on any fairy pieces you would introduce (even if this was technically possible). This would stongly bias any strength comparison in favor of the orthodox pieces, while removing the knowledge (if you cold locate it, and remove it without doing any unintended fatal damage in a program that you don't know because it is not your own) is very likely to destroy the brilliance of the program and reduce it to a mediocre level that you could have achieved with a fraction of the effort had you written your own engine from scratch. I don't understand where this Forth mania comes from. So you can convert Fruit to Forth, and are left with an approximately 3 times slower Fruit that is about 120 Elo weaker than the original one. Now what? The fact that it is written in the same language as the Axiom engine does not mean it can do anything what the Axiom engine does. The message is not in the lanuage, it is in what you say.

I have made a 5x blow up of the original gif file with MS Paint,
and indicated with some red arrows what I dislike.

| Muller, no, it's not written in the same language as Axiom. Axiom | is not an engine. It is a language, close to Forth, which is used | for writing engines for Zillions. From the way I understand the Axiom description, this is not correct. Axiom is a general-purpose game-tree-search engine that uses the interface and protocol specifications of ZoG, and can thus be used as a plug-in for the ZoG GUI. Axiom can be customized for a specific game through a powerful scripting language ressembling Forth. But the script in no way describes an independent engine capable of playing the game being described. It merely serves to inform the Axiom engine (a binary executable in DLL form) of the peculiarities of this game (the rules for making moves and the goal, with perhaps some strategic clues like piece values). Just like ZoG contains an intrinsic AI that can be configured through ZRF files with a lisp-like language, and Fairy-Max can be configured through game descriptions that are lists of step-vectors for the participating pieces in the fmax.ini file. The Axiom language is only powerful because it includes primitives that activate the power of the engine in the DLL. | Moreover, advanced chess engines foremostly draw their strength | from advanced algoritm techniques, and certainly not only well-tuned | piece-values. Sure, you got to have both. Buth the algorithmic techniques are well known, and comparativey easy to program. Using all search tecniques that are publicly known, together with simple but not too rudimentary evaluation, brings you at about 2400 Elo. (On the CCRL scale, where Rybka ~3000 and Fairy-Max ~ 2000). The remaining strengt must come from selective pruning of moves that seem poor, or superior strategic insight that cannot realistically be replaced by extra search depth, and both requires expert knowledge of the game being played. | Anyway, I only tried to give you some interesting ideas. Axiom is a | clever thing. Ideas are always welcome, but this one simply 'doesn't fly'. Axiom is clever, in particular because of its generality. That doesn't mean, however, that it would automatically any game you give it a script for very well. Its author stated that Axiom was mainly meant for connection games like Go, and that for simple Chess-like games the ZoG intrinsic AI might actually play stronger. But in both cases it will depend strongly how wel the script that defines the game is written. And I can easily imagine that you run into a barrier there much earlier in the ZRF language tan in the Axiom language. But that in itself does not imply that it would be easier to write a strong Axiom script. It seems that the Axiom engine nowadays also has an accompanying free GUI, btw, so it can be used indepedently of ZoG. Greg Schmidt (the Axiom author) pointed out to me, however, that ZoG does not have as good an engine-GUI separation as I thought. It can use plug-in engines, but for almost none of the games there exist ZRF files for it actually does so. These games are all handled by the AI that is intrinsic and inseparable from the GUI. So it is not possible to play 99%+ of all ZoG games in any other way than through the ZoG GUI. Which is then only capable of playing them against a Human (or Human-operated computer) opponent. That makes ZoG quite useless as an entity to communicate with. It simply has nothing to say...

A general game engine like Axiom or ZoG will never be as strong as a good engine dedicated to a single game, or an engine tuned to a much smaller homogeneous group of games. You always lose some performance in generalizing. Fairy-Max is slower than micro-Max in normal Chess, because it has to test all kind of conditions on the move descriptors (such as 'is this piece a hopper?', 'can it wrap around the board?', 'is it multi-path?') which in normal Chess is a total waste of time, as the conditions never occur there. So I don't think you have to look in the direction of Axiom for strong Chess programs. Systems like Axiom are designed for ease of implementing something completely new at a low but acceptable level very quickly. Strong programs for Chess variants are easier to derive from existing strong Chess programs, such as I did with Joker80, which is the Capablanca Chess version of my normal Chess engine Joker. Such engines can already play under ZoG, as they use WinBoard protocol, and a ZoG plug-in adapter for WinBoard does already exist. (I am not sure if it handles the variants, but this iwould be a problem of the adapter, which should be fixed there.) The problem is that it is a bit pointless to play them under ZoG, as you could do nothing that you could not already do their under WinBoard. On the contrary: under WinBoard such engines can lay each other, under ZoG they cannot. The new Axiom GUI would be better in that respect, but I haven't seen it, so I don't know how it would match up graphically.




I don't see why this could not be played against a computer. Of course a computer will have zero handicap from this, but neither will an experienced Chess player. It would be more confusing and distracting if the pieces were randomy colored. An next step could be to make all pieces look the same. You could play it with a draughts set. In the Xiangqi vesion of this, you could simply flip the pieces! :-) To play without referee, you could then let the player that grabs the piece first show the bottom, to prove that it is his.


I actually like that proposal a lot! In more lightweight games we coud have A=Alfil and C=Cannon.


I dropped the idea of cylinder symmetry, allowing the piece to consist of a head machined
separately from the base (like most Staunton Knights). The following design seems suited
for manufacturing in a reasonably small number of steps, the main step of the process being the
creation of two cyclindrical surfaces which will contain the eyes, ears and outside tusks.
The model I made has a round backside, but currently I am leaning more to making that flat.
Please tell me what you think of it!

Chess evolved from Shatranj, because Shatranj was BORING to the extreme. Many pices were useless, or almost nearly so. So there was a great incentive to replace them. Today we face an entirely different problem: Chess is a magnificent game, but it has been played so often that most of its possibilities have been exhausted, and can now be mastered by rote learning. As the problem is different, it is not obvious at all that the solution can be the same, i.e. replace some pieces by other pieces. It is true that replacing, say, Bishops by Cannons, or Knights by Ferz+Dabbaba pieces would make all opening theory useless, but today we have computers. And these computers can play the millions of GM-level games that led to the current level of opening theory within a year. There are only a few hundred Human GMs, but one Chess program of the level of the World Champion can easily run on 100,000 PCs... So I guess what we need is more complexity, not different pieces per se. Chess960 is an attempt to drive up the complexity 960 fold with the same material, but it is ugly, ugly, ugly... The beautiful symmetry and meticulous tuning of the opening array, where each piece starts on a square that is not awkward, and traffic jams in the opening can be easily avoided, is completely destroyed in most Chess960 setups. A game where Knights start in the corner, or Bishop on b1/g1 is just no fun. One way to get more complexity, is to start with more pieces. I am not sure gating in pieces like Seirawan does is a good way: IMO the board gets to crowded. Wider boards would be more natural. But this does pose the problem of equipmet, as in some of the less fortunate parts of the World boards larger than 8x8 are not easy to come by. An alternative is the Superchess approach: this is played on a normal 8x8 board, with the normal number of pieces to avoid crowding. But the pieces you play with are not the same in every game, as you start the game by selecting pieces from a bigger set. Although Superchess does not mention this as a requirement, you could refine the rules such that the prelude of selecting the pieces creates an esthetically pleasing quasi-symmetric array, and fobid certain classes of pieces on certain squares (something that Superchess already does) to avoid awkward bottlenecks in development. The complexity then would come from the large number of pieces you could select from. The way I envision it, would be to have a list of Queen replacements, a list of Bishop replacements, etc. These lists would be chosen in such a way that developing the pieces does not cause awkward problems.

Rich: | By the way, the issue I see with Superchess is that it s a | proprietary product, that doesn't get enough exposure, and I | personally find the pieces far too confusng. Nice idea, but it | is set up where it won't spread and get needed exposure. I am not sure we are talking bout the same form of Superchess, then. AFAIK for the version I was referring to, only the name is protected as trademark, which apparently is is pretty poor protection, considering the number of variants listed here that have the same name. :-))) Of course it is to people like us to give it the exposure it needs. Superchess is not a commercial endeavor, and I would be very surprised if the person behind it would mind to get more exposure. But I was not mentioning Superchess because I think te exact rules described in the booklet make it the ultimate variant. I only mentioned it because of the aspect which seems to address the opening-book problem: picking pieces from a larger list. I think this is a vey useful general mechanism, offering the possibility to have the players do this in a controlled way, which protects the quality of the initial position. It has some desirable properties that alternatives like gating or dropping re missing. There is no danger of overcrowding, the players don't have to worry about the very specific tactical possibilities that piece drops introduce in the game, and the complexity (and duration) of any single game is not different from what tey are used to.

OK, Joe, thanks for the feedback. It it indeed a bit bulky (but what else can you expect from an Elephant...?) Flattening the backside, to make the ears thin, and thus indeed more like ears, has the disadvantage that the backside looks more like a traffic sign than a Chess piece. Perhaps it would give a better effect if the ears were made thin by cutting away two other vertical cylinders behind them, just as is already done to create the face, so that the top look would be something like a square with 4 quarter disks, centered at the 4 corners, cut out of it. (The disks on the front side having a slightly larger radius than those on the back, so that the 'neck' is thicker than the trunk.) The ears would still cause it to have a very massive and prominent frontal view, though. This could be reduced by making it smaller size, but OTOH, it would look a bit silly to have a small Elephant next to a big Horse. In some variants, the Elephant is only a very minor piece. (Shatranj, where it apears as the Alfil, and even worse, Xiangqi, where it cannot even jump or cross the river.) In other variants it is used for F+A, which has approximately Knight value. In Superchess it is a quite strong piece (a Mastodon that can capture to pieces at once). Of course in Mastodon Chess, one would be likely to use this physical piece to represent the Mastodon. In these latter variants, the impressive appearence of the piece is quite justified. In fact it is not really true that the size of a piece is related to its power in play: a normal Chess set is designed based on esthetics. The Rookis smaller than Knight or Bishop, while there is no doubt that it is the stronger piece.

The problem is more:
1. They are plastic, thus ugly
2. They are totally out of style with normal Staunton pieces
3. The set from which they come is even more ugly (way too small Queen).
The challenge is to design something that blends well with a wooden Staunton set. This is made
extra difficult by the fact that Elephants require a non-cylindric design, so that only the
Staunton Knight can serve as a guide to define the style.

All games are 'scenarios in a larger framework'. This is why they are called 'variants'. The are all Chess, that is the framework. I don't think orthodox Chess has an excessive draw rate. 25-30% draws between equal players is quite reasonable. That the draw rate between GMs is much larger is again a result of the opening knowledge they have, which enable them to steer the game at a very early stage towards a dull position, in which not much can happen anymore, (to them), after wild, but totally pre-analyzed play. They could not do that without their opening book, as one of them would likely lose foot in the wild stage that now brings them to a known safe haven.

as €1,49 at http://www.lobbes.nl/products/detail/1910126#

Rich: | But, if you wanted to run a publicized tournament and use their | pieces for other than what they intended, you may risk them suing you. Were did you get this information? It doesn't say that anywhere in the add I referred to, which offers these pieces for sale. So if I bought them from that source, the only legal recourse they would have is sue the company that sold them. Not me! The company sells them without restrictions, so I can do anything I want with what I buy there. That is the legal reality of the situation, and if anyone told you different, they have been telling you fairy-tales. Not that I would even want these pieces...

Ritch: | Chess drawing as high as it does at the highest level is a problem. Yes, it is, but IMO the excess draw rate is due to the large body of opening theory available, and not intrinsic to the design. Remove the opening knowledge (something which is desirable for other reasons anyway), and the problem disappears. | In regards to the 'variant' phrase, this would be fine for | standardized terminology, if it doesn't decide to make Xiangqi fit | into this. Into the larger framework I describe, a 'variant' would | have consistent terminology and piece names, as other games that are | considered 'variants'. Standard naming of pieces would be nice, but even the orthodox pieces often have multiple names, and of course different names in different langages. In Dutch, for instance, a Bishop can be called 'Loper' (runner) or 'Raadsheer' (advisor), a Rook 'Toren' (tower) or 'Kasteel' (castle), a Queen 'Dame' (lady) or 'Koningin' (queen). So multiple naming is unlikely to go away completely, ever. Even if we would make recommendations for the most common pieces here, they would still only be English names, and certainly not being used in other languages. So I think this is not a realistic requirement to make. I admit that Xiangqi is a bit of a 'flyer' amongst the Chess variants, with its zonal board, lack of promotions, and hopper piece. So although it is definitely a Chess variant in the broader sense, it does not seem crazy to make a sub-division of the evolutionary tree of Chess into a Western and Asian 'kingdoms'. (I would classify Shogi as belonging to the Western kingdom, though.) Witin each ingdom, a major subdivision would occur between variants with and without piece drops But. although piece drop have a major impact on the 'feel' of the game, they have little evolutionary relevance, as vaiants seem to acquire this trait quite easily and independently in very late stage of their evolution (e.g. Crazyhouse).

I have run some tests on Keen and Quing, in the context of the normal FIDE opening array. I always forget which is which, so I like to refer to the piece that moves like a pedestrian, but kills at a distance (mKcQ) a 'Trapper', and the one that moves far, and then tramples around in destruction (mQcK) a 'Tourist'. (The Knight-like counterparts of those could then be 'Hunter' for mNcQ and 'Pegasus' for mQcN.) One Trapper lightly beats the Bishop pair, perhaps by as much as a quarter Pawn. With the Kaufman values B=325 and B-pair bonus = 50, this would give Traper = 725. Two Tourists beat R+N by at least half a Pawn (perhaps 75cP). With the Kaufman values R=500 and N=325, this would make Tourist = 450. So it is indeed clear that the extra captures make the piece much stronger than having these same moves as non-captures. This should be compared with the Commoner (opening) value, which is slightly below that of a Knight (so ~300). Note there are clear non-linear effects: adding the distant non-capture moves to the Commoner ups the value from 300 to 450 (+150cP), while adding the same moves to the Trapper ups the value from 725 to 950-975 (the Kaufman Q value), i.e. +225 to +250.
25 comments displayed
Permalink to the exact comments currently displayed.