The site has moved to a new server, and there are now some issues to fix. Please report anything needing fixing with a comment to the homepage.

The Chess Variant Pages

[ 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/Ratings for a Single Item

Later Reverse Order EarlierEarliest
The Game of Nemoroth. For the sake of your sanity, do not read this variant! (8x8, Cells: 64) [All Comments] [Add Comment or Rating]
Azgoroth wrote on 2022-06-13 UTC

Fundamentally, the problem we're encountering is that Betza never gave an example of what happens when a piece is under multiple different types of compulsion. Your interpretation requires all types of compulsion to be satisfied simultaneously to count as a saving move for a piece, while my interpretation (and the one currently implemented in the Web game) requires just one type of compulsion to be satisfied.

Your example doesn't seem particularly inconsistent to me, by the way, but maybe because I'm just used to playing by my interpretation of the rules for all these years.

H. G. Muller wrote on 2022-06-09 UTC

It strikes me as a bit inconsistent that an Ichor compulsion would not count as resolved when you push the piece onto other Ichor, while it would count as twice resolved when you push it onto a Ghast square, and then back onto the same Ichor. Of course there is a clear precedent in that you don't have to completely resolve Ghast compulsion in a single move, but there at least the severity must decrease. It would be more consistent to require all types of compulsions on the same piece to be lessened. (Which for Ichor and crowdedness would mean these have to entirely disappear.)

But perhaps this is completely moot, because players would try to avoid compelling their own pieces very strongly, even when it is not required by the rules. Still, requiring more thorough resolution of compulsion would make it easier to checkmate. I don't know if that is good or bad, though.

Azgoroth wrote on 2022-06-08 UTC

It's clear that the rules of compulsion as laid out here are not quite formal. I took my own stab at interpreting them on the page that I linked. To summarize my interpretation:

  • Every compulsion defines conditions under which it is satisfied.
  • Multiple occupancy compulsion is satisfied by moving off or destroying the piece entirely (plus some edge cases).
  • Ichor compulsion is satisfied by moving off, being pushed to a non-ichorous square, or destroying the piece entirely (plus some edge cases).
  • Ghast compulsion is satisfied by fleeing, being pushed further from the Ghast, destroying the Ghast, or destroying the piece (plus some edge cases).
  • If it's your turn and one of your pieces is compelled, you must make a legal move that satisfies at least one of your pieces' compulsions.
  • There is nothing wrong with adding new compulsions to your pieces, although this is only possible with either a Go Away's push or by a Wounded Fiend leaving a square containing another one of your pieces.

While typing this up I realized that there are a few omissions in my edge cases, which I will rectify when I get a chance. It really is tough to enumerate all the cases!

H. G. Muller wrote on 2022-06-08 UTC

Indeed, the digestion is most conveniently indicated through changing the piece type to a visibly different one. It is no crime in chess variants to have invisible game state (e.g. castling rights in orthodox Chess), but I think this would just invite errors in the Leaf Pile case.

It is true that 'collapsing' game-theoretically identical piece types into one would affect the repetition rule. But this seems an advantage rather than a disadvantage. What would be the use of prolonging play by allowing another set of repetitions of game states that are considered artificially different (e.g. because two Mummies got swapped)? In the end repeating the sequence of moves will swap the pieces back, with the same result. In my experience pieces almost never get swapped in games without drops. (Jocly considers pieces of the same type distinguishable when testing for repetitions, in deviation of FIDE rules, and it only started to cause problems when I implemented Shogi variants.)

BTW, I am pondering about how to make a more compact description of the rules of this excellent game. A formulation that seems to go a long way would be:

Pieces can change location either by 'Moving', or by being pushed (by a Go Away). In general, Moving is only allowed to empty, unpolluted squares. But there is no restriction on squares pieces can be pushed to; the pushed pieces will coexist there with any previous occupants. Exceptions are the Zombie (which can Move to any square, and then destroys all pieces that were there before), and the Leaf Pile (which can Move to unpolluted squares containing only mobile pieces). Zombies cannot coexist with Ichor, and the two agents destroy each other. Leaf Piles digest all pieces that try to coexist with them; when two Leaf Piles meet the stationary one is digested. Removal of pieces due to failure to coexist happens automatically at the end of any turn.

About the UI issues with Go-Away pushing order: wouldn't it be a natural interface to highlight all adjacent pieces after ordering a push by clicking the Go Away twice (as already has to be done now), and then allow the user to 'click them away' one by one?

And some thoughts about compulsion:

Replacing a Ghast compulsion by a lesser one (at greater distance) was explicity declared to be legal. The other two types of compulsion do not exist in grades. (Although they could, depending on the age of the Ichor or the number of pieces in a crowded square.) It was not specified whether it was legal to replace one type of compulsion by another. E.g. when a piece is pushed from an ichorous square onto a Ghast square, is the compulsion addressed? And when the reverse happens? What if a piece gets pushed to an ichorous Ghast square? Can you resolve that by pushing it to an empty square closer to the Ghast? Or would you have to address all pre-existing compulsions on the same piece simultaneously?

I would be inclined to require that, with the exception of getting a lesser Ghast compulsion, the piece should be free of all compulsions after the move in order to count that move as legal.

Azgoroth wrote on 2022-06-08 UTC

The observations that certain pieces become effectively neutral in color on petrification, and that a petrified Go Away is identical to a Mummy, are almost true. However, if one were to actually make such reductions during play, information would be lost as far as counting repetitions of positions goes.

Unrelated but worth mentioning while I'm here: in my Nemoroth implementation, there are really two Leaf Pile piece types, normal and "digesting." A normal Leaf Pile becomes a digesting Leaf Pile upon engulfing a piece, and a digesting Leaf Pile reverts back to normal when it moves of its own accord (i.e. not as a result of a Go Away's scream). It's rather important to keep track of this state, or you won't remember whether the Leaf Pile is supposed to leave behind a Mummy. This is an unfortunate omission from the otherwise fine scheme in the "Nemoroth Notation" article by John Lawson -- I would suggest using a "d" prefix to indicate digestion, such as in "dL."

H. G. Muller wrote on 2022-06-07 UTCExcellent ★★★★★

Some Nemoroth pieces are 'color blind': they capture or otherwise affect friendly and enemy pieces in exactly the same way. The only effect of their allegeance is then which player is allowed to move them. But when they are petrified neither player can move them, and in effect they become neutral. An alabaster and an obsidian Leaf Pile are really the same piece, from a game-theoretical point of view, and that also holds for petrified Wounded Fiends. Likewise petrified Go Aways are all the same. And since they lose their special power on petrification, they are also the same as a Mummy. And they only differ from petrified Humans when we adopt the rule that petrified Humans promote to Zombie when pushed to last rank. Which would also make it necessary to distinguish petrified Humans by color.

Petrified Basilisks remember their allegeance because of the Basilisk's asymmetric move, which is preserved in the way it sees. Ghasts have a more severe effect on foes as on friends.

H. G. Muller wrote on 2022-05-26 UTC

Impressive! So far the complexity of this game even deterred me from reading through the rules.

The way it is described is a bit confusing. Basilisk squares and Ghast squares are not really different types of squares, and what happens there just follows from the proximity of the Basilisk or the Ghast. They do not define additional game state. For ichorous squares, the amount of ichor on a square is part of the game state, however. So there really are many different types of ichorous squares. Since having multiple pieces on the same square is normal procedure in this game, Ichor might as well be considered an additional unmovable and unpushable piece. For over-the-board play I would use stacks of Draughts chips for representing Ichor, and just unstack the topmost on every square at the end of each turn.

A suggestion: wouldn't it be 'cleaner' to consider the go-away move a simultaneous operation, if you abandon the idea of having the moving player specify an order? Just displace all adjacent pieces first, and only then calculate the side effects of each from the new position?

[Edit] While reading back through the comments, I see that Adrian King had already proposed the same, concerning the Go Away.

Azgoroth wrote on 2022-05-26 UTCExcellent ★★★★★

Just over twenty years after the initial publication of this page, the first ever computer implementation of Nemoroth is live, complete with a basic alpha-beta pruning AI. You can play in your browser at this link:

The only thing I haven't implemented is the Go Away push order, which I've been putting off due to how laborious the UI considerations are. As a placeholder, Go Away pushes are clockwise from top.

I originally wrote this implementation in TypeScript, but the AI was too slow and I ported it over to C++ using WebAssembly. I plan on open sourcing it eventually once I have more opportunities to clean up the code. This is one of the most difficult software projects I have ever worked on; I have known about Nemoroth since around 2013 but was not a strong enough of a programmer to pull it off until now.

I found a number of ambiguities in these rules, which I have tried my best to address reasonably on the linked page. Some have been covered in this comments section, some not (for example, if a Wounded Fiend leaves an already ichorated square, does the ichor stack to 11+ plies or max out at 10?).

The AI is surprisingly dangerous. It mobilizes the Ghast immediately and WILL advance it to d4/d5 if you let it, usually costing you the game. I have managed to beat it a few times, but it's tough as nails for how crude the programming is. Beware!

Ralph, if you're out there, thanks for this amazing variant. I tried to email you to get permission to make this but alas, I never heard back.

George Duke wrote on 2016-10-31 UTCGood ★★★★

Traditional for Halloween October.

Georg Spengler wrote on 2015-01-04 UTCExcellent ★★★★★
What a game!

I didn't know that it is possible to create a game using pieces that are credibly EVIL. That's not just a game, it's a piece of art.

I'm not convinced though, that it is playable "by mere mortals" without minor changes. The most problematic piece is the Ghast. It's presence restricts the possible opening play for the second player to a few playable variations.

If you happen to hear strange voices when trying this game, don't bother! Thats normal...

(zzo38) A. Black wrote on 2013-04-22 UTCExcellent ★★★★★

I may already be sufficiently insane to read this. I prefer using flat pieces that won't scream and whatever, but I don't mind if it has to do the other way, since that is OK, too. It is complicated, but it seems well enough to work. Some things are not entirely clear; the document should really be improved to clarify the rules more.

Now make the variant which is mostly this game but can also use a hand of cards (drawn from a shuffled deck and hidden from opponent, and used for a few additional special actions by playing combinations properly, including to affect opponent's cards), betting, scoring, and other things. (And if you are in a manga written by Fukumoto, even betting your fingers and your blood and billions of yen, and cheating in extreme ways, and the use of double and triple bluffs and so on.)

Michael Nelson wrote on 2011-10-18 UTC
Perhaps a rule change for the Go-Away scream is in order. I would suggest something like this:

1. All pushes are executed.
2. Any Human to Zombie promotions are executed.
3. Any effects resulting in piece destruction are executed (engulfment, zombies on ichor or multiple occupancy squares, etc.).
4. Any petrifications are executed. 

All partial moves under a single number would be deemed simultaneous.

Under this proposed rule, the owner of the Go-Away is unable to specify the order of effects. This will reduce the tactical complexity of these moves and hopefully render the programming problem tractable.

Whether it would overly damage the peculiar and interesting flavor of Nemoroth is a question I'm not qualified to answer.

Nicholas Wolff wrote on 2011-04-21 UTC
I have an excel document with some pieces that I'd be willing to play someone a game with via email. Any takers? Shoot me an email at therealwolff (at) gmail (dot) com. I've been trying to play a game of this for a while, but the person I have been playing via email hasn't moved in months, now. Thanks!

Anonymous wrote on 2011-04-18 UTC

In response to the comments made on 2011-4-16: Thanks! I now have a pretty good idea of how the algorithm would work. Since the insanely complicated nature of this game forces me to use large hierarchies of objects, manipulating them is a slow process. Hence, the second method would probably work better; it's a good bit faster.

Jeremy Lennert wrote on 2011-04-17 UTC
Suppose Alabaster opens 1. Gb3. This threatens 2. Gd5, placing five Obsidian Humans under compulsion to flee (b7, c7, d7, e7, f7). After b7-a6, f7-g6, c7-b7, e7-f7, and d7-c7 or d7-e7, Obsidian still has compulsions on 3 Humans and no way to satisfy or remove any of them, and thus loses.

It appears to me that Obsidian's only answers to 1. Gb3 that avoid immediate loss are 1...Gb6 or 1...Gf6 (petrified), preventing the Alabaster Ghast from entering d5. Does anyone see another option?

John Lawson wrote on 2011-04-17 UTC
My point about the Ghast was not about pushing a piece closer to a Ghast, but pushing the Ghast itself.  There is no compulsion for a Go-Away to flee a friendly Ghast if it approaches, but if the Go-Away screams, the Ghast will move and potentially create compulsions in other pieces not affected by the Go-Away's scream.  It says in the rules 'The Go Away cannot approach a Ghast, and may be compelled to flee an enemy Ghast (but pushing the Ghast further away counts as flight).'
The mind boggles.

Jeremy Lennert wrote on 2011-04-17 UTC
This example from the rules strikes me as inconsistent: 'If a Human that is compelled to flee a Ghast can advance to its eighth rank and thus promote to a fearless Zombie, it does not matter whether the move is a geometrical flight; by promoting, it removes its compulsion to flee and thus is saved.'

For example, Obsidian Ghast on d8, Alabaster Human on f7, Human f7-e8=Zombie.

Although promotion removes the compulsion, there is ALSO a rule that a piece cannot approach either Ghast (even when it is not under compulsion at all). Thus, it seems that this move should be illegal; not because it fails to satisfy the compulsion, but because it violates the restriction against approaching a Ghast.

However, a Go Away on g6 could scream, pushing the Human to e8. This does not violate the restriction, because the Human is not approaching the Ghast voluntarily, and it removes the compulsion, because the Human is promoted to a Zombie.

Jeremy Lennert wrote on 2011-04-17 UTC
If it wasn't obvious from my previous post on push-order of Basilisks during a scream, once you identify the pieces whose order matters, the screaming player effectively gets to choose, independently for each piece, whether to petrify it or not. So you don't necessarily even need to code an explicit order of movements, just present a list of the relevant pieces with a 'Petrify? Y/N' choice for each one.

The push-order of Ghasts doesn't seem to matter, because pushing a piece closer to a Ghast is not illegal (the move is not voluntary), and whether you satisfied a compulsion to flee presumably depends only on distances at the very end of the turn.

To respond to a couple of earlier questions:

I don't see why pushing a piece from an ichorous square to another ichorous square would be illegal; the piece is not *voluntarily* entering ichor.

A Go Away that is adjacent to a friendly Ghast may certainly scream, because that pushes the Ghast away and thus counts as fleeing (since distance is increased). A Go Away that is within range of a friendly Ghast but not adjacent to it seems to me like it should not be able to scream, but that is just my guess at the answer.

John Lawson wrote on 2011-04-17 UTC
Whew! OK, I'm going to think about that for a while (I have to go back and study the interactions section). Don't Ghasts also cause you a problem, since they can trigger cascading flight?

Jeremy Lennert wrote on 2011-04-16 UTC
Sorry, 16 permutations.

Jeremy Lennert wrote on 2011-04-16 UTC
If only the Basilisks complicate matters (and not the relative order of
other pieces), then at worst you need to consider every ordering of
Basilisks and decide whether each other piece is moved before, between, or
after them, which is 2 * 3^6 = 1458 combinations.  With one adjacent
Basilisk, the worst case is 2^7 = 128.  I suspect that's plenty small to
brute force.

But if you want to be clever, I believe the only times order matters are
when a Basilisk sees a pushed piece's destination before the Basilisk
moves (so it petrifies that piece only if moved second), or when it sees a
pushed piece's origin after the Basilisk moves (so it petrifies that piece
only if moved first).  So you can list all the potential interactions where
order matters:

Basilisk N relative to NW and NE
Basilisk S relative to E and W
Basilisk E or W relative to N
Basilisk SE or SW relative to S
(A Basilisk NW or SW would petrify the Go Away and prevent it from

Where N (north) is the average direction of the Basilisk's Knight moves;
so with a Go Away on e4, an Alabaster Basilisk on e5 is 'north' and so
order-dependent with d5 and f5, but an Obsidian Basilisk on e5 is 'south'
and so order-dependent with d4 and f4.

So the order of the Basilisk only matters relative to at most 2 other
pieces, giving at most 8 permutations in the worst case (there's only one
case where both Basilisks affect the same pieces, and in that particular
case you might as well move the Basilisks simultaneously).

Anonymous wrote on 2011-04-15 UTC

I'll try to explain as best as I can. This is what I want the computer to do:

Given a Go Away surrounded by one or more pieces, get all the distinct positions the Go Away can produce by screaming.

This is a trivial problem if there are no Basilisks involved, but otherwise it's quite difficult. There are many pushing orders and only a few different resulting positions.

In a worst-case scenario, we may have the Go Away surrounded by both Basilisks and six other pieces. In such a case, there are 8! = 40320 different ways the eight pieces can be pushed, but only a few of those have distinct resulting positions. If we choose to loop through all of the ways, we'll be iterating over tens of thousands of redundant orders! That's not good for efficiency.

John Lawson wrote on 2011-04-04 UTC
I don't understand why you see so many alternatives. What is your thinking on the interaction of the Go-Away and the Basilisk?

Anonymous wrote on 2011-03-30 UTC

One of the major problems that I find in coding this game is calculating all possible moves for a Go Away when it is adjacent to one or both Basilisks. Obviously, a computer program can't loop through all 40320 possibilities and check each one! Does anyone have any suggestions for optimizations?

John Lawson wrote on 2010-10-27 UTC
No, I don't think so. 'No piece, neither friend nor foe, will dare venture upon an an ichorous square'

25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.