Re: Major problem with the path code

Re: Major problem with the path code

[Peter Garrone]

On Mon, Nov 24, 2003 at 07:49:30PM +0100, Hans Ronne wrote:
>  I'll look further tomorrow. Hope this helps. Could you tell me why it
> > shouldnt be a net function call from the task.c code as well as the ai,
> > would help,
> 
> Good work. And a good question. The main difference between the AI code and
> the kernel is not what it does, but rather where it lives and how it
> executes. Actually, a lot of code in the kernel (particularly in task.c and
> plan.c) is what I would call typical AI code. This reflects the fact that
> low level tactical decisions are handled there, while the AI code proper
> has more of a strategic role. I have moved some of the tactical stuff to
> the AI proper over the last few years, but there is still incomplete
> separation of functions between the AI and kernel.
> 
> The important distinction, however, is how the code is called and how it
> executes. For the AIs, each computer runs its local ai, if present (the one
> that belongs to the display side). In addition, the master program also
> runs all the leftover AIs that handle computer-only sides. Each time an AI
> does something that affects the game state, this has to be broadcasted
> since each AI runs only on one computer. The other computers must know what
> it did and update their states, or desynch will follow.
> 
> The kernel proper works in a completely different way. This code is run on
> all computers for all players at the same time. Therefore, there is no need
> to broadcast anything. You may wonder how different computers manage to
> stay in step with each other since random numbers are involved. The answer
> is that all computers in the game use the same random number seed, so they
> will always make the same "random" decisions.
> 
> The brief answer to your question is therefore that how a function is
> called determines whether it should be broadcasted or not. If it is called
> from run_local_ai (directly or indirectly) it is part of the AI code and
> should be broadcasted. If it is called from net_run_game, it should not.
> 
> Hope this was clear.
> 
> Hans
> 

Hello Hans, also Eric,
 This explains a lot and is quite stimulating. Unfortunately i am going
 to have to write a bit of an epistle explaining my position. Anyway
 your message is so good I am posting it to the list.

 The bad news first. I cant see how the current structure, particularly
 with pathfinding, should be done the way it is. In fact I have lost
 interest in it, so if in fact it is the "right" structure, you are
 going to have to expend some energy bringing me back on track.

 Some background. Many years ago I played a computerised Russian
 Campaign, and I couldnt stand the way the rules were fiddled by the
 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, 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.

 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.

 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. Also it ie expensive, so should not
 be replicated on all computers in a networked game. So have pathfinding
 called from task.c, but not move.c.

 This would require that move tasks be private to each player, and not
 broadcast over the network. So the logical thing to do is to stop
 broadcasting all tasks, only actions, and for each game loop to only
 process local ai players. Also the shared state should not include
 tasks or plans. Plans should be private, it should be irrelevant to the
 referee code what the plan for each unit should be, only what its
 actions are.

 Unfortunately with the existing structure, the easiest way to "fix" the
 current problem would be to stop the ai player calling the pathfinding
 algorithm, but I feel that would be counter-productive, so I am going
 to try implementing the converse, move the tasks and plans out of the
 shared network state, and only invoke the pathfinding from task level
 or higher. Then try to only broadcast actions.

 As a side note, if this separation does occur, then perhaps the AI code
 would be ripe for OO implementation, leaving the bulk of the current
 code, which is quite mature, in C.

 Cheers,
  Peter

Re: Major problem with the path code

[Eric McDonald]

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

Re: Major problem with the path code

[Peter Garrone]

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.

Re: Major problem with the path code

[Eric McDonald]

Hi Peter,

On Thu, 27 Nov 2003, Peter Garrone wrote:

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

No apologies necessary. I was painting with a fairly broad brush 
when I made those comments. I'm sure you have much more specific 
knowledge of the action/task/plan taxonomy than I do, since my 
only real exposure to it came while I was looking through the 
create/build code some time ago.

> The supply should conform to definite simple rules though.

The point-to-point movement, yes, I agree.

> But it should take account of enemy zoc, and terrain. 

I believe that support is already in the kernel, but I might have 
read somewhere that it wasn't working too well and so it was 
disabled. I haven't looked what the actual status of it is yet.

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

Agreed.

>But task/plans/doctrine is fuzzy ai
> behavior, so should not be in the "server".

Yes. Agreed.

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

I would also call your pathfinding code "AI". But I would call it 
"helper AI" rather than "machine player AI".

I've thought more about the supply code and the semantics of 
resupply since I wrote my earlier email to you. I think that I 
would now agree that doing cluster analysis and acting according 
to that would constitute a "helper AI" activity, rather than a 
core activity. I still have a concern that if we end up with an 
architecture where we do have separate client and server 
processes, then having a client's "helper AI for resupply" request 
materials movement by the server/referee could generate lots of 
traffic....

> We are in heated agreement here. 

:-)   Which is a nice change from the battlefield scene that the 
list became in the past few weeks.

>I hope I am not rehashing too much old
> ground.

I don't know. I haven't looked at the list archives in this 
regard. But, I personally think it is good to have this 
discussion, since it seems that we have both the will and the 
ability to act on it quite soon.

> recognise that such separation is a significant effort, so should wait
> for now.

For now. But if you're up to the task in the next release cycle, I 
am definitely willing to help.

  Best regards,
    Eric

Re: Major problem with the path code

[Hans Ronne]

>Hello Hans, also Eric,
> This explains a lot and is quite stimulating. Unfortunately i am going
> to have to write a bit of an epistle explaining my position. Anyway
> your message is so good I am posting it to the list.
>
> The bad news first. I cant see how the current structure, particularly
> with pathfinding, should be done the way it is. In fact I have lost
> interest in it, so if in fact it is the "right" structure, you are
> going to have to expend some energy bringing me back on track.

[ ... ]

> 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. Also it ie expensive, so should not
> be replicated on all computers in a networked game. So have pathfinding
> called from task.c, but not move.c.
>
> This would require that move tasks be private to each player, and not
> broadcast over the network. So the logical thing to do is to stop
> broadcasting all tasks, only actions, and for each game loop to only
> process local ai players. Also the shared state should not include
> tasks or plans. Plans should be private, it should be irrelevant to the
> referee code what the plan for each unit should be, only what its
> actions are.

I agree. I discussed this with Stan a long time ago. I remember that he had
some good arguments why plans and tasks also should be broadcasted, but I
am not sure to what extent they still apply today. They might have had to
do with performance, which is not an issue any longer. I will have to do
some email archeology to find out. Or maybe Stan can comment on this?

> Unfortunately with the existing structure, the easiest way to "fix" the
> current problem would be to stop the ai player calling the pathfinding
> algorithm, but I feel that would be counter-productive, so I am going
> to try implementing the converse, move the tasks and plans out of the
> shared network state, and only invoke the pathfinding from task level
> or higher. Then try to only broadcast actions.
>
> As a side note, if this separation does occur, then perhaps the AI code
> would be ripe for OO implementation, leaving the bulk of the current
> code, which is quite mature, in C.

I think this is an excellent thing to do, but post-7.5. I am a little
hesitant to reorganize the entire kernel just before a release.

Are you sure it's not just possible to patch the current path code so that
the synch error goes away? After all, it is only seen in some games
(standard, bellum). I have never seen in in advances or flattops so far,
despite extensive testing. And in the standard game, it is rarely triggered
unless you turn on "world-seen". This suggests to me that we are dealing
with a single function call that fails to broadcast properly in the ai part
of the current path code.

Hans

Re: Major problem with the path code

[Stan Shebs]

Hans Ronne wrote:

>
>>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. Also it ie expensive, so should not
>>be replicated on all computers in a networked game. So have pathfinding
>>called from task.c, but not move.c.
>>
>>This would require that move tasks be private to each player, and not
>>broadcast over the network. So the logical thing to do is to stop
>>broadcasting all tasks, only actions, and for each game loop to only
>>process local ai players. Also the shared state should not include
>>tasks or plans. Plans should be private, it should be irrelevant to the
>>referee code what the plan for each unit should be, only what its
>>actions are.
>>
>
>I agree. I discussed this with Stan a long time ago. I remember that he had
>some good arguments why plans and tasks also should be broadcasted, but I
>am not sure to what extent they still apply today. They might have had to
>do with performance, which is not an issue any longer. I will have to do
>some email archeology to find out. Or maybe Stan can comment on this?
>
OK, I've been trolled - or more accurately, had the lure bobbed up and down
in my face. :-)

All I remember ("my mind is going, I can feel it") is that if a task had to
broadcast all the actions it generated, it seemed like it would be a lot of
extra traffic for slow connections. The more synchronized state you have,
the more you can do locally. I also wasn't expecting to support much 
per-peer
variability at the plan/task level, because those are made at least partly
visible to the UI, and it would be good to have at least a modicum of
consistency by wiring it into the kernel.

These don't seem like really strong arguments though; I suspect everything
could be made to work OK with local plans and tasks.

Stan

Re: Major problem with the path code

[Peter Garrone]

On Mon, Dec 01, 2003 at 08:46:13PM -0800, Stan Shebs wrote:
> Hans Ronne wrote:
> 
> >
> OK, I've been trolled - or more accurately, had the lure bobbed up and down
> in my face. :-)
> 
> All I remember ("my mind is going, I can feel it") is that if a task had to
> broadcast all the actions it generated, it seemed like it would be a lot of
> extra traffic for slow connections. The more synchronized state you have,
> the more you can do locally. I also wasn't expecting to support much 
> per-peer
> variability at the plan/task level, because those are made at least partly
> visible to the UI, and it would be good to have at least a modicum of
> consistency by wiring it into the kernel.
> 
> These don't seem like really strong arguments though; I suspect everything
> could be made to work OK with local plans and tasks.
> 
> Stan
> 

The current structure has a wholesome consistent feel to it, in
that all these networked instances share the same enormous state at multiple levels,
against the thrust of modularity in software I suppose,
but its sort of awesome in its own right.

I suppose xconq is essentially an implementation of a language, the GDL.
Are plans, tasks, doctrines implicit in the GDL? The thrust of kernel
development will probably be in the direction of moving these concepts
outside of the inner core, leaving actions as the essential common element.

Regarding networking, if its possible to play something like xpilot
online, it should be possible to share actions in "realtime". Generally
xconq is categorised as a strategic turn-based game anyway, though in
reality it isnt. I think it has a big niche as a strategic turn-based
game. I would like to see a play-by-email mode, which is preety far from
what it does now, I believe.

Anyway, I am a long way from understanding it all, so I could be wrong,
 Regards,
  Peter

Re: Major problem with the path code

[Peter Garrone]

On Mon, Dec 01, 2003 at 08:46:13PM -0800, Stan Shebs wrote:
> Hans Ronne wrote:
> 
> >
> OK, I've been trolled - or more accurately, had the lure bobbed up and down
> in my face. :-)
> 
> All I remember ("my mind is going, I can feel it") is that if a task had to
> broadcast all the actions it generated, it seemed like it would be a lot of
> extra traffic for slow connections. The more synchronized state you have,
> the more you can do locally. I also wasn't expecting to support much 
> per-peer
> variability at the plan/task level, because those are made at least partly
> visible to the UI, and it would be good to have at least a modicum of
> consistency by wiring it into the kernel.
> 
> These don't seem like really strong arguments though; I suspect everything
> could be made to work OK with local plans and tasks.
> 
> Stan
> 

The current structure has a wholesome consistent feel to it, in
that all these networked instances share the same enormous state at multiple levels,
against the thrust of modularity in software I suppose,
but its sort of awesome in its own right.

I suppose xconq is essentially an implementation of a language, the GDL.
Are plans, tasks, doctrines implicit in the GDL? The thrust of kernel
development will probably be in the direction of moving these concepts
outside of the inner core, leaving actions as the essential common element.

Regarding networking, if its possible to play something like xpilot
online, it should be possible to share actions in "realtime". Generally
xconq is categorised as a strategic turn-based game anyway, though in
reality it isnt. I think it has a big niche as a strategic turn-based
game. I would like to see a play-by-email mode, which is preety far from
what it does now, I believe.

Anyway, I am a long way from understanding it all, so I could be wrong,
 Regards,
  Peter