Territory refactoring

[sanderd17]

Currently, the territory is a bit complicated. Mainly from a code point of view. There's a territory owner and a "connectedness" to a root. If your territory isn't connected, it's hard to find out, from a code POV, why it isn't. Because it's too far anyway, because an ally or an enemy build a CC too close, because your CC was destroyed,..?

Current ambiguous possibility:

Current non-ambiguous possibility:

We can't have separate decay values for when f.e. an ally caused the unconnectedness, because we can't detect that. So I propose a simplification:

• Only root entities (CCs) cause territory. When you place something in a neutral zone, and it isn't a root entity, no territory will appear
• Other entities can still enlarge the territory

This way, we can very easily query the owner of a tile, and compare if it's an ally, an enemy, gaia ... And change the behaviour accordingly.

I'd also want to remove the "weight" concept from territory. When you just use the radius as weight, it becomes a lot more intuitive IMO. And it allows you to calculate territory faster (currently, a floodfill algorithm is executed for every entity, while you could reduce it to one floodfill per player if you don't use weights).

Future possibilities:

I have code ready that does this behaviour, the code is a lot more simple than the old code, and it's more flexible gameplay-wise.

[niektb]

You are stating it is faster. What performance improvement can we expect?

[sanderd17]

But Territories are only calculated when they change (every time a building is added or removed), so you can't expect too much performance improvement. But given I didn't add any code, only removed stuff and placed stuff out of the loop, it will be a bit faster.

Performance isn't the main goal here. The main goal is that the scripting side should just be able to query the territory a building is on, and shouldn't bother with connectedness.

Edit: these are the (not cleaned up) changes I did: http://pastebin.com/Z1b2VehK

To clean it up, I should also remove the connectedness methods and stuff.

[Mythos_Ruler]

and it's more flexible gameplay-wise.

Territory is intended to be a limiter and (relatively) inflexible. If the player can build structures outside his territory, then what the heck is territory for anyway? Right now, from the player's POV, territory has a clear and concise affect on gameplay. Why start to make this ambiguous? To make the code cleaner is not a good answer.

[sanderd17]

Territory is intended to be a limiter and (relatively) inflexible. If the player can build structures outside his territory, then what the heck is territory for anyway?

I mean more flexible from a code POV. In a sense that we could differentiate between ally territory and enemy territory without adding a bazillion lines of code.

For now, almost every building is always on "own" territory. It just sometimes happens the "own" territory is not connected, (see first screenshot). Calculating in which territory the tower would have been if the tower wouldn't be there is tedious. If you have to do it for every building, the lag will become even bigger again. While in the last screenshot, we can immediately see that the tower (owned by blue) is on green territory. So we can either let it decay or not, or change the amount, depending on how friendly green is to us (neutral, ally, enemy, mutual ally ...).

[Mythos_Ruler]

I mean more flexible from a code POV. In a sense that we could differentiate between ally territory and enemy territory without adding a bazillion lines of code.

Well, you did say "and it's more flexible gameplay-wise." So I was responding to that and then seeing your screenshot with a blue tower built in the green territory and a blue tower built outside any territory and I'm left wondering what exact gameplay changes are you proposing.

[sanderd17]

Currently, we have a single decay. I propose to have a possibility to have multiple decays, where it would be possible that f.e. you still can't build in allied territory, but if an allied CC is placed next to yours, and it cuts off some buildings, your buildings don't start to decay.

Also, a possibility to let f.e. the Roman army camp decay faster when in enemy territory, and slower when in neutral territory (but still decay).

[Mythos_Ruler]

Currently, we have a single decay. I propose to have a possibility to have multiple decays, where it would be possible that f.e. you still can't build in allied territory, but if an allied CC is placed next to yours, and it cuts off some buildings, your buildings don't start to decay.

Also, a possibility to let f.e. the Roman army camp decay faster when in enemy territory, and slower when in neutral territory (but still decay).

This sounds good. Does the lone blue Tower in your screenshot represent the "Army Camp"?

[Lion.Kanzen]

It's very complicated to be avaible for A16? I know the team are focus in optimization Wraitii is busy with Aegis.

[sanderd17]

This sounds good. Does the lone blue Tower in your screenshot represent the "Army Camp"?

The tower must show that it doesn't cause any territory when the CC isn't close enough. So yes, it could represent the army camp, or an outpost where another CC build around.

The main limitation of the "not causing territory changes" is that you don't see territory blinking anymore. So we'd probably need an other visualisation for decaying buildings.

[wraitii]

I like it.

[k776]

Very quickly, I was involved with the spec for the original territory. The weighting was designed so that walls repelled territory far more than buildings, so that an ememies terriroty should not be able to push past a players wall barracade.... as long as that is preserved...

[Mythos_Ruler]

Very quickly, I was involved with the spec for the original territory. The weighting was designed so that walls repelled territory far more than buildings, so that an ememies terriroty should not be able to push past a players wall barracade.... as long as that is preserved...

Interesting. That's something I wanted. What kind of weight is necessary to do this for walls?

[FeXoR]

This should be the same for all buildings with an attack like CC, Fortress and Defense tower.

[sanderd17]

Very quickly, I was involved with the spec for the original territory. The weighting was designed so that walls repelled territory far more than buildings, so that an ememies terriroty should not be able to push past a players wall barracade.... as long as that is preserved...

Well, it isn't used in any case. All entities have 65536 as weight. The only exceptions are the special territory_pull and *_block. And the campaign demo cities. None of which are actually used.

@Mythos_Ruler: I suggest, if you want to use it, you don't enlarge the weight of the well entities (there's lack of an overflow check in the code), but halving or quartering the other weights might work well.