Re: [glob2-devel] teleporters

[Kai Antweiler]

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


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

I expect much more than 5% with the new layout.
I have put in a lot of comments compaired to the rest of glob2.
But the organisation of the code itself is bad.  I will reorganize
it and put in comments on how to switch to simple gradient generation.

By the way, if you think the rest of glob2 code is more maintainable,
you haven't seen much.  Glob2 is written using a greedy approach.
Every change to glob2 is made in the simplest way it could be done.
Therefore you have a bad design, and a lot of things are in places
they shouldn't be.
This might be a general open source illness.
Anyway with Bradley coding so much and his preference on reuseability
and abstraction this will change.


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

I want at least one simple that every one can understand, and
one sophisticated that will be fast.  But different maps, and gradients
may prefer different generators.


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

And now you already should use two.  One to generate an initial gradient
and one to update.  Combining both into one wouldn't enhance readability.
The planned algorithm is for updating the gradients.

But this is not trivial.  As far as I know, we can only go for an
algorithm that is much better on average, but takes about twice as long
as the simple calculation in the worst case.
A simple routine, that estimates whether the simple version would be
faster in the current turn, would be nice.  (But shouldn't be necessary)

If you want, I'll help you to understand what we did and what we had
planned.  But you'd have to wait till next month.


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

This comment was about tps directly implement in the gradient.
You wouldn't be able to manage pipes this way.


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

You're right.
We could manage tp-tp routing.  Maybe some network theory.
Simplest would be that "entry" tps have to sign in special waiting list of
the "exit" tps.  That is n^2 queues additional for n bidirectional tps.


>> I also would like to have teleporters for warriors only.
>
> I was thinking of workers only TPs as an indestructible map design element.

We could have different teleporters:
One base class teleporter and some inherited classes:
1. Indestructible map design elements for workers.
2. buildable warrior only tps for smarter attacks.
3. virtual tp buildings (pseudo flags) for resources transplantation:
   Imagine a tp which only will have influence resource spreading.
   You put one tp-flag on or near a resource you want to transplant,
   and one near the place you want to farm. 


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

When we increase speed someware, we can use slower algorithms elsewhere,
without makeing glob2 unbearable slow.


> I don't want one ways.

I do, for the tps that have to be build.
This would allow to limit the range of tps.
Then you would have to plan nexi ( nexuses?  What is the plural of nexus?)
Let's say on a real big map you'd have to have 3 nexi to get to your
enemy.  But the enemy has good recon an sees this.  After one third
of your army is near his town, he destroyes (or deactivates) one nexus.
Now he finishes of the small force that is stuck in the cave of the lion
(does that translate?).
Hooray!!! smart glob2 player.

Bidirectional tps would look bad.  Glob leaves it, gets back into it
in the next turn.

Rethinking: we could give ordinaray tps the ability to be a virtual
nexus.  That is globs would not have to leave it.  Or have special,
cheaper and easily destructable buildings for this.  These also could
be combined with the non-buildable map element tps.

When considering limited range.  We should also consider
to prevent tps (or tp-helper-buildings) too close to one another.
This would make them better targets, because you wouldn't be allowed
to build redundant networks efficiently.


-- 
Kai Antweiler