The Zone of control (ZOC) code has always been a bit odd since it was written for GalCiv2, with weird little bubbles, twists, etc. But it mostly worked in GC2, and I didn't have time to give it a lot of love when porting it to the new engine. The code to update the ZOC is also fairly inefficient, which is why it only updates at the end of a turn. The ZOC expands based on the influence of the city and the player's influence ability. It works by specifying a source, which has a power and a radius. The power determines how much influence the source is exerting on the tile, so that if there are two sources in the same area with different owners, the player who 'owns' the tile is the one who has the most power in that tile.
This is how the influence looks in 1.09e for a city hub which has a radius of 2:
Looks OK, right? But wait, city hubs have a radius of 2, and that's only showing ZOC around tiles that are 1 tile away from the hub. It turns out that the ZOC code was modifying the power of the source (the city hub) by its relative distance from the center using the Euclidean distance forumla So the closer you were to the center, the higher the power was, and the tiles with distance 2 had a power of 0 because they were at the farthest edge. Also, adding an improvement on the edge of the ZOC didn't bump out the influence because most of them only have a radius of 1, which meant that the only tile that got influence was the one they were actually in, which tended to already have influence from the city hub. Also, since you can have up to 4 improvements in one tile, each exuding their own influence, they were overwriting each other as sources.
So first I changed it so that all tiles within the radius got the same power value. If we cared about pixel distance instead of tile distance, having the influence fade out towards the edge of the range would make sense, but everything uses tile distance for calculations, and the descriptions for how much influence an improvement gives you says 2 tiles. I also made it so that the influence was calculated from the city tiles instead of the improvements themselves, so that each tile would return the max influence radius and power for all the improvements on the tile. This is what happened:
Well, rats. The interpolation code is clearly just using the center point of each tile and it looks pretty lame. The city hub is now starting with a radius of 1 and growing to 2 once it's built up a little more. But it looks lame, even with a radius of 2. It must need more points. Hmm, there are some extra points that are commented out in the code that calculates the edges. Maybe just uncommenting those will work?
Nope. That obviously isn't going to work. That must be why the points were commented out. But why weren't they deleted when they clearly don't work? I hate that. The developer who wrote the original ZOC code hasn't worked here for over 5 years, so there is no target for my crankiness.
I commented out those lines again in case I needed them for reference and stared at the edge calculation code again. I decided to simply outline the edges of the tiles, since that would be clear which tiles exactly were under your influence, and the filtering code should take care of adjacent zones.
Well, that's better, I guess. You can tell where your influence is--but wait, why isn't that fire shard in my influence? It's only two tiles away. Oh, but it's still using the Euclidean distance formula to set the powers. Well, that's lame, and it makes it look lame too. No one is going to look at this and say, "Oh, it's calculating the Euclidean distance from the city hub." They're going to count the tiles.
So I made it not check the Euclidean distance and just check everything in the bounding rect with the source at its center and a radius of 2.
I think it looks a lot better. This is a city that has been built up a little, and has two improvements built. The first improvement, the farm, only has a radius of 1, so it was inside the 2 tile radius of the city hub. It wasn't until I added the next improvement that it bumped out a bit.
I might need to do something with the line interpolation code though, because the leftmost corner of the zone always seems very pointy and we want the rounded squares for aesthetics. Also, I haven't played very long with this code so I don't know how well it will react with adjacent zones yet. But I think it's headed in the right direction, and the calculations are a lot easier to read now, which is always good. It's even a bit faster since it doesn't have to calculate the Euclidean distance anymore. Now, to test and polish...