glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[glob2-devel] teleporters


From: Leo Wandersleb
Subject: [glob2-devel] teleporters
Date: Tue, 06 Feb 2007 02:35:11 +0100
User-agent: Icedove 1.5.0.9 (X11/20061220)

hi list

i'm digging into gradients and have some questions:


== 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?

=== 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.


good night,

Leo Wandersleb




reply via email to

[Prev in Thread] Current Thread [Next in Thread]