Responses to various issues in your last note:
Some of my confusion about what the enemy sees resulted from your not being explicit about when you were describing the Battle Map view. Your pretty much cleared this up, but raised the visibility of another issue: what *will* be visible from the Battle Map? With Conquest it's easy: you see at most one enemy piece in a given square at any point in time. As we lift that restriction through the Closeup view, I think we really need to simultaneously rethink the Battle Map. Knowing that there *might* be a piece hidden under the visible piece on the Battle Map, I will frequently feel compelled to look underneath (i.e., double-click to bring up the Closeup View). This will quickly get tedious and annoying. My proposed solution: put a number on the piece on the battle map if there are other pieces visible from the Closeup View. The number would correspond to the total number of visible pieces, so it would be somewhere between 2 and - what? - 18? Hmm... maybe a simple asterisk or some other sign would be equally effective.
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:
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?
I'll try clumping and muss with the menu in the coming days.
Are we making progress?