Now, for better things! I threw together a wrapped, attributed container class for Moe use. "Argh you fool!" I hear, "don't wrap containers, and don't use your own!" Eh, you might be proven right in the long run. In the short run, this seems pretty bad ass.
What you ask? Auto-discovery. The containers now will toss events (actually aggregated events, so there's only one to many containers) on addition or removal of an object. They will also auto-grant fog of war information based on info generated from attributes during game initialization. So, what does that get me?
Say a unit moves from one tile to another. What fog of war events need to be learned? Unit loses sight in old tile. Unit gains sight in new tile. Everything that sees the old tile loses the unit. Everything in the new tile sees the unit. The unit discovers everything in the new tile... and so on. Quite tedious, and quite annoying when the general behavior differs only slightly.
So with the new setup, remove unit from old tile, add unit to new tile, and the container events handle all the side effects. Further, if a different empire's unit discovers the new tile, the fog of war changes will propogate to the original unit, allowing the new empire to find the info about it without me explicitly coding that discovery vector. Just set up a few rules, and let the code extrapolate what it's supposed to do.
It's very interesting to do things this way. I can only imagine the sort of stuff that someone that actually knows what they're doing can do with this sort of rules based approach. I'll see if I can't get a test map done up tomarrow, so I can effectively show how the container benefits actually effect the code involved.
How are you storing visibility info? I'm keeping a counter per player per tile. The counter represents how many of their units/buildings can see that tile. This way, when a unit is placed, I just increment every counter in a certain radius. When it's removed, I decrement it. I get the impression you're calculating it a much harder way.