Bucky:Java implementation

From Carls wiki

1 Data model

Data model

State, Board and Spirit

Position, Player, GameItem and Piece

State and Move

A State object encapsulates all the necessary (and unnecessary) information at a certain point in the game. A Move object is used for describing atomic transitions between states.

From the looks of it right now, we're not going to implement a separate canMakeMove() method as we originally planned, since this will likely be identical to the makeMove method in all aspects, save for the return type.

Simulated boards

Oki, we've thought a bit. It seems that we have to revise the whole way we test for legal moves, since it is nontrivial whether a moving piece becomes doubly hypnotized by an arbritarily long chain of events ocurring because of the move. In essence, any algorithm which tests whether an arbritary move in a given board situation is legal or not will (more or less) have to simulate the move, after testing the bare necessities of legal movement types etc.

It suddenly seems that every move will have to be simulated unless it is clear that no double hypnosis is involved. This, we believe, is a good thing. We separate the movement validation phase from the hypnosis validation phase. This also ought to solve the revenge dilemma nicely.

c3-c4(xe5,e6,c4) is an illegal move, but how can we see it without simulating it?

Another reason this is a good idea:

c1-c3 is not allowed either

Double moves are not as simple as we thought, once again because of those pesky chameleons.

Update: This is much worse than we thought. Now we really need simulated boards. Look at this:

Situation I: Holy smokes! The white chameleon does c1-c3(xf7) by escaping from indirect hypnosis through its indirect vengefulness/enthusiasm, killing of an opponent chameleon in the process! Yowza!

Also, we're a bit unsure about this one...

Situation II: Same move, c1-c3(xf7), but now the double hypnosis is made during the intermediate step (b2) in the eager move, but not in the resulting position. Does that count?

Update: During lunch, we just couldn't stop ourselves, and made up two more variations on the theme. Here they are.

Situation III: We have agreed to make this move (c1-c3(xc3)) illegal.

Situation IV: A black jedi at d3. Same thinking as in situation II, but we also need to make sure that the jedi cannot do an en passant (d3-c2(xc3)) in the next move.

Equilibrium

Define equilibrium as something a state can be in, namely when no piece is standing in double hypnosis. All valid states are in equilibrium. In order to reach equilibrium, one must remove pieces, but removing all doubly hypnotized pieces isn't enough, since this procedure sometimes uncovers other pieces which might then become doubly hypnotized. The effect created by this iterative removal is called cascading.

In the above board position, white is to move. The move h7-h8(S)(x...) will result in a cascade of double hypnoses which removes all pieces on the board except the promoted shaman. The cascading will consist of six steps — it is conjectured that there can never be more than eight steps in a cascade.

Move and Movement

The classes Move and Movement are two altogether different beasts. Moves transform one state into another, while movements are filters for allowed piece repositionings across the board.

Move and Notation

When creating a new Move object, the standard way to do it is through a Notation factory method. This for two reasons: we don't want to tie one notation irrevocably into the core of the game, and further, we want the selection of the correct Move subclass to be made for us. This is exactly what the Notation interface does.

Server, Client and Monolithic

This being a large project already, we will start by fully implementing Monolithic first.

However, we do have a few nice ideas about the message-passing between the client and the server. If they could pass proofs between each other, they could pinpoint possible disagreements to a much higher degree — they would still not agree, but they would disagree at a sometimes much smaller scale.