Date:	1994-02-22
		From:	John
		Subject:	3D World

Thanks for the detailed response - I think we're really cooking here! The number of unresolved issues and open questions indicates that we have yet to nail down a firm understanding of how our interface will work. Here are my responses to your responses:

You say, "...the enemy can see only four pieces...either a carrier or another fighter (depending on whether his currently selected piece...)." I don't follow you; why is this? I think he sees *both* the carrier and the fighter, as they're not attached.

I was referring to the enemy's view from the Battle Map. Each grid on the Battle Map can only hold a single piece so the enemy can only see one piece regardless of what is attached to what. I thought we had agreed on a distinction between attachment and cohabitation. A quote from my e-mail of January 28, 1994:

"As I understand it, our current thinking is that whenever pieces share the same square a fixed heirarchy 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."

Is this correct? If not, how would you propose displaying multiple pieces in the same square of the Battle Map? (See below for a discussion of displaying air vs. surface grids.)

What the enemy sees in the CLOSEUP VIEW is another matter. Here we could, as you suggest, hide only attached pieces and expose all unattached pieces sharing the same square. This would provide another motive for attachment, but it may compel players to constantly attach and detach pieces in order to gain that extra measure of concealment even when the pieces in question are not travelling together but only momentarily sharing the same space. This is an important issue which has not yet been resolved to my satisfaction.

The particular case in point here, however, is of a slighty different nature. The spy plane, of course, is not only not attached to the carrier, it is airborne and thus appears in the separate air grid. I agree with you that IN THE CLOSEUP VIEW the enemy should see both the carrier and the fighter: the carrier on the surface grid and the fighter (though not the spy) on the air grid. Indeed this is one of the primary functions of the closeup view: to clarify the distinction between surface and air pieces.

The unresolved issue is whether the enemy can see the submarine which occupies the same surface square as the carrier but which is NOT attached to the carrier. Of course, this issue is further complicated by the submarine's camouflage property, but even so: if an enemy fighter were to destroy our spyplane and fly into the air square directly over our carrier, would it see the sub? Would it see the sub if the sub WAS attached to the carrier?

[Note that the separation of air and surface now means that a fighter does not have to automatically attack a sub when it flies over it. This is one of many new behaviors that emerge when we distinguish between surface and air.]

Also, I don't understand the point about the "currently selected piece". Surely selecting a piece (presumably to move or view it?) has nothing to do with what enemy pieces are visible. Please elucidate...

I am referring to an idea I proposed some time ago on a tape. We have yet to resolve the problem of what to display on the Battle Map when an air piece is flying over a surface piece. You nixed the idea of an alternate blinking display. My proposal was that if the current selected piece was an air piece, all overflying air pieces would be displayed, while if the currently selected piece was a land piece all underlying land pieces would be displayed instead. I recognize that this is not a perfect solution, but it would avoid blinking and at least when you selected a fighter on the battle map you would immediately see all airborne enemy fighters without having to resort to the closeup view. Similarly, when you select a ground piece you would immediately see all opposing ground pieces, not the planes which happen to flying overhead. If this scheme were accepted, ON THE BATTLE MAP the enemy would see either the carrier or the fighter depending on whether he was currently moving an air piece or a surface piece. Again, this is not a perfect solution, but if you have a better one I'm all ears.

I support what I believe to be your current position that one spy "attack" must be on either the air or the land grid, not both. What is not explained is the attack relationship between the spy and his host. Does the spy attack also consume one host attack? If the spy attacks twice this turn can the plane also attack? My proposal: The host plus all its attached pieces are allowed exactly as many attacks as the unencumbered host would otherwise be allowed.

I'm afraid I must completely disagree with this last proposal. Are you saying that a stack of eight armies can only fire TWO shots per turn if they are attached, but could fire SIXTEEN shots if they occupied the same square but were unattached? Only two rangers can jump per turn (and so it takes FOUR DAYS for a planeload of rangers to jump)? This is such a severe penalty that it would make attachment all but useless. Attachment originally evolved as a refinement of the current Conquest's stack move, yet Conquest imposed no such penalty and if it did I dare say no one would use it. The whole point of moving multiple fighting units is to combine and focus their strength, not to reduce it. Bottom line: if you stop attached pieces from fighting, players will not bother to attach in the first place.

Why can't the spy spy on the battleship? Are you implying some rule about "clearing out" the grid a piece is in (air or land) before being allowed to switch grids?

At issue here is what is adjacent to what when an air piece "attacks" a surface piece. I am proposing that in order for an air piece to attack a surface piece (or vice versa), the air piece must first move DIRECTLY OVER the surface piece. In the situation depicted in my mockup, the spyplane cannot move directly over the battleship because the airspace above that battleship is already occupied by an enemy fighter. Thus the spyplane must first attack and destroy the enemy fighter. When this is accomplished, the splyplane will wind up directly over the battleship; the spy is then "adjacent" to the battleship and may attack (probe) it.

Our problem is that we're still used to thinking in terms of the flat world of Conquest. If we distinguish between air and surface (as I believe we must) the rules of engagement and adjacency are changed. These new rules provide a "truer" form of "air cover" - the enemy fighter really does protect its battleship from air attack. I think this is the correct way to define 3 dimensional engagement but there may be other ramifications that haven't yet occured to either of us.

Can air pieces only SEE surface pieces beneath them, or can they see surface pieces beneath all eight adjacent air spaces? The simplest answer is that for all purposes every position in Alexander is adjacent to NINE other positions: the eight positions which surround it on the surface/air grid, and the ONE additional position above/below it.

I propose that an army be allowed to occupy, as opposed to attack and capture, a neutral city.

I think instead that (if we allow occupying at all) we should go with the proposal you made on the last tape. To wit, when we fire the shot that defeats an enemy city, instead of automatically capturing the city, that city reverts to its neutral status. It then takes one more attack (by an army) to capture the city. Under this scheme there would no longer be any reason for an army to occupy a city. When an army captures a city it "turns into" a city marker and defends the underlying neutral city with the same strength as would a single army occupying that neutral city. It would make no difference whatsoever from a defensive standpoint; the only difference would be that an occupied city could not produce anything or provide harbour for ships and planes. Thus no player would ever choose to occupy a neutral city with an army. This is a cleaner solution and would save us from further complicating the interface by forcing every victorious army to choose between occupation and capture. It also means that an infantry unit can defeat an enemy city and help hold it until an army arrives.

I rather like this idea of occupying cities, but there is still one issue that troubles me. When a helicopter or land piece (other than an army) occupies a neutral city, what appears on the battle map? If the topmost piece appears the neutral city is concealed from enemy eyes - I think this would be too potent a weapon. The alternative is that the neutral city would conceal whatever defenders were occupying it - at least on the battle map. I suppose the defenders would be revealed in the closeup view. Acceptable?

Can a chopper attach to a fighter? This revives the earlier discussion around the definition of "attach", which was not resolved to my satisfaction. Attaching a bomb to a bomber is very different from attaching, say, two fighters. In this context, I guess the question becomes, "Can the chopper and fighter move as a unit, and can the fighter hide and protect the chopper?" To answer the first part, I'm inclined to fall back on "real life". Can fighter planes slow down to the speed of helicopters? If so, I would answer "yes" to that part of the question. Responding to the specific initial question, "I don't know" is the best I can do at the moment.

Like you, I'm inclined to fall back on "real life" in this case. To me, it seems unnatural that a fighter, typically streaking over the countryside at Mach 2, could or would defend a nearly stationary helicopter. My inclination would be to say that a helicopter CANNOT attach to a fighter (though they may of course temporarily share the same air space).

Your representation of the fighter-bomber-fuel-ranger-bomb attachment is unsatisfactory to me. It faithfully depicts the attachment, although "upper-left-hand-corner piece is on top, attachment-wise" is not very intuitive, but it doesn't address "containment" at all. I know that the rangers are inside the bomber rather than inside the fuel (don't laugh) only by referring to the piece matrix, or some other documentation. I think we can do better than this.

My current understanding is that we do NOT recognize "containment" as distinct from attachment. I agree that this leads to some odd situations (in fact that is precisely why I included that heavily-laden bomber in my mockup) but I don't think any truly ambiguous situations arise. I think our players will be bright enough to deduce that the ranger is inside the bomber, not inside the fuel. Indeed, there is no such thing as "inside" in the first place.

If you really want to pursue the concept of containment as opposed to attachment as opposed to cohabitation I am completely open, but I fear you would be opening a can of worms. Containment implies a kind of nesting relationship that further complicates our already burdened interface. You say "we can do better than this." By all means: enlighten me!

How about if we treat refueling like a modified attack? One barrel would be, say, 10 fuel units, so a complete refueling would "stop" both bomber and fighter for the turn - no more movement, no attacks, no dropping paratroopers, etc.

Sounds good to me. I still wonder, though, if we should allow one bomber to simultaneously carry fuel, rangers, and bombs: it seems "unnatural." Should we restrict a bomber to one type of cargo at a time?

In a recent note I kind of proposed extending this concept even farther, making as many as four grids: air, land, sea, and undersea... I like some of the features that this makes possible, e.g., subs having to surface to enter port or - maybe - attack planes.

I see no reason to have more than two grids, surface and air. The subtle distinction between surface ships and a single type of piece (submarines) in no way justifies the enormous extra interface burden of an "undersea grid." And I see no reason whatsoever to have separate land and sea grids. Land and sea are mutually exclusive. There is simply no need for separate grids when the two elements NEVER overlap. No, two grids is all the trouble we need!

We definitely need to distinguish visually between the various city states in the closeup view.

Agreed. How?

I think scrolling of the closeup view is a nice, but maybe not necessary, feature. I'd rather not make this window modal.

I agree. I wonder how heavily this closeup view will be used. I'm beginning to fear that players will need to spend more of their time in the closeup view than in the battle map.

I could start playing around with firing globs rather than single sparks any old time. Do you have any specific ideas?

Instead of 20 sparks, try 10 clumps of 16 (4x4) sparks. In other words, choose ten random positions and set a 4x4 block around that position to land. You might also try randomly varying the size of the clump from 2x2 up to 5x5. Now that we have the world view window we can quickly evaluate the results!

Is the [world] window style right for you?

Yes.

What should I do in the way of menus?

I suggest a Views menu with two checkable items, battle map and world thumbnail (and someday maybe a closeup view). The user could select either or both; I guess you should allow the user to turn off both displays as well, though he won't be able to see anything until he turns at least one of them back on. I don't see a need for a "New Window."

A new alternative popped in my mind today: "World thumbnail" in place of "World View". What do you think?

Sounds good. On proviso. If we decide to add a button which doubles the size of the world thumbnail (to 4 pixels per position) than we should go back to calling it world view. The larger world view (and the switching capability) would disqualify it as a "thumbnail."

WHEW! Hope this makes it across the ether in one piece. It would seem time is ripe for another summit. In any event we need to do more thinking about the ramifications of a three dimensional game, both on the tape and in subsequent correspondance. I am particulary eager to settle the matter of what is adjacent to what. I look forward to your ever-more detailed response!

Yours in haste,

Epicurious J.