In 1993, Paul and I started experimenting with expanding and generalizing the concept of attachment. This idea suggested exciting new possibilities, but also raised some difficult questions about distinguishing being in something from being over or under or near.

Part one of this page consists of a Word document I authored proposing an "attachment matrix." Part two presents the initial refinements triggered by this proposal. Part three is a more in-depth proposal for how to represent these relationships in the interface. And Part four captures the vigorous discussion which followed. Attachment turned out to be a real can of worms.

Attachment Matrix

Notice that not all relationships are symmetrical. For example, an artillery piece can attach to an army, but not visa versa. Since a piece covers any pieces attached to it, this means that when an army/artillery group share a square, the enemy will see the army piece only. When symmetrical relationships exist, the player can determine which piece is "on top." Thus, if a spy and a paratrooper share the same square, the player is free to choose which piece covers the other.

Some details about attachment are still unclear. To what extent, for example, does a piece take on the properties of the piece it is attached to. The paratrooper has the property of camouflage, that is, it cannot be seen until it attacks, or until the enemy attacks it by inadvertently attempting to occupy the same square. If a spy attaches itself to a paratrooper, is it also rendered invisible? I think it should be, and this is one of the reasons that the current attachment matrix forbids any other piece from attaching to the paratrooper. If we were to allow the engineer to attach to a paratrooper, would this mean that the engineer could also jump out of air transports?

Some pieces are allowed to attach to themselves; this is the equivalent of the block move in Conquest. One question is whether a bomb should be allowed to attach to itself as a method of increasing its destructive radius. Thus, instead of following Conquest's method in which bombs slowly increase in radius and production time as the game progresses, we could instead make all bombs constant (20 days, radius 1), but give players the option of "fusing" two bombs (or more) to make a single bomb with greater radius.

Other questions arise in connection with the fighter. The current matrix allows an air transport to attach itself to a fighter for protection; the enemy would only see the fighter and would have to shoot it down to get at the air transport. Should players be allowed to do the reverse, attach a fighter to an air transport? (Offhand, I don't see why anyone would want to do this.) And should fighters be allowed to attached to themselves (in "tight formation")? If so, this would allow mulitple fighters to protect the same air transport.

Antiaircraft guns and radar installations were originally conceived as immobile pieces which could only exist in the city which created them. The question marks at the bottom of the chart raise the possibility of assembling either of these pieces in a seaside city and towing them to any shoreline square using the transport ship.

You will notice that the current matrix allows submarines to be attached to any other naval piece except the destroyer (which moves too fast for a sub). The idea here is that a sub could be placed under a surface ship for added protection. An attached sub would follow along without additional intervention until enemy contact. Although somewhat counter-intuitive, a simple implementation would dictate that a transport with attached sub could hold only seven other pieces because the sub takes up one of the eight available slots.

It is tempting to automate the process of escorting by allowing all naval pieces to attach to each other in spite of the fact that (except for the submarine) they cannot occupy the same square. Upon further reflection, however, I feel that a more appropriate mechanism for automatic naval escort is the patrol. Any mobile piece can be assigned a patrol path which begins and ends at a given location. I propose that patrol paths can also begin and end next to another piece. Thus, as the piece moves, the patrol path (and any pieces on that path) move with it. This mechanism would allow destroyers to scout ahead of transports and fighters to buzz around moving carriers without additional intervention.

The relationships shown in this initial attachment matrix are still in their infancy and will certainly continue to evolve. Please review the chart and respond with objections, suggestions, and further enhancements.

Initial Refinements

Attachment Hierarchy

But upon further reflection I think it might be better (and much simpler) to provide a fixed heirarchy. Most of the pieces, as currently defined, already follow a heirarchy. A heirarchy is imposed whenever A can attach to B but B cannot attach to A. Thus engineers can attach to armies but not the other way around. This means that armies are always on top of (and so conceal and protect) engineers.

Here is my initial proposal for a fixed heirarchy among land pieces:

1. Infantry
2. Army
3. Artillery
4. Engineer
5. Ranger
6. Spy

Hovering Vs. Landing

There are a number of undecided issues here. How can we draw these distinctions without imposing a burden on the player? The distinction implies that air pieces become land pieces when refueling or (in the case of the helicopter) picking up troops. How is this indicated on the display screen? Perhaps a grounded helicopter should cover all land pieces in its square, but protect them with zero strength.

Parachuting

During the enemy's subsequent turn, the ranger will be visible to any piece that moves adjacent to it; if attacked at this point the ranger will defend with half strength. During the players next turn the ranger is free to move like any other piece and from that point on it is invisible to adjacent enemy pieces (until it attacks) and defends at full strength.

Can Ships Sail Under Bridges?

Some questions. First, how do we apply our limit of, say, nine pieces per square. Does this limit refer to all land, sea-surface, underwater, and air pieces combined? Is it nine pieces in each of the three (four?) elements (a total of 27 [36?] pieces allowed in this situation)? Do containers (such as a helicopter with an infantry unit or a submarine with a spy) count as 1 piece or as more than 1? What if some of the pieces belong to the enemy? If the sky is already buzzing with nine enemy fighters does this mean none of my fighters can lift off from my carrier?

And secondly, how in the hell do we portray this situation on the map?

Attaching and Detaching

The Concept

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.

The Mockup

In this scene, we are the slate pieces and are opposed by red plastic. The battle map shows a scene on the outskirts of a neutral port city. The main battle map shows our transport about to unload troops, our carrier with (non-escort) submarine beneath and spyplane overhead, and a downed helicopter refueling at a fuel dump just created by one of our engineers. We also have a heavily-laden bomber with one fighter escort and another fighter preparing for a mid-air refueling. We occupy only four squares, so the enemy can only see four pieces: a transport, a fighter, a downed helicopter, and either a carrier or a another fighter (depending on whether his currently selected piece is an air or surface piece).

We can only see three enemy pieces: a battleship, a fighter, and an infantry unit. The mockup shows what would be displayed if we double-click on our downed helicopter. The window shows the downed helicopter with the eight surface cells immediately adjacent to it, and also the airspace overhead with the eight air cells immediately adjacent to that. Double clicking on a piece in the closeup window brings up an info dialog box for that piece. Surface pieces can be dragged to other positions in the surface grid, air pieces can be dragged to positions within the air grid, and special pieces (like the helicopter and the ranger) can move from one grid to the other. We can perform a number of interesting activities within this one closeup view.

Our first decision is how best to use our spy. Like any other piece, the spy is allowed two attacks per turn. The enemy fighter is already adjacent to our spyplane, so the spy can "attack" the enemy fighter without the need to first move its fighter. If we select the spy and then click on the enemy fighter, any AIR pieces "underneath" that fighter will be revealed. It may be a lone fighter, or it may conceal a squadron of bombers.

We could also move the fighter one unit southeast into the airspace over the enemy infantry. The spy could then penetrate the infantry unit directly below it and determine what pieces it may be hiding. Notice that the spy cannot easily probe the enemy battleship because of the enemy fighter overhead. In order to probe the battleship, our spy would have to position himself over the battleship, but he can't do this unless his fighter first attacks and destroys the enemy fighter. In any event, with only one spy we can probe only two of the three enemy pieces during this move.

Unloading our transport is easy. We can drag any or all of the four land pieces onto any of the three adjacent land squares (although an infantry piece can occupy a neutral city, only an army can capture it). Once the city is captured, we can move the transport into the city as well.

Our carrier contains a helicopter which, in turn, contains a unit of infantry. If we wish to move that infantry on shore, we much drag the helicopter, NOT the infantry piece. A land piece cannot directly disembark from a carrier; but if we drag the helicopter to any land piece within ten units, the infantry will tag along automatically. Once the chopper is on the ground, the infantry can safely detach. I think even rangers should NOT be allowed to detach (jump) from helicopters that are in the air; I say they can only jump from bombers.

If we drag the helicopter to a sea square, it (and the infantry) will automatically pop up into the air grid. We can also drag the helicopter directly onto any of the nine air grids. This is unusual: most pieces cannot move from the air grid to the surface grid or vice versa. Of course, if we try to move the chopper into an occupied air grid, this would constitute an attack (and if the chopper is destroyed, the infantry is destroyed with it).

With an enemy battleship so close, it might be wise to move the chopper up into the air, but this might leave it vulnerable to the enemy fighter. If we move it straight up over the carrier, would our spyplane protect the chopper? And can a chopper attach to a fighter? In any case, we cannot move the helicopter into the lower right airspace square, because that airspace is already maxed out.

In this representation I have dropped the idea of a four piece limit for air pieces. Our heavily-laden bomber tests even a nine piece limit. As you can see it is carrying one bomb, two rangers, and three units of fuel. Should we allow bombers to carry all three types of cargo at once? If so, this particular plane is simultaneously a bomber, and air transport, and a mid-air refueler.

I presume mid-air refueling should require both the fuel-er and the fuel-ee to remain motionless for one turn, so if we wish to refuel the unattached fighter we much first attach him and then wait until the next turn. Could the rangers jump during a mid-air refueling? Once fueling is complete, our eight piece air clump can move ten units a day for many days.

We have a number of other options. We can attack the battleship with our sub, but we could also attach the sub to the carrier and then both carrier and sub could retreat together. If the sub had already been attached to the carrier, we would have had to detach it before we could use it to attack the battleship. If the sub WAS attached to the carrier, and if the carrier then attacks the battleship, what do you think should happen? In that case the carrier would fire the first shot. But would the attached sub AUTOMATICALLY fire a second shot, or would the player have to open up the closeup view and then specifically select the sub for a separate attack? I presently favor the automatic attack as this further enhances the power of attachment: not only do attached pieces automatically move together, they automatically fight together as well. The player would only need to detach the sub if he wanted the sub to fire FIRST.

We can also move the engineer and use it to attack the enemy infantry (NOT a good idea) or move into the neutral city. I propose that any land piece can effortlessly move into and thus "occupy" a neutral city; the enemy would have to destroy any occupying pieces before it could occupy OR capture a neutral city. Sea and air pieces (except the helicopter) could NOT land in a neutral city until it was captured and only armies can actually capture a neutral city.

There are many more issues raised by this scenario, but that is enough for now. What do you think of the twin surface and air grid approach? I think it solves several problems, both the sometimes complex forms of attachment, disembarking, refueling, etc., and also some of the issues you raised earlier about the distinction between air pieces on the ground and in the air. Under this scheme, when a player flys a fighter into a city, that fighter LANDS in the city and is a sitting duck for any enemy fighter that can fly into the airspace OVER the city. If the player anticipates an enemy air attack, he must expend an additional movement to send the fighter up into the city's airspace before his turn is over.

Several other unsolved issues...

How should we distinguish (visually) between neutral, captured, and enemy cities in the closeup view? I could simply display the city marker piece (for either captured or enemy cities), but would that take up one of the nine slots? (Actually, there is enough room to bump the limit up to 12 if we want.)

Should we provide a means for the player to scroll around the map from within the closeup view window? And if so, how? (One method would be simply dragging a piece to the edge of the window until it starts to scroll.) Should the closeup window be modal (that is, should the player be forced to put it away before returning to the main battle map), or should we allow the closeup window, the main battle window, and the floating world palette all to be active (and updating) at once (for those with football-sized screens)?

Is the concept of the twin-grid closeup window sufficiently clear? Are we comfortable with the strict (and sometimes counterintuitive) limit it places - by its very nature - on the number of pieces that can occupy a given square?

Discussion

Questions and Answers

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.

Paul's Issues

Your quoted mail of Jan. 28 is fine as far as it goes, but it doesn't seem to address the issue of multiple grids (right?).

The issue you raise about compelling players to constantly attach and detach pieces for concealment deserves serious attention. My first attempt at a solution: charge the piece for each attachment and probably for each detachment as well. So to hide, you have to stop a little sooner each turn. I think this will be a small penalty for long-term attachments, and maybe a large enough deterrent for willy-nilly use.

Can the enemy see a sub under a carrier? I don't have a strong opinion here. For consistency, I'll propose that subs are hidden when attached - just like all other pieces - and otherwise available for spotting.

What to display on the Battle Map when an enemy air piece is flying over an enemy ground piece? I now understand your proposal that visibility on the Battle Map is keyed to the currently selected piece. When combined with my current proposal to flag the co-location of other unspecified enemy pieces I think we can make a workable solution.

Our disagreement on attacks from attached pieces may be pretty fundamental. I believe this re-emphasizes our overuse of the term "attachment". What I *meant* to say in my last note is that "contained" pieces share attack units with their container piece. I'm very attracted intuitively to the concept that bombers contain bombs, or fuel, or rangers; transports contain troops, or whatever, etc. Containment also explains why destroying a bomber also destroys bombs, fuel, and rangers. Destroying a fighter does not, I presume, also destroy any other attached fighters. To me this seems like a very natural distinction. I think you earlier argued against containment; I don't remember why.

You argue that an airborne spy can only attack ground pieces when it's directly overhead. I assume the reverse is also true: a spy on the ground only attacks planes directly above it?

I've made two city-related proposals recently:

1. Enemy cities must go through two state transitions to become friendly cities.
2. Armies can occupy neutral cities.

What appears on the battle map for an occupied neutral city? I suggest the city plus my proposed asterisk-thingie to warn of more detail available on the Closeup view.

We are now agreed that helicopters and planes don't attach.

Your suggestion that bombers should be restricted to one type of cargo at a time sounds reasonable, I think.

I see that late in your note you mention one problem with containment: visual representation. I agree that this is a big problem, but is it your only significant objection? I think this is a hurdle we can overcome. I'm *not* interested in multiple levels of containment, by the way.

Containment thoughts: dragging a piece onto another eligible piece in Closeup view initiates containment. Contained pieces are adjacent - as are attached pieces - but are further identified by a solid or dashed line around the container set. Other arrangements are surely possible.

On increasing the number of grids from two: I agreed on the last note that this would be messy. If we can't come up with a clever interface I will willingly abandon the idea. I *think* you're dismissing the benefits of such an approach a bit too quickly, but I'm not prepared with a suitable battery of powerful examples. I guess I'll let you kill the idea for v1. ;-)

I share your view that the necessity of the closeup view is increasing. I think the display prototyping you're doing is crucial to our discovering things like this. Are we prepared to do a high level interface design yet? You're tackling a few parts, but we may be missing others. Maybe the problem is that this work is leading other essential design by too much. What do you think?

John's Response

• 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.

Conclusion

The ideas Paul and I came up with to tackle the problem of representing attachment, containment, and all the spacial relationships that go with it were ingenious but ultimately unsatisfying. I came away with a new respect for traditional strategy games that restrict their pieces to two dimensions. Much is lost in this approach, but the simplicity allows the essence of strategic conflict to emerge, unencumbered by bewildering issues of over, under, inside, and out.

References

• john1993-10-26. Beginning of attachment discussion.
• john1993-11-09. Attachment hierarchy, hovering vs. landing.
• john1993-12-03. Parachuting, ships and bridges.
• john1994-01-28. Attaching and detaching: concept.
• paul1994-02-09. Questions about the concept.
• john1994-02-16. Attaching and detaching: mockup.
• john1994-02-20. Helicopter airlifts and aerial dogfights.
• paul1994-02-21. Mockup questions.
• john1994-02-22. Mockup answers.
• paul1994-02-23. Paul's issues.
• john1994-02-23. John's response.
• john1996-06-19. Air and ground pieces sharing oblong grid.