On 11/4/05, Matthew Marshall <address@hidden> wrote:
On Friday 04 November 2005 08:13 am, Andrii Zvorygin wrote:
> - shortcut problem: this is the problem where you have say two lanes
> beside each other, so theoretically the globules can use one to go
> forward and one to go back. however they the do not do this very
> efficiently and keep bumping into each other becase one of them is usually
> longer then the other. they always wish to take the shorter path though
> it's no faster. Thi cis is a limitation of the wavefront algorithm as far
> as we can see. - circuit problem: this is the problem where you have one
> lane leading towards a resources and one lane leading away, due to the fact
> that the shortest path is going to be only one of the two lanes they wont
> even consider the second, same problem as mentioned in the shortcut problem
>
A while ago I had an idea for solving this. The player can paint 'arrows'
similar to forbidden area. Globules will not enter a space from the opposite
direction of the arrows. This does add more management, but in this case it
might be a good thing.
Note that you also have the problem of fast globs being held up behind slow
globs, burning food. Perhaps these arrows could optionally enforce a minimum
speed? (Similar to the minimum attack strength/speed for warriors.)
MWM
Well though there is always benefit of havinng direct control of your
globs, it does add managment. Though I can't profess to be the best
glob2 player or indeed even a very good one at that (can't beat more
then one AICastor at a time :( though that is the reason I wisht to
improve the UnitAi) I have loads of trouble being able to take into
account all the fields that are already available, while it is a good
idea and can be used for many things (for instance instructing your
warriors in what direction you want them to attack or what not) It
changes how the game is played (and i'm not saying it's a bad thing)
maybe we can make it a plugin later, or if we decide to make the
UserControled "Ai" I was talking bout in the last email.
the pheramonal system I was talking about earlier can actually take
into account all of these things. though I forgot to mention it in my
first email. The reason behind having pheramones three squares on each
side of the globules is so that if a globule is so that the globules
followinng wont get lost if an obstacle appears on the main path, they
can always side step into the pheramonal path and continnue on their
way later rejoinning the path with the highest amount of pheramone if
there are no obstacle along it.
this actually also takes care of the problem of faster globs being
bogged down by slower ones as they see the slower ones as obstacles and
simply bypass them and go back to their normal course. In the case of
alleyways however there is not much that you can do as if you do set a
minimum speed then the workers that can't keep up are more or less
useless until room in a school is available for them to go there. under
normal circumstances they would go there anyways if room was available
so the speed then wont be too much of an issue, bottle necks always
exist.
oh yea btw, direction is directed by all spaes in the pheramonal path,
like as long as there is pheramone there is direction. as it is an
array and every direction has it's own direction and pheramone the
dominant direction is determined by the pheramone that is at least 2
times that of the second largest pheramone. perpendicular paths don't
count into this as they don't really get in the way(maybe diagonal ones
don't have to either, but that can be seen to when code actually starts
getting written, or we could determine it through logic)
also you'll eliminate the problem of possible congestion say if you
have an alleyway and two resources on the other side, with the
wavefronts it's hard to code in taking into account other wavefronts
(not sure it's possible actually). with the pheramonal path, because
type only dictates which pheramone path a globule should follow,
direction and pheramone level are non-typal so a path initiating glob
will not go against the flow of a currently laid path and will be
encouraged to go with the flow of a current path (assuming it gets them
to the same destination) this shouldn't be too hard to implement using
the A* algorithms as they assign values to directions and you can give
slightly lower costs to those that go with the flow and much higher
costs to those that go against
Sincerly,