Re: [glob2-devel] teleporters

[Stéphane Magnenat]

Hello,

> == confusing code ==
> why are there
> updateGlobalGradientVersionSimple
> updateGlobalGradientSlow
> updateGlobalGradientVersionSimon
> updateGlobalGradientVersionKai
> when there is stated: speed 105.09% compare to simple on test
> as the best case of all?
>
> it is very confusing to have some extra 300 loc and it is not comfortable
> to hack in teleports into 4 versions of the same function.
>
> if versionSimple is about as fast as the other 3 can we delete the others?
> please don't take me wrong but a speed benefit of 5% at the cost of 4 times
> the loc taken the speed measurement was correct i don't see the point.
>
> == confused leo ==
> how should i implement teleporters?

Here is as I see it: basically a teleporters are list of area that are all 
connected together. So when you are updating a gradient cell that is a 
teleporter, you also scan around all teleporters area to find the smallest 
(or biggest I do not remember the direction) gradient in addition to scanning 
around the cell. When you follow a specific gradient in a suitable 
teleporter, you scan around all the teleporters to find the place             
to go. This will need some hack into the unit state machine but that should 
be limited.

> === 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) *no extra gradient needed
> *gradient calculation slowed down as a check has to be performed on all tp
> until the first teleporter is hit. after that the squares of the tp are in
> the list of the gradient and the gradient can be calculated as before. *the
> entering tp is not known until we hit it
> **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) *effectively bigger maps work with 8 bit
> gradients as these shortcuts put remote points on the same level
>
> === 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
>
> === conclusion ===
> I prefere the first implementation as it saves on resources and will work
> smoother i guess. I'd like to test another feature: global tp: one would
> have to build turrets around the tp first and then the tp. global tps are
> indestructable after beeing built/set up by the designer.

So I prefer the first implementation too. We should keep simple to code and 
easy to understand for the player.
As I see it, teleporters are buildings that cost quite a lot of ressources but 
use no room on the ground (they are virtual as flags). Normally the engine 
should be generic enough to handle this (virtual buildings that need 
ressources to be build but it might need work).

Have a nice day,

Steph

-- 
http://nct.ysagoon.com