Jump to content

Territory refactoring


sanderd17
 Share

Recommended Posts

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:
post-15092-0-47612100-1390911581_thumb.p

Current non-ambiguous possibility:

post-15092-0-78546300-1390911360_thumb.p

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:

post-15092-0-78546300-1390911360_thumb.p

post-15092-0-04703800-1390911390_thumb.p

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ...).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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"?

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...