Re: [glob2-devel] teleporters

[Leo Wandersleb]

Kai Antweiler wrote:
> Please wait a with the teleporters. (unless you use your second method.)
> I want to revolutionize the gradient computation next month.
> Last year I've planned an algorithm with Nuage.
> There is a layout for this in our bugtracker.
> It has some flaws, but I have a much more explicit and correct layout
> somewhere in my mailbox.

ok. i'm curious. but my vote is for version 2 now anyways.

> Also Simons version belongs to the most elegant solutions I have ever
> seen.  I would blindly vote for it as the best part of glob2 source
> code.

I will have a look again.

> Leave the gradientdependent implementation to me.

You will not be around forever and a maintainable code goes over a 5% faster 
code. That's a general thought and maybe it makes sence to have this technique 
here.

> The intention is to get real big maps to work smoothly where 10 or
> more teams can play at the same time.

That's a great point about globulation.

> By the way.  Not the algorithms were running 5% faster.
> glob2 was running 5% faster, which means that the algorithms were 10 to
> 15 % faster.  By the way glob2 only runs so smooth because we use outdated
> gradients most of the time.

I have no idea of the alternatives. I only thought it would be nice to have one 
and only one gradient generator.

> The gradient calculation is not a good place to hack in anything.
> Everything has been carefully planned, theoretically proven, extensively
> tested und measured.

As I studied mathematics I'd still like to look over this code and I still 
think there should be one method to rule them all. Maybe an algorithm that 
doesn't always regenerate globally from zero but fixes local changes.

> It is one of backbones of glob2.  A bug in here leads to very
> confused globs.  Trust me, I've seen some :-)

hehe :)

> That's the reason why I don't like teleporters.

TP v1. But TP v2?

> > === gradients that hit tp put all tp to the achieved value and further 
> > propagate from there ===
> > *a glob walking to wheat will either hit wheat or a teleporter. tp know the 
> > wheat exit gate and directly release the glob there (wait n seconds, gradient 
> > drops n here)
>
> If n is smaller than the transporter size, virtually all globs will
> want to use it.

hehe :) nice thought.

> If n is bigger than 1 this will increase jams.

Why so? if n is high globs will more likely walk. we don't have to limit 
throughput. i have no problem with 50 globs in the pipe on really big maps.

> What shall we do, if after n timesteps there is no place for the glob to go?
> Or all places it could go to are far further from the resource.  In this case
> it will go into the tp again.

szenario: big map, 30 tp, 40 globs, 1 tp that is closest to wheat :)
the best tp limits output to 2/s and hands over to next choice all others. 
tricky and  bad if globs expect the tp to bring them to wheat but finally they 
end further away from wheat ...

> Tps need to check if their resource value is 254.  A resource direct
> adjacent to a teleporter will lead to problems, because a glob might
> want it, but there is no place to get out of the tp sometimes.
> Imagine a tp that is overgrown by wood.  The gradient algorithm would
> need to check, if there is a free adjacent field that is also adjacent
> to this resource, otherwise use 1 as gradient value.
> (0 is forbidden area, if I remember correctly.) 

good point but controllable in exactly that way. if tp-wheat-level == 254 check 
if a tp has to get removed from the list.

> > **this is bad if we want (i don't) to limit the throughput. (imagine there is 
> > only one tp near wheat and all globs use tp to get there while the opponent 
> > tries to rush this tp)
>
> I do want to limit the throughput.

I know want to limit, too.

> If we don't glob2 will become all about
> teleporters.

the time spent in the tp can be any time. 50 gradient-levels and 50 s would 
dramatically limit their usability. Level 2/3 could be faster.

> There also big problems I refer to below.
> I also would like to have teleporters for warriors only.

I was thinking of workers only TPs as an indestructible map design element.

> That is use them
> on war-flag-gradient only.  This would also allow us to be more wastefull
> on tp computation and thereby allow more sophisticated algorithms and
> attain a better glob behaviour.

??

> > *effectively bigger maps work with 8 bit gradients as these shortcuts put 
> > remote points on the same level
>
> I don't understand.  What do you mean?

now an 8 bit gradient barely is enough for 512x512 maps. with 3 TPs remote 
areas get closer to each other on the gradient and 8 bit is enough again.

> > === gradients that hit tp put all tp to the achieved value. tps propagate their 
> > own gradients ===
> > *globs would have to check if they are higher on wheat-gradient or on one of 
> > the (tp-gradients + the tp's wheat-value)
> > *tp could accept a certain amount of globs at a time depending on the level 
> > (1/s 2/s 3/s). this would lead to unwanted behaviour as globs would start their 
> > journey and turn around to take the teleporter while others would benefit far 
> > more from the tp ...
> > *many more gradients
> > *smaller change to the gradient generation
>
> Actually no change to the gradient generation.  Or have I missed something?
> This is my favorite.  Better unit control.  We could refuse globs with high
> speed from using teleporters, or require some school education for using it.
> This would also allow oneway teleporters.

I don't want one ways.

> Also your first approach will cause horrible traffic jams.
> Globs are not considered in gradient calculation.  No matter how many
> globs dam up in front of a transporter, even more will come.
> Glob-glob collisions are eluded by premovement checks individually.

i guess i'm convinced.

Leo Wandersleb