Allow selecting units by cell rather than checking for intersecting unit boundaries.
This one is kind of a mixed bag. While it would be handy for hard-to-click-on units, what do you do about units in the courtyard of a building?
I didn't think of that, thanks for pointing this out. Might have to prevent the situation from arising by disallowing units from stopping there. Or clicking twice in a cell could select other units in the same cell.
Allow setting default attacks for units with multiple attacks. Battle Machine should probably use its arrow by default.
I could be wrong, but I think this is currently determined by their order in the XML, so if you want the arrow attack to be default, just re-arrange the skills and/or commands.
Thanks, that would be useful in the meantime. But what I had in mind was being able to set the default attack command *during* a game on a per-unit basis (think autocast from Warcraft 3 if you're familiar with it).
Disable faction previews by default.
Why?
Well, because I was never a big fan of them. I think it's easy enough just to try out the faction, so it's not a fantastic use of screen space. When you've tried a faction once, you'll never need or want the preview again.
Map previews, on the other hand, are indispensable.
Before a building's foundations are laid, place a transparent version of the completed building at the desired location. Enemies ignore this region, allies navigate around it.
That might be a bit jarring to look at. In a futuristic sci-fi faction, having a transparent hologram of a building would look fine, but it would look a bit odd in a medieval/fantasy setting. Placing some kind of foundation/scaffold/boundary would look good, but require more modeling work.
A ghosted version of the building is already used when placing the foundations. I don't think it would look particularly odd if it were to persist until construction has started. But anyway, the important thing is to mark the region as a no-go area for allies.
Blue movement/gather point arrow should have a minimum transparency cap, so it doesn't seem to disappear.
What is it that you don't like about that?
Why do we have the arrow in the first place? So I can see where my units are going. The reason for the transparency is because the arrow covers the extent of the screen, it might be seen as obtrusive... but I don't think it is, and the arrow only appears for a moment. A small degree of transparency solves this anyway.
Show idle workers as an icon in the (bottom right?) corner of the screen.
That would be nice, or just have a hotkey for selecting the next idle worker. Maybe an XML tag would be necessary to distinguish whether that unit counts, since Technicians might be standing around waiting for things to repair most of the time, and that's probably exactly what you want them to do.
Actually, there's already a hotkey ('I'). But there's no good way to know there are idle workers before pressing it, so the result is that I press it almost continuously in-between issuing other commands.
An xml tag might be useful, good idea.
Rotate minimap when rotating camera, rather than rotating the minimap camera position indicator.
That seems more like a stylistic preference rather than an objective improvement to me.
The issue is that when the indicator rotates and you pan the camera, it then moves at a different angle to your camera movement, which isn't entirely intuitive. But you're right. Anyway, this one isn't terribly important.
A per-faction total unit cap to discourage turtling, and limit network load. Could also limit numbers of defensive structures (Sphinxes etc).
Why? Turtling is a perfectly legitimate technique. If anything, this would just discourage human wave tactics, which are already dealt with by mechanisms in place (resource upkeep, selection size).
Legitimate but overused imo. In our games it's about the only strategy I've ever actually seen, though the CPU is admittedly rather aggressive. I don't see how it discourages wave tactics, the point is to stop players from stockpiling units indefinitely, and force them to try to attack in order to make some sort of progress (and they'll be able to build new units again to replace them when they die, so it will seem more worthwhile).
Make clearer which buildings are resource drop-off points, and for which resources.
What's more clear than saying this building stores 200 wood?
I could be wrong about this, but just because a building "stores" wood (raises wood cap) doesn't imply that it serves as a drop-off site for wood. I was caught out by this.
Remove unit armour (but keep armour types like Leather etc), boost unit health to compensate. The problem with unit armour is that it takes off a fixed amount of damage, which means units with an already weak attack are especially badly affected. Maybe this was intentional, I don't know, but I don't think it's particularly desirable. [emphasis mine]
Armor values serve a vital function and do exactly what they're supposed to do. Just like you said, it reduces the effectiveness of heavy attacks by a small amount while reducing the effectiveness of small attacks by a huge amount, so no number of darts is ever going to destroy a tank, but a rocket should just fine. Removing that would be making the game dumber by reducing strategy (which is what the "est" in Glest stands for). Units in Glest are already barely more than different combinations of HP and attack-strenght, and this would make it even worse. Exact opposite of progress.
This was the most controversial idea, so I put it near the end of the list. In your example, maybe the tank just needs buffed up a bit. All arrows do at least 1 damage, so it will be destroyed eventually. But it's a game, it doesn't have to be realistic.
So I don't think this one is so clear, and the only way to find out for sure how playable this would be is to test it. Armour *types* should still be important of course, so the rock-paper-scissors mechanic is preserved. Anyways, this one shouldn't really be here... it's just food for thought really.
Thanks for taking the time to respond to these, much appreciated.