How Can I Create a Variant?

It might also be a problem with duplecheck.  I don't exactly know how to implement special rules, so I guessed and this is what I used:

Rule: checkmate = win

Rule: stalemate = draw

Rule: duplecheck

I don't completely understand what the problem is, probably because I don't know what exactly the rules of your variant are. The usual way Chess variants work is that royal pieces can be captured the same way as any other piece, and that you lose when your last royal is captured (sometimes with an exception for stalemates). 'In check' usually means you would lose the game in the next move if you passed your turn. So logically when you would have multiple royals and one gets attacked, you would not be in check, as the worst the opponnent could do after your turn pass is capture the attacked royal, which is not losing as you still have the other one. (Assuming we are dealing with 'extinction royalty', rather than 'absolute royalty', where loss of the first royal would decide the game.)

'Duple check',( which is a concept I only ever encountered in Spartan Chess), is an exception to this, where you cannot leave more than one royal in check, even though the opponent could capture at most one when you passed your turn. This is an independent rule that does not logically follow from the normal royalty rules.

With multiple royalty you cannot avoid exposing one of the royals to capture (e.g. they could be forked, and you can rescue only one). With absolute royalty that would mean you are checkmated, but with extinction royalty you would just play on and let one be captured, rescuing the other on the next move if that problem did not resolve itself.

So how exactly is it supposed to work in your variant?

It is supposed to be absolute royalty.  A loss of either piece results in checkmate.

Beyond that, non-royal pieces aren't allowed to capture in this variant.  However, they are supposed to be able to deliver check, and unfortunately the two appear to be mutually exclusive.

Then it's really simple.  Download the link that HGMuller provided above, and change the initial setup.

This is indeed a rather unusual combination. The problem with configurable engines like Sjaak II is that it is hard for a programmer to foresee every possible option a user could need. It seems that what you want is a specific case of the more general concept of 'iron' pieces: pieces that are immune to capture. This transfers the property from the attacker to the victim.

What you describe could be achieved by giving all pieces normal captures, but declaring all non-royals as 'iron'. Then only the royals have to avoid the captures (as they are absolutely royal, so that neither of them is allowed to expose itself to a capture).

Unfortunately the latest version of Sjaak II does support neither iron pieces nor absolute royalty. I have already taken up this issue with the Sjaak II author, and he agrees both these concepts are of sufficient general interest to justify their implementation in the next release of Sjaak II. I have no idea when that will be, however.

A more fundamental question is whether Sjaak II (or any other engine) is really what you want. You mentioned that your aim was to play other people over the internet. An engine will not in any way help you do that: it is an AI that thinks up moves, against which you could play on your own PC. This of course is interesting enough in itself. But an engine won't connect you to anyone.

Actually, Royalties are supposed to be able to capture pieces as well, but yeah, it's kind of a brick wall.  The reason that I'm using Sjaak II is that I really just want to get it down, if you know what I mean.  Ideas mean nothing in the long run, unless people can see that you actually did something with them.

Do you have contact info with the creator of Sjaak II?  I tried his email but it was rejected.

He is a quite active poster on the TalkChess.com forum (e.g. http://www.talkchess.com/forum/viewtopic.php?t=59531 ).

It seems your variant has rather complex rules for what is allowed to capture what. This is quite unusual, and therefore unlikely to occur as an option in any general-purpose Chess-variant software. Zillions of Games could probably do it, as it is extremely general. The price for this is usually that it becomes impossibly complex to do it. (The so-called "maximum-flexibility, minimum-usefulness principle".) To allow specification of every conceivable rule, the specification format must become sort of a general-purpose programming language in itself.

My own configurable Chess-variant engine, Fairy-Max, also doesn't support "selective capturing" as a standard option. But if it is just a matter to forbid non-royal capturing non-royal, (so that royals can capture everything, and non-royals only royals, and thus deliver check) this would be a rather trivial program change. I am not sure how strong a standard Chess-variant engine would still be with this rules. The major goal of such engines during the middle-game is to gain material, and if capture would be a rare event, they might not know what to do, and just start shuffling their pieces aimlessly.

Well dang.  The search continues...  Although it looked like the designer was interested in adding those features to the new version of Sjaak II, so maybe some day.

I would like to see how Sjaak II handles my variant, although I had figured it would lose most of the games.  There are a few reasons for my assumption.  First, with two royal pieces Sjaak II won't know how to keep its royalties safe (although to be fair it's a bit difficult for human players too!), and as a result it will probably fall into a lot of perpetual check nets, which usually result in mates some time down the line.  Secondly, like you said, it wants to capture material (in fact, Sjaak II seems much more material hungry than most chess engines I've seen) so it would be really confused by iron pieces.

Here's a good example of the king-safety issues: I made a variant that I called "Endgame," where both sides have eight pawns and one "queen," which actually moves like a king but can't be checked.  Sjaak II is actually very easy to beat in this variant, because it thinks that its king needs to be safe with Queens on the board.  Of course, human players recognize that the Queen is essentially equivalent to a King, and thus the only way to win is to get the King involved early.  It's fun to beat a computer

Well, if I were you I would not get up my hopes too much that Sjaak II will ever be useful to you, unless you would disclose the exact rules fo your variant.

Apart from that, I am also pretty sure that Sjaak II doesn't care at all how you name the pieces. You can wreck its play by lying to it about the piece values, of course; it has a heuristic to derive piece values itself, and would no doubt consider a piece that moves like a King as a pretty weak piece, where its royal King would not have to be afraid for. But if you specify a value, that overrules (by design) Sjaak's own opinion.

So it is quite easy to make 'variants' that you can easily win, e.g. by specifying the Pawn value as 500, and the value of all other pieces as 100, so that Sjaak will immediately start trading all his pieces for your Pawns. This has not much to do with the variant, however, but everything with configuring it wrongly. I would be surprised if with the correct value of the non-royal King (around 300 centi-Pawn) Sjaak would not be a tough opponent in this 'end-game' variant of yours.

Garbage in, garbage out, so to speak...

Well, there's only so much you can do with the evaluation of a program that has no build-in preconceptions about how pieces move. It's one thing to put in pawn structure evaluation terms, it's another to put in pawn structure evaluation terms when you can't make assumptions about how pawns move.

Anyway, here's a sample game at 4:1 time odds (white had 5 seconds/40 moves, black had 20):

As for making a game that starts with and end-game position, that will indeed break one basic assumption: that the game can be divided in two phases, an "opening" where the king is meant to be kept safe, and an "ending" where the king needs to participate. If you input an "opening" position that is really an end game, you break the evaluation. It's easy to think of a way to fix that in a particular case, but hard to do in general (I don't want to hard-code too many assumptions).

If you want to give it a fair chance to evaluate the position better, define the variant with a full array, then enter the position you actually want in the GUI.

It estimates the value of a Commoner at 333cp (same as a knight), which is a bit high but not too aweful. Independently of what value you give it by hand though, the heuristic will only ever consider it to be as dangerous as a knight for the purpose of king safety, and it will also only weigh it the same as a minor for the purpose of determining game phase. So the damage you can inflict on the evaluation by mis-handling the piece values is limited (and if I would trust the heuristic to do a half-way decent job at piece values in the general case, I'd get rid of the ability to input them; as it stands it's better to leave them blank if you have no idea what they should be).

Where things break down though is that the game phase runs from 0 (pawn ending) to whatever it was in the initial array (for the opening), so defining the variant with an end game position as the starting position completely wrecks the evaluation. Of course it's pretty obvious that if the calculated game phase of the opening corresponds to a minor piece, then the whole game phase scaling should be discarded and the phase fixed to the end game, but I don't want to draw an arbitrary line there. It's something I hadn't considered though, so I'll have to give it some thought.

In games with drops I never advance the game phase at all, which seems reasonable. That can be deduced directly from the rules of the game though...

Fairy-Max determines the game phase by absolute criteria, rather than relative to the opening position. It considers it save to come out with the King (i.e. switches off its rudimentary notion of King Safety) when the opponent material is down to Q, 2R or 4 minors. I think that is the only thing that makes sense. Why would the fact that initially the opponent had 3 queen-class pieces (as in Seirawan) suddenly make it good to let the King come out of hiding against Q+R, while it should be considered suicidal in orthodox Chess? The position is the same, so the evaluation should be the same.

I did something like that originally by normalising the material weight on the material in orthochess. This gives a slightly higher weight to king safety in Spartan Chess and a much greater weight in something like Capablanca Chess, which seems reasonable. The problem is that it completely wrecked something like Makruk, where king safety should still be a concern although pieces are much weaker.

What I have now was the best compromise I could come up with, but it's not without issues and I'd like to replace it with something better, I just haven't had time to work out how.

There are a number of things that need to be figured out for this:

1. Does it even make sense to advance the strategy from a "hide the king" to a "bring the king to the centre and start pushing pawns" phase? For many variants it does, but for instance for drop variants like Shogi it does not (so they're locked in "hide the king" phase).
2. Should "bring the king out of hiding" and "start pushing pawns" depend on different things? Almost certainly, but they're lumped together and interpolated using the same interpolation factor.
3. Should the castle/shelter be scale in the same way?
4. The king safety currently saturates at 416 evaluation units, but there isn't much difference in performance for the range 384-500. Should this be scaled somehow for different variants? Probably, if for no other reason than that things will completely break if the user decides that pawns are worth 1000 units rather than 100 units (I could always scale piece values entered by the user, of course).
5. This probably needs a mix of an absolute scale (Q, 2R or 3M all roughly come to a weight of 24 in SjaakII's weighting which seems reasonable-ish) and some terms that are scaled based on the material that participates in the variant.

In short, it's hard if you want the evaluation to auto-adjust for arbitrary variants. ;)

One of the things I want to do (there have been feature request for it even) is to expose the evaluation settings to the user, so they can create "personalities". This will also make it easier to experiment with things like this, but again: I haven't found the time too fully implement that...

I still don't see why it would be any safer to have the King stroll around against 2 Rooks and 2 Knights in Makruk than it would be in Chess. It might be less important to do it in Makruk, because there is less to be gained by pushing your Pawns to promotion. But the logical way to treat that is to scale the King PST based on the value of Pawn promotion.

The popular model of interpolating all evaluation terms the same way between opening and end-game seems quite wrong. King Safety depends much more abruptly on material than Pawn pushing. At some point you just want to drop it entirely, while you still would like other terms to progress towards an end-game value (e.g. to encourage simplification when ahead).

For drop variants game phasing as in Chess makes indeed no sense. In Shogi they still do recognize a certain game phase as 'end-game', but it seems based on King Safety, not material: it describes the phase where both castles have been destroyed / severely compromized, and the game has become a "race to mate" as being checkmated would be unavoidable.

What you need to realize about the "end-game" variant I made was that the Queen only has a value of 200 in the .txt file.  Looking at it now, I agree its value is probably higher than that (explaining why he would sometimes sack his queen for two pawns and then get trashed), but the point still stands: the computer is feeling unsafe about his king despite the fact that no pieces which can attack it are on the board.

And what I really meant by this example is partly what you had already explained, which is that the computer can't handle games very well if it doesn't understand certain aspects.  Sjaak II will never really play my variant well, because having two royalties turns off King-Safety.  As a result, I expect it to be a sub-par player, should I ever get the variant working in Sjaak II.

And about that: to specify about what I need, it's basically just absolute royalty, iron pieces, and a flag allowing pieces to capture iron pieces.  I'm not sure if these will be added, but maybe someday.

What makes you think having two royals would turn off king safety? Fairy-Max would not turn off the little bit of king safety it has when it has two royals. A royal Queen would probaly not need much safety anyway, mobile as she is.

The problem with your variant (as we understand it) is that it is a dead draw from the outset. Even if you get the advantage of two Rooks and two Bishops in the opening, you still would not be able to win. The opponent would just close the position with a rank of protected Pawns.

Actually, SjaakII will never consider its king to be "unsafe" due to the presence of a single piece - certainly not if it's not even attacking the zone near the king. However, if all initial material is still present, it will consider it too early to bring out the king. This is something very different, and it happens because the variant definition breaks one of the basic assumptions: that the game can be divided in two phases. Define the variant with a full array in the initial position and then set up the end game position and give it another try.

When dealing with multiple royals, I originally calculated king safety for both and used some sort of weighted sum (you can make some argument for any particular weight). This is in the context of Spartan Chess, where it turned out that the best option was to not bother with king safety as long as both Spartan kings are on the board. I can bring back the old code easily enough (or write something better) if needed. The question is if it is.
Be aware though: SjaakII will never be as good in a variant as a dedicated engine should be (proof: take SjaakII and remove everything you don't need for variant X. It is now better at variant X than it was before).

Anyway, my development version has a flag to enable check detection when multiple royals are present, and it allows you to customise the victim list for each piece type (including the royals is redundant for this; any piece that can capture can check a royal), so it can play what you described. The problem is that it just closes the position and waits for the draw. Giving 4:1 time odds isn't enough to prevent that.

In Sjaak II's variant instructions page it tells you that it won't calculate for king safety if more than one royal piece is on the board.  And the variant is not what you're expecting, there are no pawns on the board.  Trust me, I've played it almost a hundred times, there's practically no such thing as a draw unless you can force a three-fold repetition from a losing position.

Yes, but that is the instruction page for a version of Sjaak II that in case of multiple royals always assumes it is extinction royalty. Trying to keep both Kings safe in that case is a losing strategy; keeping one King safe and using the other in battle is much better. The program would typically try to avoid situations in which both Kings are unsafe, because in its search it would then see one being lost, which would bring it back in a situation where there only is a single royal, for which it then evaluates King safety again (and would not like it when that is poor).

When the program would be extended with an option for absolute royalty, it would of course have to keep both Kings safe, so there would be no reason at all to switch off King safety. Where with extinction royalty the King safety is dominated by that of your safest King, having the second one providing a small bonus to it, for absolute royalty it would be dominated by that of your unsafest King, the other one being an extra liability.

I once tested with Fairy-Max the value of an extra absolutely royal King in a FIDE setup without Queens. It was practically zero; the side with the two Kings did not have a measurable advantage from it.

Of course there still is the question of how important safety is for a royal piece that does not move as an orthodox King. My guess is that for a royal Queen no extra safety terms are needed; Queens are 'intrinsically safe' because of their high mobility. With multiple absolute royals it might be useful to have evaluation terms that punish putting them in relative locations that allow them to be forked or skewered, however.

It doesn't really matter what is and isn't on the instructions page, I haven't updated that in ages (and it doesn't mention evaluation at all; do you mean the "evaluation" page? Note that that talks about Sjaak rather than Sjaak II, which is a complete rewrite).

I see a 95%+ draw rate in self-play at 4:1 time odds, and an even split in win/loss between both engines, so the side with more time wins as often as it loses.

What do you mean "there are no pawns on the board"?