Check out Symmetric Chess, our featured variant for March, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments by rescharn

Later Reverse Order EarlierEarliest
[Subject Thread] [Add Response]
Reinhard Scharnagl wrote on Fri, Oct 22, 2010 11:24 AM UTC:
Well, still I am continuing developing 10x8 chess engines for my own,
because the number of supporters has nearly vanished. The SMIRF GUI now is
supporting seven languages. There are plans to write a UCI-2 related
protocol based 10x8 engine, but it is proceeding very slow, because of
missing donations for such a donation ware project. Thus, when there is no
public support, there will be no public new engine.

[Subject Thread] [Add Response]
Reinhard Scharnagl wrote on Fri, Oct 23, 2009 02:48 PM UTC:
SMIRF is no longer available. People enjoy playing clone programs.
Multivariant engines are out of focus. Maybe situation will be changing
after some years ...

Reinhard Scharnagl wrote on Sun, May 10, 2009 07:16 PM UTC:
SMIRF still is an 8x8 and 10x8 multivariant engine and GUI at amateur level. Experiencing some problems when being executed at Windows XP 64 Bit I recompiled an actual version of SMIRF and made it downloadable from http://www.chessbox.de/Compu/schachsmirf_e.html. Thus SMIRF still will have its conceptual weaknesses during mating operations. Nevertheless some 10x8 fans might welcome the current version made available. Please report on still existing weaknesses of the GUI or the download link. SMIRF itself will not be improved, instead there will be a rewritten private engine Octopus.

ArimaaA game information page
. Uses same equipment as Chess, but designed to be difficult for computers.[All Comments] [Add Comment or Rating]
Reinhard Scharnagl wrote on Sun, May 10, 2009 03:57 PM UTC:
Omar: thank you very much for your reaction here!

To 'Also please see the Arimaa Public License: http://arimaa.com/arimaa/license/ ': well, I am not a native English speaker, as a lot of chess and variants programmers would not be, too. Thus I do not understand every implication of the license's details. If those rules would be valid also e.g. for the country of Germany, where I am living in, it would be fine to have a German language translation at hands. This is, because I am not a lawyer, and I had experienced a lot of difficulties around an unspeakable 10x8 chess variant targeting a bunch of priorly very interested people.

To: 'For personal, educational and research use, Arimaa is freely available.': I occasionally used to publish my (still amateur level) combined 8x8 and 10x8 chess multi variant engine SMIRF and GUI at my homesite http://www.chessbox.de/Compu/schachsmirf_e.html, very rarely from time to time gathering by it some voluntary donations to support that programming work, which needs casually to be enhanced e.g. buying some updates of development tools. 

Within SMIRF I therefore had to disable that unspeakable 10x8 variant to prevent it from general use. Moreover nevertheless I always regarded myself to be only a small step away from jail. Such feelings are not of that kind, which might increase motivation and creativity to deepen an understanding especially of patented variants. It seems, that there would be no chance to legally publish any Arimaa® enabled program or GUI at a personal web site, so why should I start an Arimaa® development at all, when only earning of trouble seems to be certain already e.g. by giving away some program copies mainly for testing purposes?

Reinhard Scharnagl wrote on Sat, May 9, 2009 01:24 PM UTC:
To the Arimaa site I have posted repeatedly for to get information on details, but there is no reaction at all. One of my additional questions would be, why only linux programs will be accepted at tournaments. Using there also Windows or Mac OS would be more interesting to me. Moreover Arimaa is a patended game, and troubles seem to be already anticipated for really engaged programmers. A new drosophila for AI which Arimaa intends to be, should be free of such restrictions.

Relocation Chess. Swap a pair of your own pieces before you begin. With Fischer Random castling rules.[All Comments] [Add Comment or Rating]
Reinhard Scharnagl wrote on Fri, May 1, 2009 03:11 PM UTC:
to a): there seems to be no need for a special swap move. Instead move the King / Queen to the Bishop of opposite colour, which seems to be an impossible exchange, which should be skipped then. 

Initial exchange moves (of traditional sequence: White starts) could be integrated into traditional game notations by starting a game at a negative move count (here e.g. -2 half moves), supplied by an appropriate FEN. But I am not yet convinced that an intended relocation would be better than a randomized one.

Reinhard Scharnagl wrote on Fri, May 1, 2009 10:42 AM UTC:
a) Your sentence: 'Note that the players can choose to keep the standard position by simply swapping bishops.' seems to be obscure to me.

b) When after such relocations the arrays will end in one of 20 possible Chess960/FRC starting positions, it still will result in a position with small advantage for White. Thus having the last relocation choice would enable White to maximize that advantage or in contrast Black to minimize that advantage. Thus it seems more natural to start any relocating by White as with the following playing.

c) Supposing that there would be a minimax optimization of the relocation process along with the coming lot of games, there soon would be a well known 'optimal' relocation procedure (for both sides). Thus this finally would raise a preferred 'standard' starting position, in extreme it would end up in a traditional chess game itself.

d) To provide a bunch of really used different opening positions therefore it seems to be unavoidable to demand an execution of any kind of a randomizing procedure like in Chess960/FRC. So maybe there might be an alternative to make a hidden choice among possible exchange piece types?

[Subject Thread] [Add Response]
Reinhard Scharnagl wrote on Tue, Oct 7, 2008 08:07 PM UTC:
Harm, FullChess games have moves defined by TWO seperatedly to be clicked
squares. Those fields are encoded within the algebraic move encoding sent
by the engine before. In doubt, e.g. at promotings, the GUI is prompting
possible moves to be selected by the user. After any move the engine is
sending the current X-FEN position to be interpreted and displayed by the
SMIRF GUI. The GUI is absolutely unable to generate any Chess move by
itself or to modify the board position by its own means.

Go is defining its moves by exactly ONE to be clicked square. Thus Go
belongs to a different family of board games, for which a similar approach
would be possible.

Reinhard Scharnagl wrote on Tue, Oct 7, 2008 07:21 PM UTC:
But that, Harm, is just the way SMIRF works. It asks the engine for a list
of valid moves and from that filters only valid move inputs from the user.
And that has been the basic idea of the TMCI protocol. The intended utmost
goal was to have some engines playing and a certified referee engine
secure a correct play of a chosen variant. That would make a GUI able to
communicate a family of games even unknown to it without any need to be
changed or updated. Therefore the base of its communication: X-FEN has to
be maximally independent from any selectable variant. The subset of
variants it aimed to cover has been called: FullChess.

[Subject Thread] [Add Response]
Reinhard Scharnagl wrote on Sun, Oct 5, 2008 08:53 PM UTC:
It is not my intention to represent every variant position by X-FEN. I
would be happy to cover a lot of variants having gait combinations in
their pieces strongly related to traditional chess. Maybe you noticed
SMIRF naming itself a FullChess engine. SMIRF does it covering dual
combinations of N, B and R. Coming Octopus is intended to cover some
additional combinations, too. 

FEN stems from traditional Chess. Thus I am convinced that using X-FEN
makes sense the more the variants it supports would be related to chess.
My X-FEN approach therefore is not thought to be a base for Zillion
positions. 

As long as X-FEN belongs to that idea, the handling of variant names and
pieces names as a kind of comment will work best. Thus I will remain in
the neighbourhood of Chess.

Reinhard Scharnagl wrote on Sun, Oct 5, 2008 07:54 PM UTC:
Indeed, I am always trying to separate variant- and piece naming from FEN
representation. In SMIRF I made a first approach to that using X-FEN as
published. But including Janus or Optimized Chess produced a lot of
encoding problems, just by having different piece type letters. I learned,
that this was an unnecessary complication, which should be avoided. Think
on different piece names and abbreviating letters in different countries
for traditional chess. Those are part of the PRESENTATION of the game,
thus belonging to the GUI. Piece letters on the surface simply are a
comment to the underlying pieces, thus not being absolute. But a
calculating engine has no need to communicate multi language wise, it
simply has to use well introduced unique international (english) letters
PNBRQK. That is, why I have not yet included SMIRF's current
representation of Janus or Optimized Chess into the X-FEN concept, because
that has been the wrong approach. X-FEN has to be extended to include a lot
of variants in a generic and universal way. Variant names are only
comments, even though I know, that Winboard handles it as a definition.
But have a look at Chess, Chess960 and castlingless random chess. Having
X-FEN will cover all of them doubtlessly, thus avoiding any need to
explain more than X-FEN to fully describe a position. Chess960 as a
variant title then therefore merely is a comment. A lot of variants
include each other, e.g. think of CRC. Sometimes it is not to be decided
to which variant a position belongs, and there is in fact no need to.
Moreover this would not make any sense, as in Shredder FEN that is
creating confusion encoding identical positions by different FEN strings.
All Chess positions e.g. could be regarded as Chess960 positions.

Reinhard Scharnagl wrote on Sun, Oct 5, 2008 05:02 PM UTC:
Well, Harm, I intend to seperate the variant depending renaming of piece
types from FEN, because this should be a feature of the GUI and maybe
become customizable at least. It might be accompanied by a commenting PGN
token like: [Variant='Janus Chess, J:=A']. That would give to it an
importance like a kind of comment. But the X-FEN as a communication
vehicle for engines should use merely unified and thus constant piece
letters. This should also be true for move notations (in PGN / Algebraic),
where protocols e.g. like UCI demand for one-char-letter piece symbols.

Of course this approach is not at all able to cover all piece types. But
that goal would need a much bigger approach than what I intend this
moment. (Octopus would not be able to cover every piece type, too.) And a
later extension e.g. done as proposed in your posting would not at all be
made impossible by my idea. But it would be a simple and compatible ad hoc
extension into the right direction.

Promoting possibilities should not differ through different incarnations
of the same piece type. Thus having pawns with different promotion
abilities does not make sense to me. Thus it has to be related to a given
board situation in total.

Reinhard Scharnagl wrote on Sun, Oct 5, 2008 02:01 PM UTC:
Thank you, Harm, for your explanations. Concerning X-FEN I would prefer to
have piece letters being unique and compatible to nearly established
Archbishop and Chancellor. I do not want to change used letters with the
variants playing them.

Smirf unfortunately cannot be extended to handle all those four super
pieces because of its piece codes' bit encoding their properies. But in
Octopus there will be a more flexible bit encoding, so that a lot more of
gait combinations might be possible in Octopus, e.g.: Q+N, K+N, K+B, K+R.

When I read Superchess documents correctly, a promotion to Q+N is not
permitted. The union of all usable pieces seems to be constant, thus it
might be unnecessary to have the unused pieces listed seperately inside of
an X-FEN. Nevertheless it is not obvious, that it would be a notation from
Superchess. To have a unique X-FEN method I intend to do following:
instead of a []-list of captured pieces (which I am not yet able to
support, but maybe later ...) there could be an optional separated tag '
:' followed directly by forbidden pieces' symbols (if any). By default
at 8x8 NBRQ and at 10x8 NBRACQ are promotable pieces. For e.g. Janus Chess
thus ' :C' would symbolize, that a Chancellor would not be allowed to be
selected for promotion in this situation. Extending this to Superchess'
piece set there could be a representing symbol '*'. So ':*G' could
symbolize that any available castling piece has to be selected within the
unused super pieces set and that the (G = Giant) Q+N piece is not allowed
to be promoted in.

Reinhard Scharnagl wrote on Sun, Oct 5, 2008 11:29 AM UTC:
Harm, according to your Superchess note I ask, whether the implementation
of those four piece types: Amazon (Q+N), Empress (R+N), Princess (B+N) and
Veteran (K+N) would be suffcient. It presume that it would not be
important, to name those piece types differently in SMIRF/Octopus:
Archangel (A = B+N), Centaur (C = R+N), Giant (G = Q+N) and Hydra (H =
K+N) thus defining new unique letter symbols for those types.

But still I see some problems in defining a compatibly extended X-FEN
because of the differing promotion behaviour, which could be derived from
the whole game only. Additionally it is unclear to me, how those first
PRELUDE moves have to be encoded (PGN/algebraic). Moreover it is not
clear, whether castling rights would be occupied by super-piece
replacements or not.

Piece Values[Subject Thread] [Add Response]
Reinhard Scharnagl wrote on Fri, Jul 4, 2008 04:50 PM UTC:
To Derek Nalls and H.G.M.:

For your testing purposes I will provide new SMIRF releases. There will be
three of them. The regular one will have the suffix -0, the one with the
minor increased Archbishop basic exchange value will have the suffix -1,
and the one more increased will have the suffix -2.

SMIRF basic exchange values will be for 10x8:

P=1.0000
S=3.0556
B=3.5972 
R=5.4306
A=6.6528 / 7.5685 / 8.0278
C=8.4861
Q=9.0278

So I will be waiting for your testing results ...

Reinhard Scharnagl wrote on Wed, Jul 2, 2008 05:27 PM UTC:
H.G.M.: '... But the point really is that Derek ASKS you to provide such a
version of SMIRF to help him conduct an experiment he thinks is
interesting. ...'

Harm, I have released such special versions of SMIRF. But in the meantime
SMIRF internally has separated the mobility parts from the static values
and replaces it by combining a positional detail evaluation, where needed.
This is not at all a mature approach, because I make and improve it merely
by my own.

Here I am not very interested in an epicycle theory kind approach, but
more in Kepler's laws related approach, using clear and simple
statements, which could be of practical use. To see statistical results
might give a hint for researches, but I would like to see convincing
explanations.

Reinhard Scharnagl wrote on Tue, Jul 1, 2008 06:23 PM UTC:
Derek: '... Please raise the material value of your archbishop within your
CRC model? ...'

If there would be a theoretical explanation of your value estimation
beside of that statistical argument, I will think over my model. For me
it is more interesting to have a well argued and preferred *SIMPLE*
value derivation, even if that would not match all experiences. That is,
because such thoughts also could influence the lay-out of other program
parts e.g. like the detail evaluation.

P.S.: Thus it would be best to present a short and convincing argument.

Schoolbook. 8x10 chess with the rook + knight and bishop + knight pieces added. (10x8, Cells: 80) [All Comments] [Add Comment or Rating]
Reinhard Scharnagl wrote on Sat, Jun 28, 2008 06:13 PM UTC:
Thank you, George, for explanting. In SMIRF I already have implemented traditional, symmetric and modern castling, which is defined by the King's destination squares and thus also will work for randomized setups.

But having randomized pieces, there might be Kings neighbored or near to Rooks, thus the given definiton of free castling will not be usable for such varying starting arrays, because it would ban any castling towards such blocked sides. That is a weakness, as I think. A more flexible definition therefore would be welcomed and moreover would less interfere with any claimed patents.  

How about following (which probably will be in conflict only marginally with some of those games using free castling): you can choose any square on the base row to be the King's castling target field except of the center and the border squares. The left squares are related to the left Rook, the right squares are related to the right Rook. A castling Rook will always be placed to the inner side of the castled King. Only still unmoved pieces will be allowed to castle. Castling is invalid under check or if the King will have to pass or reach a threatened square. All squares between King and its target (included) and between Rook and its target (included) have to be free from third pieces (therefore at least all squares between King and Rook have to be free).

A clear notation would be O-c-O, with a central letter related to the King's target square column.

Reinhard Scharnagl wrote on Sat, Jun 28, 2008 09:22 AM UTC:
Sam, in fact not in this thread, I repeatedly have tried to investigate details of 'free castling', which still is not quite clear to me. Maybe caused by the fact, that my mother language is german, I am still interested in some clarifications: e.g. whether the King always has to move at least two steps or not, which would be the outermost target fields, whether the Rook always has to be placed beside of the castled King or not, and what would be the recommended notation e.g. O-c-O (?). Such missing information unfortunately prevented me from implementing related variants into SMIRF.

[Subject Thread] [Add Response]
Reinhard Scharnagl wrote on Thu, Jun 26, 2008 10:40 PM UTC:
Sam Trenholme: ' ... looks like 8x10 Chess (Capablanca chess, etc.) is
dead. ...'

... must be a zombie - you can't kill it. ;-)

Grotesque Chess. A variant of Capablanca's Chess with no unprotected Pawns. (10x8, Cells: 80) [All Comments] [Add Comment or Rating]
Reinhard Scharnagl wrote on Thu, Jun 19, 2008 04:25 PM UTC:
H.G.M.: '... there is no way in WB protocol to request it from the engine ...'

This is true also for UCI. I regard this to be a very big weakness, which I have avoided in SMIRF's TMCI protocol, which is unfortunately used by nobody else but your Smirf-O-Glot. 

Because engines using that new FEN and multi-variant approach still have to be written, why not to extend used protocols in this point? A GUI SHOULD be able to ask an engine for ALL possible moves. There is no need for an intelligence for this inside the GUI, because it would not be able to grow with upcoming new variants.

H.G.M.: '... the O-i-h system ...'

Nevertheless I would like to use following convention for stored PGN files: if there is only ONE castling move possible at all, it will be matched by ANY string starting with 'O'. 

The use of different letters e.g. M (Marshal) instead of C (Chancellor) or C (Cardinal) instead of A (Archbishop) should not be handled by the FEN string, but by a new to be defined PGN translation tag e.g. for embassy chess: [translate 'M=C C=A']. This is for showing traditionally translated piece letters (to be used on the GUI and PGN only, but NOT inside FEN). An exception to this is the use of J=Janus, having the special meaning of avoiding any Chancellor. Here it would be necessary to use also an additional tag [translate 'O-O=O-O-O O-O-O=O-O'] because of the unlucky old switched encoding decision inside of Janus.

Thus a FEN string always should use those piece letters with a well defined, preferable traditional meaning: this moment I suggest J/A=Archbishop(N+B), C=Chancellor(N+R), G=General/Gladiator(N+B+R). ANY big piece type MENTIONED inside the INITIAL sent FEN might be used for promotions, additionally all the well known 8x8 and 10x8 standard pieces (but using J would disable C).

Reinhard Scharnagl wrote on Thu, Jun 19, 2008 02:22 PM UTC:
H.G.M.: '... how much effort one should put into upkeeping a unified approach ...'

Why not, if the effort isn't too big? So let's try out some ideas.

H.G.M.: uses: 'Ke1-i1&Rj1-h1'

Maybe I am too traditional, but I would like to have an encoding startig with 'O'. Here I would suggest to write 'O-i-h' using the first column letter for an untypical King's target square and the second one for an untypical (not inner neighbored) Rook's target square.

H.G.M.: '... but simply as FROM and TO square ...'

Appending a letter (I would prefer the involved Rook's/piece's source column letter) is only a partial solution, because this forces the GUI to somehow generate the input gesture squares, which demands, that its programmer has anticipated this (what is not necessarily the case at a new variant). But, because the problem of two unique squares representing this move exists nevertheless, it would be covering more, to use those square coordinates also for to communicate the move.

Nevertheless here again is an encoding problem, when a free castling would also allow to place the Rook on different selectable squares. Thus I still have problems with such types of castlings.

My understanding of a GUI is, that it has not to know much about chess. It has to ask for all the possible moves, have the user make a selection e.g. by clicking at two squares, and to communicate this choice to the engine, using the move code it has sent before by request.

Reinhard Scharnagl wrote on Thu, Jun 19, 2008 11:54 AM UTC:
To H.G.M.: Harm, you are proposing a lot of things simultaneously. So let me answer slowly. There should be a main primary demand, that such an extended FEN should end in an IDENTICAL string, when applied to common chess variants. Otherwise I would not like to support it. There already has been a quarrel concerning X-FEN and Shredder-FEN, which is incompatible to that demand. Nevertheless in the early days of X-FEN I modified its definition concerning a less important element to also cover the proposed additional demand to have a partial castling string in FEN NEVER longer than 4 letters. I would like to preserve that state of the art of X-FEN.

Actually I would like as a first step to merely support castling rights, where the castling piece will be placed upon the next inner square neighbored to the (one only) castled King. The King will be placed by default THREE steps from the a-side performing 'O-O-O' and TWO steps from the other side performing 'O-O'. The algebraic notation should use source and target coordinate, when the king is moving at least two steps when castling with the most outside Rook. Otherwise the coordinate of the involved piece has to replace the (redundant) target square. This is for to serve two goals: a) to avoid a mixing up with traditional King's moves, b) to give the GUI a unique information, by which input gesture a castling should be intended without any doubt. Such a modification should not be interpreted as a 'capturing' of the involved piece, instead as a jostling it for to have it join the castling procedure. 

To encode the castling rights: the default is to address the most outer Rook by traditional letters 'Qq' for the a-side, 'Kk' for the opposite side. In any other case the column letter of the involved piece should be used: in upper case, where a white colored piece is addressed, in lower case, where that piece would be black colored.

Now to different castling methods: because such methods would target all possible castlings (never different methods for different pieces) it does not make sense to encode this related to the elementary castlings. Instead the whole partial castling string inside a FEN has to be addressed. In SMIRF I solve this by applying a special prefix letter, which has to be different from any possible column letter to avoid misinterpretations.

Now let me stop at this point, to have the written text being discussed.

Reinhard Scharnagl wrote on Wed, Jun 18, 2008 09:29 PM UTC:
'... support for the 'free' castling ...'

This is not clear to me. I think it over to possibly implement free castling into SMIRF, but still there is missing a detailed explanation of rules and notations (I would suggest: O-c-O if King is castling to column c). Where could I have a closer look?

Piece Values[Subject Thread] [Add Response]
Reinhard Scharnagl wrote on Wed, Jun 18, 2008 09:15 PM UTC:
Sam Trenholme: '... and I needed to give Smirf over a minute to make a
move ...'

I presume, you had used the donation ware version of SMIRF, which probably
is about 150 Eló behind of the donators' bonus version of SMIRF (actually
improved again). Nevertheless Joker80 is the top 10x8 engine.

25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.