Date:	1994-01-28
		From:	John
		Subject:	Piece Movement & Design

In the last day or so I've had an avalanche of ideas about how to render the Alex pieces, how to attach and detach them, etc. The first tangible result is the poster (stuffed PICT file) included here.

It offers three styles of pieces and seven ways to play the game. Here's what I'm proposing:

We have talked on and off about allowing more than two players. I would very much like to allow three players (so that you and I and Lawrencium could play, for example) but it seems to me that any more than that would make the game FAR too tedious - I suspect three is the practical limit. Actually the current game already has three players if you count the Neutral Cities as a third player (of course the Neutral is like the dummy in bridge - it is present but never really plays).

Meanwhile, my experiments with piece design seemed to be converging on three basic "substances": stone, wood, and steel. I therefore choose to view this convergence of threes as a good omen and an indication we should structure the game in a three player format. The third player can be either neutral or not and the other players can be either humans or programs. Each of the three players is assigned a different piece type (stone, wood, or steel).

As you can see by the poster, this yields seven possible ways to play. The simplest form would be human vs. computer with neutral cities. Eventually I would like to offer a small set of different canned programs from which to choose. Thus you could choose a bumbling computer opponent, an aggressive one, a cautious one, etc. Or you could design and store your own programs. A human player could simultaneously oppose two different programs, two programs could battle each other with a pre-existing set of neutral cities, etc.

At the outset of the game the player(s) would first choose which of the seven forms they wished to play and would then assign a piece style to each player. Typically the human player might choose stone pieces for himself, wood for the computer, and steel for the neutral cities.

My current thinking is that I would have to provide a total of eighteen (!) variations on each piece. All the mobile pieces need both a left-facing and right-facing orientation. The pieces will come in either stone, wood, or steel. And each piece will need three different display modes: resting, active (not yet moved), and selected (when the user clicks on a particular piece or shift-clicks on a set of pieces). 2 orientations times 3 styles times 3 display modes yields 18 variations. I am also thinking that the pertinent dialog boxes should come in three styles as well (stone, wood, and steel).

I further propose that a slight distinction be made between mobile and immobile pieces. I'd like to try representing cities and other mobile pieces as "flat" squares as opposed to the raised beveled mobile pieces. Sometime soon I will try to come up with a chart showing all 18 variations. Eventually I can ship them all to you as individual PICT resources if you so desire.

I've also been thinking about the simplest way to let players attach and detach groups of pieces. As I understand it, our current thinking is that whenever pieces share the same square a fixed heirachy determines which piece is on top. The piece on top protects and conceals the pieces beneath. In addition, pieces can be attached to other pieces (as allowed by the attachment matrix) for the purpose of automated movement. Once a set of pieces are attached the player need only move the top, or lead piece and the others will follow along automatically. The whole group moves at the speed of its slowest member.

The problem then is to provide an easy way for the player to form and reform these attached groups. Our basic approach is that whenever a player doubleclicks on a piece (or piece stack) a special window opens showing a magnified and somewhat abstract view of the piece's square with it's eight surrounding surface squares (either land or sea) and also the airspace with eight surrounding air squares - a total of 18 squares. Each of these magnified squares should be big enough to easily accomodate the limit of nine pieces. (Incidentally, I wonder if we should limit airspace to, say, four simultaneous pieces instead of nine - what do you think?)

It's important to keep in mind, by the way, that the approach described here requires that our limit apply to ALL pieces whether or not they are attached. Thus, if a submarine is attached to a carrier, that carrier can only hold seven, not eight fighters. A bomber with two bombs aboard could only have a single fighter escort, etc. If a player attempts to drag a tenth piece into square already occupied by nine pieces the computer would beep and disallow the move.

Now then, as we have discussed, attaching and detaching groups and subgroups can get rather complicated, especially if several independent groups happen to wander into the same square. My proposal is this. Once the player has doubleclicked and is presented with the 18 square magnifed map, he can attach two pieces by simply dragging one right up against the other. When pieces are attached they will actually stick to each other (that is, they will be positioned directly next to each other. Whenever two pieces occupy the same square but are not attached they will be positioned with a certain amount of dead space between them. Thus a player can tell at a glance who is attached to who and can pull a single piece out of a group by simply dragging it to one side (but still withing the central magnified square). Because of the beveled look of the pieces this affect will be attractive and easy to grasp.

If the player doubleclicks on a isolated piece in the main battle window OR if he doubleclicks on any cohabitating piece in the magnified view window, an information box will open for that piece. A pop-up menu in that info box should indicate current movement status (either manual, programmed, or attached). Thus an alternative method of detaching a single piece would be to summon its info box and then change the movement status from attached to manual.

An example: suppose you have a port city with one transport and five armies. When you doubleclick on the city you will see a magnified view with all six pieces scattered about in the central square (none of them touching). To load four of the five armies onto the transport, simply drag each army right up against the transport. When they get close enough they will stick to each other like magnets, eventually forming a clump with three in the first row and two in the second. Once the clump is formed you simply drag any one of the pieces into an adjoining sea square and the voyage is underway.

While at sea, you move a submarine into the same square as the transport. Upon doubleclicking you see the transport and four armies still clumped together and the submarine sitting to one side. If you wish to attach the submarine as a silent escort, simply drag it next to the transport clump. If you move a fighter into the same square and doubleclick it will appear in the separate air grid. A fighter could be programmed to follow a transport (within fuel limits) but cannot ATTACH to a transport. The interface will make this obvious by placing the fighter on the separate air grid.

Finally, when you reach a new continent, simply doubleclick and drag the transport (and sub) away from the clump (but still within the central square. You can then move the four armies ashore with a single movement. OR you could simply drag a single army ashore and leave the rest of the clump in tact. If some infantry units are already waiting on shore you can simultaneously offload the armies attach them to the infantry (or not) with one simple sweep of the mouse. You can leave the sub attached to the transport or not, as you wish.

What do you think? At some point I will try to put together a hypercard mockup; I think it will be much easier to demonstrate this method than it is to explain it in words. My guess is that this method will be very flexible and very intuitive at the same time.

I hope that the tape will arrive this Saturday. Perhaps you can record your reaction to all of this.

Yours in haste,

Epicurious