This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Major problem with the path code
- From: Peter Garrone <pgarrone at acay dot com dot au>
- To: Eric McDonald <mcdonald at phy dot cmich dot edu>
- Cc: xconq7 at sources dot redhat dot com
- Date: Tue, 25 Nov 2003 21:17:34 +1100
- Subject: Re: Major problem with the path code
- References: <l03130300bbe6714d52a1@[212.181.162.155]> <20031123101615.GB10513@leonardo> <l03130300bbe6714d52a1@[212.181.162.155]> <l03130301bbe7fdde24ca@[212.181.162.155]>
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