Date:	1994-02-23
		From:	John
		Subject:	Continuing Progress

YES! We ARE making progress. Here is a summary of the points we have agreed on in our last two exchanges:

• Rangers should not be allowed to jump from airborne helicopters.
• The Closeup View window should NOT be modal.
• We will treat refueling like an attack, that is, allow only two 10-unit fuel transfers per turn, a full 20-unit refueling would prevent further movement for that turn, etc.
• Automatic attack. If the lead piece of an attachment clump attacks, all (offensively-capable) attached pieces automatically attack as well. (I added "offensively-capable" because I don't think the Corps of Engineers, for example, should automatically attack.)
• We will settle for a maximum of TWO grids: surface and air.
• Naming conventions: "Battle Map," "Closeup View," and "World Thumbnail."
• One spy "attack" must be on either the air or the land grid, not both.

• Enemy cities must go through two state transitions to become friendly cities.
• Armies can NOT occupy neutral cities, and will automatically capture as before.
• Other land pieces (and grounded helicopters) CAN occupy a neutral city (but only an army can capture a city). An occupied neutral city will appear on the battle map as a neutral city with some kind of indicator (see below).
• We are now agreed that helicopters and planes don't attach.
• Bombers should be restricted to one type of cargo at a time.
• An airborne spy can only attack ground pieces when it's directly overhead. The reverse is also true: a spy on the ground only attacks planes directly above it. We *SEEM* to be in agreement on the more general case, that all "intra-level" attacks must take place between pieces directly above/below each other. True? Are we also in agreement to the even more general principle the an airspace is adjacent (for all purposes including movement, attack, and visibility) to only one land space, the space directly beneath it?
• We also *seem* to have reached an agreement that attachment provides concealment even in closeup view. A sub attached to a carrier cannot be seen by an overflying fighter, but an unattached sub could be.

One question: should the enemy be shown this indicator on the battle map in cases where all our pieces in a single square are attached? Given our principle that attachment provides concealment, the enemy could not see which pieces were attached even in closeup view, but he COULD be told that there ARE pieces attached. Such an indicator would allow the enemy to distinguish, for example, between an empty troop transport and a non-empty troop transport. What do you think?

You say that you "now understand [my] proposal that visibility on the Battle Map is keyed to the currently selected piece." Does this mean you favor this solution?

You raise the idea of imposing a penalty for attaching and detaching pieces. I have also considered this, but my instinct is that the nuisance of popping in and out of closeup view is penalty enough. I propose that we table this idea for now until we see how some of the more fundamental issues (i.e. containment) shake out.

Our primary disagreement at this point seems to revolve around the issue of containment. We have discussed this before but I am quite willing to repeat (and refine) my position. Indeed, I agree that containment has a certain natural appeal. It's all the worms inside that container that trouble me.

First let me respond to another issue that you pulled into the larger dispute over containment. You now retract your argument that attached pieces should be forced to share their allotment of attack units and say you *meant* CONTAINED pieces. But I'm afraid my objection still stands. In your previous letter you included the following examples:

A spy attached to a full-power destroyer could attack twice per turn, but attached to a weakened destroyer might be allowed only one attack. If the bomber in your example carried fuel, paratroopers, bombs, and spies, it could still "activate" only two cargoes per turn. If it dropped a bomb and dropped a paratrooper it could not also support a spy attack that turn.

This strikes me as a highly unnatural and annoying limitation. Why should it take FOUR DAYS to unload a planeload of rangers? Even if our plane drops only two rangers, by your reasoning the plane would have to remain hovering for another day before it could return to base. These limitations make rangers almost unusuable. The further we extend the logic of your restriction, the worse things get. If it takes four days to unload 8 rangers from their bomber container, shouldn't it also take four days to unload 8 troops from a troop transport?

Even in more "classic" forms of attack this rule seems wrong-headed. Are you saying that because fighters are "contained" on a carrier, only two fighters can attack per turn? Forgive me, but this idea just plain doesn't work. This is not to say that containment per se is unworkable, just that the idea of trying to reduce the behavior of all contained pieces to the behavior of a single entity does not work. Please concede this point so that we can move on to the real issue.

You offer the opinion that containment provides a natural explantion for the fact that destroying a bomber also destroys the rangers within and add that attachment lacks this clarity because destroying a fighter does not destroy an attached fighter. While I agree that containment does provide an explanation I think attachment ALSO provides a natural explanation. When a bomber is destroyed the attached land pieces (rangers, fuel, etc.) suddenly find themselves in mid air unattached to anything that can fly. By definition, land pieces cannot exist unprotected in sea or air. Thus, they too are destroyed. This seems perfectly natural to me and also explains why a fighter attached to that bomber would survive. Again, this is not an argument against containers, but a defense against the notion that containment provides a clarity that attachment does not.

What, then, are my arguments against containment. First of all, I remain concerned about the problem of nested containment. You now flatly state that you are "*not* interested in multiple levels of containment." But is this problem really so easy to dismiss?

I presume you would agree that a helicopter carrying two infantry units is a container. I presume you would also agree that a carrier carrying a helicopter is also a container. What, then, happens when the helicopter container lands on the carrier container. Do we not then have nested containers? If not, do the infantry units somehow automatically disembark and become contents of the carrier? Can a carrier carry land pieces without a helicopter present? How are these changing relationships shown? Can the helicopter leave the infantry behind? If not, why not? If so, how would the user specify what should be contained in what?

Because attachment, unlike containment, is not inherently recursive, it avoids all these problems while still providing all the functionality we need in simple way.

You now agree that the visual representation of containment "is a big problem." Your suggestion of adding dotted lines around contained (as opposed to attached) pieces is interesting, but would, I think, prove difficult to implement and be confusing to the player. Remember that in each square of the closeup view we are working with shifting clumps of pieces in a very tight space. As players moved pieces in and out of clumps these outlines would have to be instantly reformed in a myriad of possible shapes. If containers can be attached (and I presume they can) you might have to outline the first two pieces of one row, then the last piece of the first row with a line or loop leading to the first piece of the second row, etc. In short: a mess.

I guess my fundamental objection is that it's bad enough that we have to distinguish between cohabitation and attachment. Having to distinguish between cohabitation and attachment AND containment is far worse and should be avoided unless absolutely necessary.

Although containment does seem a more natural way to think of certain relationships than the broader concept of attachment, the bottom line is that containment doesn't seem to give us anything that attachment does not. And given the problems with nesting and the BIG problem of representing this extra distinction, I choose the simpler approach. If you can find a way of handling containment in a way that simplifies rather than complicates, you can still win me over. Indeed, I wish you could.

One final note. I am very excited by the progress you are making with Alex. I was a little too hasty, though, in my full approval of the current world thumbnail. I notice that you have drawn it as a window, not as a floating palette. As I mentioned before, the floating palette is distinguished by the light gray, half-height titlebar shown in my mockup. It's essential property is that, unlike an ordinary window, it ALWAYS "floats" to the top of the window pile. In your current implementation, once I click on and select the battle map window, the world thumbnail vanishes beneath it and is then difficult to retrieve. Regardless of what window is currently selected, the world thumbnail should always remain in view (unless it's put away). There are standards defined for this sort of thing and, I presume, pre-defined code somewhere.

THERE! Another late night but we really are making remarkable progress. I think a few more exchanges and we will reach a new plateau of understanding in our seemingly endless ascent of mount Alex.

Yours in haste,

Epicurious J.