When player resigns, the entities belonging to the player should be deleted

[Jia Henry]

Hi,

When a player resigns, the entities belonging to that player should really be deleted. This would be better than handing over all the buildings and stuff to Gaia as it would reduce the number of entities and obstacles for the path finder in the game to minimise lag.

Also, another problem with handing over control of entities to Gaia is that the entities and are still hostile and will sometimes still attack other players which is not what should be happening.

[sanderd17]

They shouldn't be deleted. But when we have conversion, they should get a very low loyalty, making them convert almost immediately to player who's nearest. As such, giving the capturing player a reward for his effort in the form of almost free buildings.

[serveurix]

How about giving the possibility to choose who you surrender to ?

[Corey]

I think i Much prefer sanderd17's suggestion. easy conversion means for faster play and adds an element of land grabbing to the game as multiple players scramble to claim the territory. Also how are you suggesting they leave the game? the whole settlement fades and the people all die at once? that puts more strain with all of the extra animations which would increase lag, not decrease it.

[Jia Henry]

Most of the time, the game lags because of the fact that the path finder is having trouble navigating a large group of units around a certain obstacle in the game (such as a tree or a mine or a piece of wall) whilst trying not to break the formation, not because of the animations. The animations are relatively simple and are not graphically intensive.

Also, the conversion would lead to a problem involving population caps. What if the attacking player has already hit the population cap? Converting units would lead to that player going possibly way beyond the population cap which would pose a massive problem.

[Corey]

Replying to HenryJia:

Most of the time, the game lags because of the fact that the path finder is having trouble navigating a large group of units around a certain obstacle in the game (such as a tree or a mine or a piece of wall) whilst trying not to break the formation, not because of the animations. The animations are relatively simple and are not graphically intensive.

You forget that as one player has left the game the amount of work to be done decreases as less units are moving. Adding them back into the game just returns to the original amount of work and does not increase it so unless it is an issue having high sustained usage over time, there is no benefit to having lower usage at later stages of the game.

Also, the conversion would lead to a problem involving population caps. What if the attacking player has already hit the population cap? Converting units would lead to that player going possibly way beyond the population cap which would pose a massive problem.

Well then don't let someone convert more people than their population cap. Conversion is done on a person by person basis so you can easily add in the ability to check whether there is sufficient space to convert that one person. This would not cause issues with converting buildings as no such restrictions apply.

[Jia Henry]

Replying to Corky:

Replying to HenryJia:

Most of the time, the game lags because of the fact that the path finder is having trouble navigating a large group of units around a certain obstacle in the game (such as a tree or a mine or a piece of wall) whilst trying not to break the formation, not because of the animations. The animations are relatively simple and are not graphically intensive.

You forget that as one player has left the game the amount of work to be done decreases as less units are moving. Adding them back into the game just returns to the original amount of work and does not increase it so unless it is an issue having high sustained usage over time, there is no benefit to having lower usage at later stages of the game.

Also, the conversion would lead to a problem involving population caps. What if the attacking player has already hit the population cap? Converting units would lead to that player going possibly way beyond the population cap which would pose a massive problem.

Well then don't let someone convert more people than their population cap. Conversion is done on a person by person basis so you can easily add in the ability to check whether there is sufficient space to convert that one person. This would not cause issues with converting buildings as no such restrictions apply.

It's not the number of units that are moving that matters, from my experience, it's the number of units that are moving in the same formation that matters. Also, what if every player has hit the pop cap? Every possible scenario should be taken into account

Also, your idea of land grabbing would fail as if this is enabled, less players will use the resign option.

[sanderd17]

The population cap is more a training limit than an "owning" limit.

It's perfectly possible to go over the population cap. Like in A15, chariot archers that levelled up used double population, sometimes causing the player to go 20 units over its max population. This has been removed for balancing reasons, not for technical reasons.

There are also demo maps without buildings (so max population is zero), but with lots of units.

Now you can argue the winning player would have a disadvantage, as he can't train any new units until his captured units are dead, well, he can still kill everything he owns, so that'd be only a minor disadvantage.

[Jia Henry]

Replying to sanderd17:

The population cap is more a training limit than an "owning" limit.

It's perfectly possible to go over the population cap. Like in A15, chariot archers that levelled up used double population, sometimes causing the player to go 20 units over its max population. This has been removed for balancing reasons, not for technical reasons.

There are also demo maps without buildings (so max population is zero), but with lots of units.

Now you can argue the winning player would have a disadvantage, as he can't train any new units until his captured units are dead, well, he can still kill everything he owns, so that'd be only a minor disadvantage.

I think the ability to capture buildings is a good idea but not in this context. There are too many problems with giving the building to the nearest player. What exactly should be defined as distance? Most players expand so they cover a large area so there are too many things about what could count as "distance"

I think a better idea would be to have some sort of special units which can capture buildings but can't attack as this would make tactics far more diverse without "de-balancing" the game so everybody only uses 1 type of units.

[Corey]

Replying to HenryJia:

Replying to Corky:

Replying to HenryJia:

Also, your idea of land grabbing would fail as if this is enabled, less players will use the resign option.

Incorrect. You have no reasoning for this and it doesn't make any sense. Those who resign don't care who takes their land. If they are going to resign and they have others on their team then they would tell them to move into the area and get ready to convert. If they don't have anyone on their team then this affects nothing atall.

I think a better idea would be to have some sort of special units which can capture buildings but can't attack as this would make tactics far more diverse without "de-balancing" the game so everybody only uses 1 type of units.

Like in Age of Empires? they're called monks which already exist in 0AD, just can't convert yet. I'm pretty sure that's already in the feature request list. ​http://ageofempires.wikia.com/wiki/Monk_(Age_of_Empires_II)

[historic_bruno]

I don't like destroying entities of resigned players, but it's likely a trivial change to make an option for people who do want that. I like the idea of being able to transfer units/structures to other players, maybe as a form of tribute w/ various restrictions. In the past, that was also discussed as a way to handle resigned players' entities.

It shouldn't have anything to do with lag though, there are other, far better ways of dealing with performance issues, so this should only be about gameplay.

[Imarok]

Move tickets to Simulation as UI & Simulation got some sub components.