This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Major problem with the path code


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]