Enter Your Reply

Zillions cannot be compared to anything else, because of its amazing
geneality. But that does not mean that any particular thing Zillions does
cannot be done better by other means.

Zillions is basically a programming language, and so it can do anything.
But C is also a programming language, and it can also do anything. Although
some pieces are too complicated to handle for Fairy-Max at the level of the
configuration (.ini) file, because I only provided for true Chess pieces
(i.e. moving from one square to another in a translation-invariant pattern,
capturing by replacement). Side effects are rare and too specific to
generalize them efficiently. So they cannot be implemented by enabling pre-cooked 
options from the .ini file.

But that does not mean I could not handle such pieces if I wanted to. It
only means that in such a case I would have to handle them at the C level.
Being the author of Fairy-Max, it is very easy for me to add the necessary
code to implement peculiar properties at the C level. I would have little
difficulty to use pieces like BodyGuard or Coordinator in a Fairy-Max
derivative, like I have no problem limiting Kings and Guards to the palace
in a Fairy-Max derivative (MaxQi) that plays Xiangqi. It is very
questionable if this would take more effort than describing the piece in
ZRF. 

How I would do that, would depend on the case at hand. having to think
about it would allow me to choose an efficient implementation. For the
BodyGuard I could for instance test all surrounding squares on the presence
of an enemy BodyGuard, and abort the ray scan if there is one. that would
probably still leave Fairy-Max faster (in searched positions per second)
than Zillions, which always has to test for who knows what strange
propertis of pieces. But really efficient implementation would add the
lines

position[piece] = toSquare;
position[piece] = fromSquare;
if(neighbor[toSquare - position[32 - color + BODYGUARD] + 140]) break;

in the code for MakeMove, UnMakeMove and the ray scan of the move
generator, respectively, plus an initialized table

char neighbor[280] = {
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,1,1,1,0,0,
0,0,0,0,0,0,0,0,0,0,0,1,0,1,0,0,
0,0,0,0,0,0,0,0,0,0,0,1,1,1
};

Well, big deal, 3 lines of code and a trivial table. I doubt if you have
to tell Zillions less than that to implement the stimying effect of a
BodyGuard.

I don't understand your negativism towards brute-force tree searching; I
am sure that this also is exacly how Zillions comes up with its moves.
Except that the need to be general slows it down, so that it searches less
deep. And that means it plays on the average weaker moves. Deep searching
has proven the way to winning Chess. Why you would prefer to have an entity
that plays like crap just to be able to say that it was not a 'bean
counter' escapes me.