Re: Major problem with the path code

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

Hi Peter, Hans, others,

On Tue, 25 Nov 2003, Peter Garrone wrote:

>  program to restore game balance. The point is there should be a
>  central part, the "server" or "refereeing" part that is "simple" and
>  conforms to strict rules, 

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.

>and is separate from the AI. Eric mentioned
>  that he though that cluster analysis might be good for resupply, but I
>  disagree, because the supply should conform to strict simple rules.

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.

>  Therefore there should be simple "refereeing" code, and more
>  complicated "AI" or "client" code. The best terms I can think of are
>  "refereeing" code and "player" code, with the AI stuff in the player
>  code. Code in the refereeing part would be actions.c, combat.c, move.c.
>  The player code would be ai.c, plan.c, task.c, mplayer.c, 
> iplayer.c, perhaps ui.c.
>  The dividing as the code is currently structured is between "actions"
>  which would be refeering code, and "tasks" which would be player 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.)

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.

>  The pathfinding is now implemented as part of the action code, and that
>  is wrong, it should be part of the player code, because the path that
>  is found is only ever hypothetical. 

Given the hypothetical nature, yes.

  Regards,
    Eric