Re: Major problem with the path code

[Peter Garrone <pgarrone at acay dot com dot au>]

On Tue, Nov 25, 2003 at 12:05:41PM -0500, Eric McDonald wrote:
> Hi Peter, Hans, others,
> 
> I mostly agree with this. That is why I mentioned the 
> tasking/planning stuff in conjunction with the AI in my "growth 
> agenda" last week. IMO, we need to further abstract and separate 
> things, even if the "clients" and the "server" are still part of 
> the same monolithic executable.

My apologies. I am still learning this system to an extent, and have
been focused on getting this pathfinding doing.

> In a tradeoff of simplicity vs. effectiveness, I would choose the 
> effectiveness in this case. I don't see supply automation as 
> belonging to a GUI client or an AI client, but to the server, 
> since it ultimately involves manipulation of common game state. 
> And the server should be free to do what is best, not just what 
> is minimalist.

Good Point. The supply should conform to definite simple rules though.
But it should take account of enemy zoc, and terrain. I suppose an
algorithm that first flags each hex for enemy zoc, then moves out from
each supply unit looking for units to supply and taking terrain into
account might seem like ai. But it should conform to definite well
specified rules would be my main concern. But task/plans/doctrine is fuzzy ai
behavior, so should not be in the "server".

I suppose that AI in this situation is really only the implementation of
well-known algorithms. Would we call the Astar algorithm AI? I would say
yes, because it makes the existing AI work better anyway. But just
because its "ai" does not necessarily mean it should not be in the
server. However there are other good reasons why it shouldnt be there.
But a decent supply algorithm would look a lot like the astar algorithm
of course.

> 
> >  Therefore there should be simple "refereeing" code, and more
> >  complicated "AI" or "client" code.

> I agree completely. (And it appears that all 3 of us agree about 
> this, at least according to the new mail from Hans while I was 
> writing this.)

We are in heated agreement here. I hope I am not rehashing too much old
ground.

> 
> But like Hans, I am rather leary about attempting this endeavor 
> before the 7.5 release. I would be more in favor a "dirty" fix, 
> rather re-architecting at this point. But I would certainly look 
> forward to the re-architecting almost the moment 7.5 is released.

I agree now also. I have not been bothered with release points, but I
recognise that such separation is a significant effort, so should wait
for now.
 Peter.