Hi Kai Thanx for taking your time to think it over but i guess there are some misunderstandings.
> 1. The first thing that comes into my mind is: > when deciding in which direction to go, try a field that reduces the > distance to the nearest resources and if possible the distance to the > building that controls the worker too (or at least doesn't increase > it). Maybe consider a small disk instead of just the next field. > For a start this should weaken the problem in some cases. The now used algorithm (gradient/wavefront) does not allow this approach. Imagine it as a landscape with the special property to have no place that is a local minimum without beeing 0 whereas 0 is the level of the searched resource/building. You have such a landscape for each target (corn/wood/stone/fruit1/fruit2/fruit3/every single building). Now corn is found by walking down the corn-landscape to level 0 and then the inn12 is found by walking down the inn12 landscape. if you mix 2 landscapes you get local minima where the glob is closest to both corn and inn12 but doesn't find neither the one nore the other. HA! Idea! Bad idea, i think :( Walk down the Inn12+corn gradient to a local minimum(/saddle point) and then procede with the normal algo. unfortunately this local min needn't be a global min. also the combined gradient might be const on wide areas. :( also the direct path to the shortest path between inn and corn would be an improvement it is far from beeing optimal. > 2. When a worker gets a job for a new building-resource, > you could use the gradients to determine the resource the worker > is heading to. (Well this works not in constant time, but it is fast > since you know each step. Combine this with 1. to get a promising > resource.) > Then you can compare the distances: > worker-this_resource-building > with > worker-building-nearest_resource-building > and dicide if resource or building should be the target. ?? if i got you right, you take the resource that's closest to the building in consideration. that resource doesn't need to be reachable by the glob at all. > 3. If the worker hands over its first delivery to the building, it could > be let to the part of the building that is nearest to a needed > resource - only if that is not to far off and a considerable improvement. > (For example using a small gradient initiated from that field) > I think the actual improvement would be small, but the globs might > look smarter this way. again: if the spot is reachable, this could help. > 4. Globs could go to the building before they start out for the resource. > Ok, this is ugly, but fast to calculate and never worse then 2 times > the optimal route. no way! that's the worst of all possibilities as a remote suply-inn would never get a single corn. > 5. Make globulish behaviour part of race customization and let > the user worry about it ;-) ?? > > C > > C > > CHHG > > CHH > > CII > > CII > > Cx > > C > > > > G runs around H again and again rather than sitting at x and handing > > in the C. > > I guess here you are looking at two different inns. > The upper right inn and the lower left - is that correct? no. inns are 2x2. so it is just one inn. > Kai Antweiler Leo Wandersleb _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
