Comments/Ratings for a Single Item
Anyway, just a couple of questions that came to my mind while reading the rules for the 10th time (I probably know them by hard now, I just love reading them =P):
1) Suppose we've got a mummy and a statue in the same square (possible, thanks to the marbelous deeds of a Go Away/Banshee/Dread), now if pushed once more, they'll travel toghether, right? (i guess the same would happen with any combinations of contents being pushed as a matter of fact).
2) Well, that was pretty silly, but how about this one: suppose there's a Leaf Pile engulfing them (or whatever else you care for it to engulf) and a Go Away/Banshee/Dread pushes, will the engulfed piece be pushed as well? or is it just the Leaf Pile that gets pushed leaving behind the engulfed pieces unharmed?
3) Now that I'm at it, about engulfing, by it you mean that the 'engulfed' pieces cannot move, right? It's kind of logical since they are 'removed' from the board and only the Leaf Pile remains.
4) Any ideas as to how many different statues could there be? I mean, a petrified Go Away/Banshee/Dread is pretty much like a petrified Human for that matter (I think I read a comment addressing the same issue).
5) Any ideas as for how many pieces (maximun amount) can there be in a single position? Something like an Upper bound...?
OK, that's pretty much it, great game!
cheers!
Hi, me again... I've got just one more question (for the moment at least), it regards Ghasts and the compulsion to flee them. Let me see if I got it right. Consider this 'diagram': +---+---+---+---+---+ | 5 | 4 | 3 | 4 | 5 | +---+---+---+---+---+ | 4 | 2 | 1 | 2 | 4 | +---+---+---+---+---+ | 3 | 1 | G | 1 | 3 | +---+---+---+---+---+ | 4 | 2 | 1 | 2 | 4 | +---+---+---+---+---+ | 5 | 4 | 3 | 4 | 5 | +---+---+---+---+---+ Whilst fleeing the Ghast, a piece in any of the numbered squares can only move to a higher-numbered one, right? Now, suppose this particular piece is a rider (a Wounded Fiend actually, since Zombies fear not the hideous Ghast), can it approach the Ghast (by riding through a lower-numbered square) if it ends its move past the Ghast's influence? or should it ride in the direction indicated by higher-numbered squares only? (for example: can a Wounded Fiend in a '2' square ride horizontally through the '1' square ending its move past the '4' square, or must he flee in the opposite direction?) Thanks in advance for your time. Cheers... ...Ingrid. PS: I hope this 'thread'/game/whatever (I dunno how to call a series of follow-ups on comments) is not dead but just a bit dated, I'd really love to play this game!!
:((((((((( Oh...how terrible, really.... Well, I guess I'll just read the rules more carefully or 'fill in the holes' myself in order to play it. Terrible, terrible news.... Thanks for your time. Bye... ...Ingrid
A question? Can a go away push pieces off the board? If not what would happen if a go away on g8 used it's special move on a piece on h8?
Nemoroth is very difficult to play legally. I think every game Ben and I played, there were illegal moves that had to be taken back, usually involving the effects of the Ghast. You may also note that no one ever posted a Nemoroth variant. I toyed with one based on bodily functions, but it was untested, and I am as far from Ralph Betza as can be. I never posted it, as a 'humor' piece, because it would have violated the CVP's G rating. (For those not familiar with the US movie ratings, a G rated film has no sex, no violence, and is considered suitable for very young children.)
Raplh Betza posted this game after I stopped haunting the Chess Variant Pages around 2000, and so I didn't become aware of it until recently. And having become aware of it, I am (like some of the previous posters) intrigued by the extreme challenge (apparently yet unmet) of writing a ZRF for it. In response to Robert Price's post of 2004-01-17, it seems to me that the nonsimultaneous shout of the Go Away is actually a more interesting problem than multiple occupancy. As far as I know, Mr. Price's proposal to treat this as a 3-dimensional game with visually overlapping cells is, although a pain to code, the appropriate solution for Zillions. However, I believe it is infeasible to code a Go Away shout as a single Zillions move. As Mr. Price implies, using add-partial to code a shout as a series of all legal submoves is likely to result in a very weak computer opponent, because Zillions will be able to look ahead only a very short distance when a complicated shout is available. Nonetheless, I think you have to do just that. The reason why the shout is so troublesome is that in the worst case, a Go Away can be surrounded by a large number of pieces, including both Basilisks. As I understand it, the order in which a Go Away pushes pieces does not matter unless it pushes Basilisks; but if does push Basilisks, then it matters which pieces are pushed before and which after each Basilisk. That means that when a Go Away is surrounding by n non-Basilisk pieces subject to petrification (that is, n pieces that are not Basilisks, and not statues or otherwise immune to the Basilisk's glare), the number of distinct moves a Go Away can make is equal to the number of ways to partition a set into b + 1 parts, where b is the number of Basilisks among the n pieces. For a large n (say, 8 or so, but multiple occupancy can result in an even larger n than 8), this is a big enough number for one Basilisk (256 for n = 8), and an even bigger one for two (6561 for n = 8). Certainly the number could be big enough that the menu of move choices Zillions would display for a single-move Go Away shout would be substantially larger than the average computer screen. I know such menus are broken into multiple columns when longer than the height of the screen, but a big shout could easily fill the entire width of the screen with such columns, and still not be done. What happens then? I've never seen a program display such a long list of choices, but my experience with Microsoft products leads to me fear that Windows does not handle the situation gracefully. However, I think there is a solution involving add-partial that is near optimal. Code it as follows: first move all the non-Basilisk petrification-immune pieces simultaneously, and then move each of the remaining pieces in a partial move. I think the result in terms of lookahead difficulty is the same for Zillions as for a single-move shout, but the menus should be manageable for a human player. If someone who understands the implications of the rules of Nemoroth better than I do figures out that there is actually a tight enough constraint on the number of nonpetrifiable pieces that can be adjacent to a Go Away that the unitary Go Away move actually is feasible, I'd welcome the news. In any case, Nemoroth is an extremely deep game, much more so than any other pure strategy game I know of, and computers are likely to play it very badly for the foreseeable future. An alternative to implementing the full rules might be to nerf the Go Away, and code its shout as simultaneous (move all the pieces first, and only then calculate the Basilisks' effects). This would not really be Nemoroth, of course; it would be a less deep variant (you might call it Nemoroth Lite), but computers might play it better. As an aside, I'm grateful for John Lawson's comment of 2008-10-30, where he says it's difficult to play Nemoroth legally. When I first read the rules, I thought, there's no way I'd be able to figure out what was a legal move in this game without a computer to help me. I'm glad it's not just my own thickheadedness.
While re-visiting the comments for this game, I realized that I had not given it a rating. So now I correct that oversight. I've finally accepted that this game will be extremely difficult to code. So for the sake of my own sanity I have given up such an attempt. But it has been fun trying. Like hitting myself with a hammer. :) This is not to say that it will not eventually be coded. I just realize that it will probably need its own dedicated program to accomplish this. And such a project will be merely a labor of love(or obsession) because there will probably never be sufficient monetary reward to cover this effort. If anyone decides to make such an attempt, they have my sympathy. ;-)
Instead of 'Multiple Occupancy', why not use 'Crowdness' to indicate the status of multiple pieces on the same square? That sounds better and easier. Also I think, if one wants to rewrite the rule for readability, what he needs is to modify the order to introduce the pieces and statuses. For example: 1. Humans, starting at the normal pawn squares, moves 1 square without capture in 5 directions, namely 1 forward one, 2 diagonally forward ones, and 2 sideways ones. Upon arriving at the 8th rank promotes to Zombies, which are very strong. Just remember the name for now. 2. Go Aways, starting at the normal bishop squares, jumps 2 rookwise or moves 1 diagonally. Instead of moving, may scream, which push adjacent things away. Pushing things onto non-empty squares results in crowded ones. Living things that find themselves in a crowd are compelled to move out. Compulsions: the status in which ... Just like that. I don't have time to write a full version, just want anyone else to do it.
'Mobile pieces within the range of an allied Ghast are not compelled to move, but when they do move they must flee.' Wait...does the Go Away's scream count as a movement? If a Go Away is on a square in the range of a friendly Ghast, is it permitted to scream? I assume that the answer is 'yes,' since the example game includes a portion in which an Alabaster Go Away screams while adjacent to an Alabaster Ghast. (I'm interested in clarifying all these rules, since I'm trying to code this game in time for Halloween.)
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?
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.
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 screaming.) 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).
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.
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.
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.
25 comments displayed
Permalink to the exact comments currently displayed.