Gatherer counts: of limiting and displaying.

[wraitii]

Some discussion that revolves around two tickets:

-The already committed "limit to the gatherer count per resource" (1387).

-The yet-to-be-committed "display the number of workers on resource X" (643).

I think those two are linked and I'me putting up a discussion because there are a few design issues right now (and I should now, I committed the patch for 1387).

So right now each time a gatherer is tasked to a resource, it will be added to that resource's "gatherer count". If the resource is "full", the gatherer tries changes plans. For convenience's sake and help for the AIs, I've made it so that when a unit is returning resources but will come back to gather, it's still "assigned" to that resource (this avoids units coming in and "stealing" your spot, and does help the AI as it has a real count of how many units are gathering, and won't assign thousands of units to the same tree just because others are returning resources).

There is no discrimination between players. It is all handled automatically by unitAI (there is possibly a few missed cases though, in particular there is a ticket opened for some cases where apparently the units aren't removed properly).

Two problems:

-it's not entirely logical: if units need to go really far away to deposit their resource, it might be better if they were removed from the "gatherer list". Basically i think it might be better to simulate a unit being in voice range to say "No I'm working there, go away", ie have a maximal range after which the unit will be removed from the list even if it's returning there. This should probably also be true for units that are tasked to gather something from afar (if you order a unit to work on a tree on the other side of the map, right now, its spot is taken immediately. Not really good. Particularly for the reason below).

-It's gameable. Since there is no distinction between players, a player can very much prevent other users from gathering somewhere simply by tasking units to it. In particular, right now, with enough dedication, you could task units on an enemy's mine very far away, make it full, preventing the enemy from collecting, and never actually going to collect. This would be fixed by changing the behavior to have a maximal range though. Still, it might be better to make this limit per player, perhaps?

So questions:

-should there be a maximal range for the behavior or should another system be used (weak link/strong link or something?)

-should it be split between players to avoid gamey issues and some other odd cases?

Now it's linked to #643 because I believe we could simply use the same unitAI system to add the gatherer to the "gatherer count" for that resource there. Only we need to agree that a gatherer returning resources is still gathering (and here the maximal range might not apply).

I would advise against not counting gatherers returning resources at all. This means AI would need to count on their own again, which is slow and inefficient and ugly and not safe and so on.

[sanderd17]

When units are tasked to a resource, they should be assigned immediately I think, so the player can keep count. So I'm not really in favour of the range system.

I do agree, to avoid it being gameable, it should be a limit per player.

Btw, I thought displaying number of gatherers is already in: http://trac.wildfiregames.com/changeset/13541

Edited July 14, 2013 by sanderd17

[Juan Sebastián Gómez]

Hello Wraittii. In my opinion, if units needs to go really far to deposite their resources, they shouldn't be removed from the "gatherer list". It's true that a second player could send his citizens and capture the hole mine before first player even arrive. But I have seem in other games that when it happens, citizens just get together over the mine and wait their turn to collect. The same applies when you send so many citizens to collect metal or stone and there's no enough space for everyone of them. In that case, some of them collect while the rest just get together over the mine waiting for their turn. When players see this, they immediately know that it's better to take some of those citizens and send them to other resource.

For me, every citizen sent to collect a resouce should be imediately added to the "gatherer list". No matter how far or how many citizens are already working on that specific mine. I think this is the only way to have an accurate "citizen per resource count".

Note: In case you use "Shift" key to assign some citizens a list of tasks, being gathering a resourse the last one, that group of citizens should be added to the "gatherer list" just when they finish the penultimate task, not before.

Edited July 14, 2013 by Juan Sebastián Gómez

[Juan Sebastián Gómez]

another option -If you don't like the idea of citizens around a mine waiting for their turn to work- could be to asign mines in the game a max number of allowed workers. This way, every time you send a citizens to work on a full mine, you'll get a message saying something like: "This mine has exceeded the max number of allowed workers". This should happen no matter how far workers of that mine are depositing their resourses. The mine is full, that's all.

Edited July 15, 2013 by Juan Sebastián Gómez

[Nolanjoker]

Pablo you know about trac in order to create tickets when a gameplay are not complete or can be improved?

[errt]

If we know the time a unit will need to reach the dropsite and return (or we can estimate it good enough), something like this might be possible:

Have the gatherer count be a hard and soft limit, so gatherers currently working on the ressource count 1 to the hard limit (so e.g. only 5 workers can work on it concurrently). All gatherers being assigned to the ressource (whether currently working on it, returning to or from the dropsite or just being idle) would count <timetogather>/<timetogather+timetoroundtriptodropsite> to the softlimit (so no more than a total of 5 may be assigend to that ressource). That way, for a single player with one dropsite that all gatherers on this ressource use (this should be the main case), if assigned the max number of workers, this should balance out to a optimal (subject to rounding) gathering rate. The situation for more than one player on a single ressource might get more complex, but could work, too.

As an example: If a ressource allows 5 gatherers, and units the player wanting to collect from it take 10 units of time to gather and 20 units of time to round trip to the drop site, he could assign at most 15 workers (15*(10/30)=5). If assigned at the same time, 5 of them would start gathering, at time 10 they'd go for the dropsite, so the second 5 will start gathering taking up to time 20, when the first 5 have reached the dropsite. At time 30, the third batch of workers will have finished gathering just in time the first batch arrives again and so forth.

This still has the issue of being gameable by just filling the soft limit with units you'll never reach the target. Solutions to this could involve requiring a unit to at first reach the ressource and the return to it more or less regularly to be counted to the soft limit or using the soft limit only when the hard limit is used up.

[Nolanjoker]

that good alternative idea when resources are far to the dropsite, two things left, what happens with Mauryan Elephant workers and waht happens eith the Ai, with this change?

[gudo]

In that case, some of them collect while the rest just get together over the mine waiting for their turn. When players see this, they immediately know that it's better to take some of those citizens and send them to other resource.

For me, every citizen sent to collect a resouce should be imediately added to the "gatherer list". No matter how far or how many citizens are already working on that specific mine. I think this is the only way to have an accurate "citizen per resource count".

I agree that this is how it should be. Execpt lumber and berry bushes. If there's a empty tree right next to a crowded one, why not harvest from it?

[Nolanjoker]

some times the stone quarries are together.

[niektb]

To reply on displaying of gather counts: it is really a must. You can see it in action in aoe3 and it really works. Every time I play an other RTS I really mis this feature.

[s0600204]

My apologies for continuing/resurrecting an old thread...

I have a counter proposal to the problem of counting currently gathering units on a given resource, when they are not actually at said resource:

• Specify units tasked to gather, but not actually at the resource, as "Enroute" gatherers, and make the object storing the entity-ids of these be player-specific.
• When a unit arrives at the resource, they are moved from the player-specific 'enroute-gatherers' object to the global 'gatherer' object for that resource.
• When a player selects a resource, the count they see in the UI is summed from the global 'gatherer' object and their particular part of the 'enroute-gatherer' object.

To give an example:

• Player 1 and Player 2 can both see a tree they wish to gather from, a tree that has no current gatherers
• Player 1 sends four units to gather at the tree, and they are now considered 'enroute'
• Player 1 selects the tree in question, and sees from the UI that there are four gatherers
• Player 2 selects the tree, and according to her UI, there are no gatherers. (Which makes sense, as a Player shouldn't have advance notice of enemy unit movements)
• Player 1's units arrive and get to work. Player 2's UI updates, showing the four gatherers.
• Player 1 sends four more units, and upon reselecting the tree, his UI shows eight units.
• Player 2 also sends four units, and her UI updates to also show eight gatherers (Player 1's original four units who are still at the tree plus her four enroute units)
• Player 2's units get there first, and set to work. Player 1's units arrive shortly after, find the tree now full, and look for an alternative tree nearby.

The plus is that it prevents gather-slot stealing by not allocating the global slots until the unit is actually at the resource, whilst also providing a way for a player to be able to assign units to a resource, and have the UI update to reflect that decision.

To see if the above would work, I have created a mod to demonstrate: https://github.com/s0600204/gather-count (A18 only, sorry). Continuing, on a branch, I've also merged MattDoerksen/Deiz/historic_bruno's patch from #643, adjusting it to take into consideration enroute gatherers and also formations (which was a known issue with the patch).

Known issues:

• Units coming out of a building (from being trained/garrisoned) following a rallypoint to a resource to gather are not counted. This is due to units being given the order to GatherNearPoint rather than Gather in these cases (causing units to use INDIVIDUAL.GATHER.WALKING rather than INDIVIDUAL.GATHER.APPROACHING). This is also true in the unmodified game.

Edit: I created the mod so as to demonstrate and so people could try it easily. I can create a .diff patch if desired. Edited May 20, 2015 by s0600204

[FeXoR]

Does this approach really solve more issues than it brings with it?

If so please state which ones.

[s0600204]

Issues it solves:

• Gatherer-blocking - where one player deliberately sends units to gather at a resource close to an opponents base to prevent the opponent gathering from that resource
• Fore-knowledge of enemy gatherer movements - where a player can look at a resource and see how many units are currently gathering or have been assigned to gather there, regardless of whether said units are the player's or not, before any of them ever arrive.

Issues it introduces:

• None. (That I'm aware of, no doubt someone will point something out.) The mentioned issue is one that is already present in 0AD.

Edit: The example mod has been updated to be compatible with SVN (r16778) Edited June 19, 2015 by s0600204

[FeXoR]

I agree gatherer-blocking is an issue to be handled.

However, the other things seam more like a consequence invoked by the approach and I'd not consider them positive.

I don't think there is any need for the ability to manipulate where an enemy gathers it's resources other than sending military units there.

What about a "ratio" approach so gatherers chose the target entity to gather from by checking 1 / (Distance(entityToGatherFrom, resourceDroppoint) * numberOfUnitsInRange(EntityToGatherFrom, distance) ) ?

Something like this would IMO be better than hard capping per entity.

Not sure about the performance...