Jupiter (Revised)

Ten years have passed since I submitted the game of Jupiter, planning to finish it off relatively quickly. It was not to be. I was never able to complete the Zillions implementation of it, because Zillions kept crashing when I put too many pieces in a file. I got busy with other things, and forgot about Jupiter.

A few months ago, the disk in my laptop died. It took some scrounging to round up all my old files (the backup disk died too!), but when I finally had them all assembled, I looked through them and found some of the Zillions files I had worked on a decade earlier. That reminded me to submit some changes I had made in the meantime to Scirocco and Typhoon, and I made another attempt at finishing the ZRF for Jupiter.

Alas, Zillions still couldn't digest the entire set of Jupiter pieces (although I did feed it enough to make Zillions run really slowly). The screenshot above shows what the board would look like in Zillions, if Zillions could play Jupiter.

However, in the course of attempting to make the Jupiter ZRF work, I did realize I needed to revise the moves of some of the pieces (either because they were unclear, or because they were too difficult to describe to Zillions).

The changes are:

• The changed movements of the Cicada, Dervish, Harpy, Missionary, Salamander, Sorcerer, and Typhoon, as incorporated into the revised games of Scirocco and Typhoon;
• Clarifications on the moves of the Doubler and Halmopper;
• Removal of the ability of the Ox Tank and Dragon Tank to capture friendly pieces; and
• A completely new move for the Teleporter, whose old move was easy for a human being to visualize but very difficult for Zillions.

This file describes only the revisions made from the original, rather than restating the complete rules for Jupiter, which would probably overflow the member-submitted-description form.

Setup

The Jupiter setup remains basically the same, but adopting the new setup conventions for Typhoon: that is, Blue first chooses the overall symmetry of the initial array by placing the Kings and Commoners, and then Tan decides how to place each pair of pieces.

Pieces

Here is the revised table with the summaries of piece movements:

Rules

The basic rules are mostly unchanged from the original, but some additional cases came to my attention when I was attempting to implement the new ZRF:

• Doubler and promotion: If a piece is eligible to promote after the first part of its move, it may take the second part of its move without promoting, as usual, or it may promote and then move again as the piece that results from the promotion. If a piece moves out of the promotion zone without promoting on its first part, it does not have the option to promote on the second part unless it moves back into the promotion zone.

• Halmopper and latent effects: The Halmopper is immune to poison, burning, and immobilization on any of its intermediate destination squares; these effects apply only to the final arrival square. Doubling has an effect only if the Halmopper chooses a nonhopping move as its first step, or makes a capturing hopping move on its first step (otherwise the Halmopper is already making a move of at least two parts).

• Doubler and Lion-type pieces: Pieces modeled on the Chu Shogi Lion have what looks like a two-step move, so you might think the Doubler would have no effect on them. However, the Doubler does double them: a Lion-type piece that could normally capture up to two pieces in one move can capture up to four when doubled.

• Tanks and promotion: As in other cases when a piece is not moving under its own power, a piece pushed by an Ox Tank or Dragon Tank cannot promote, even when moved into or out of the promotion zone. The Tank itself may promote according to the usual rules when making a pushing move.

• Tanks and immobilization: An Ox Tank or Dragon Tank may push an immobilized piece.

• Burning and poison: Burning and poison are in fact the same effect, but the term poison is usually applied to squares containing a piece, while burning may also apply to an empty square. However, the following discussion uses the terms interchangeably.

  Fiery Dragons both capture adjacent opposing pieces by approach and burn (or poison) adjacent squares.

  In detail, a Fiery Dragon (say, Blue) landing next to an opposing Fiery Dragon (say, Tan) works as follows:

  1. On Blue's turn, the Blue FiD immediately captures all Tan pieces surrounding its destination (this is a capture by approach, not a poisoning). However, the Blue FiD does not immediately remove the poison applied by the just-captured Tan FiD to the squares surrounding itself.
  2. Poison is then activated on all squares where it is present; this removes the Blue FiD.
  3. Finally, before Tan's turn, poison is recalculated on all squares. Assuming there is no other source of poison in the vicinity, this leaves the squares around the former locations of the FiDs poison-free.

• Relaying and burning: Because the Fiery Dragon's initial captures are captures by approach than poisoning, a Fiery Dragon moving with a relayed power rather than its own does not immediately capture adjacent opposing pieces. Assume, for a example, that a Blue Harpy relays a Knight's move to a Blue Fiery Dragon:
  1. The Blue FiD arrives at its destination. Adjacent Tan pieces are not captured.
  2. If the FiD is poisoned (e.g., lands on a Tan Deadly Nightshade or next to the Tan FiD), it is captured before it has a chance to poison adjacent squares (the poison-activation phase occurs before the poison-laying phase). If not poisoned, the Blue FiD lays down poison before Tan's turn, but the poison is not activated yet.
  3. On Tan's following turn, adjacent Tan pieces have a chance to move away from the Blue FiD and escape poisoning.
  4. At the end of Tan's turn (even if Tan captured the Blue FiD), the Blue FiD's poison is activated, and any Tan pieces remaining in the squares the Blue FiD poisoned are removed.

• Optional captures: As in the revision of Typhoon, I've made it so that pieces that capture by some means other than displacement no longer have the option not to capture when they make a move that could capture. It seemed to me that you would choose a noncapturing move so infrequently that it was not worthwhile cluttering the rules by mentioning the possibility of not capturing.

Notes

From the behavior of the partial Jupiter implementations I've made, I'm guessing a typical game of Jupiter would take somewhere between 200 and 500 moves.

Still, I think it would take less time to play Jupiter than it has taken to implement Jupiter.