From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32333 invoked by alias); 25 Nov 2003 13:20:27 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 32312 invoked from network); 25 Nov 2003 13:20:25 -0000 Received: from unknown (HELO acaymail.tel-pacific.com) (203.88.255.16) by sources.redhat.com with SMTP; 25 Nov 2003 13:20:25 -0000 Received: from leonardo (acay007133171.acay.com.au [203.7.133.171] (may be forged)) by acaymail.tel-pacific.com (8.12.8/8.12.8) with ESMTP id hAPDKIOq013095; Wed, 26 Nov 2003 00:20:20 +1100 Received: from garrone by leonardo with local (Exim 3.35 #1 (Debian)) id 1AOaGE-0000J9-00; Tue, 25 Nov 2003 21:17:34 +1100 Date: Tue, 25 Nov 2003 16:30:00 -0000 From: Peter Garrone To: Eric McDonald Cc: xconq7@sources.redhat.com Subject: Re: Major problem with the path code Message-ID: <20031125101734.GA1178@leonardo> References: <20031123101615.GB10513@leonardo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2003/txt/msg00919.txt.bz2 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