(I'm assuming that the distance value is not just the physical distance, but takes into account obstacles in the path. Is that correct?) Actually, why not for each possible resource (when choosing which one to collect), look at the *sum* of the distance value from the worker AND distance value from the building? This way we can find the resource that is easiest to get without going too far off the shortest path from the worker to the building. So there is always only one calculation to make which will always give the best answer, no conditional branches needed.
This could only work if it is already known what kind of resource the worker is supposed to get (the target resource), so I'm just wondering why is the target resource not known at the start? In any case, what I am doing with my project here will take care of this as it will break down tasks (like the construction of a building) into subtasks (the delivery of each individual resource unit) and each subtask will be allocated to the best worker to do it. How to figure out which is the "best" worker is the focus of my project so I will be doing that, whether this gets implemented into the game or not. I'll let you guys know how it goes at the end of the year. Cheers. On Mon, Jul 21, 2008 at 5:04 PM, Kai Antweiler <[EMAIL PROTECTED]> wrote: > > So does the algorithm for the resource pickup make the worker pick up > > the resource that has the lowest distance value from it when it was first > > allocated the task? > > In each step the worker chooses his next field. So if a new resource > is available nearer or the old one vanishes he will automatically walk > to a different resource. > (By the way the resource values are only recalculated every fifth time > step or so. But this can only lead to one maybe or two steps in the > wrong direction.) > > > > If that's the case maybe a possible optimisation is to > > make it consider the resources that are close to the target building as > > well? > > Yes, we thought about it. But because we don't know the target > resource, this is not so easy. We're not even using heuristics here. > So this is clearly an issue where we can improve. > > > > And a further optimisation is to make it find the nearest resource > > located along the path to the target, but that might be quite a heavy > > process... > > Actually I think this is easier - and a good idea. > > I thought a while ago about having a worker choose his next > field by the distance values as usual, but have him choose from > all fields with the same distance a field that is closest the building. > > After reading your comment, I think we should use both distances equally: > > If the glob has not been at (or maybe near the building) he > should look at those fields that are nearer to the resource. > > Than at those that are nearer to the building. > > If there is a one that qualifies for both, take it. > > If not, look at the field with the lowest distances value. > And here I mean: comparing the resource distances to the > building distances. > > If that value is an improvement to the current field, take it. > > Otherwise take the other field. > > > Although this algorithm might take longer in many cases, I think > it will be better on average. Especially if this behavior is considered > in unit allocation. > > -- > Kai Antweiler > > > _______________________________________________ > glob2-devel mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/glob2-devel >
_______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
