From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21050 invoked by alias); 2 Dec 2003 04:46:11 -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 20994 invoked from network); 2 Dec 2003 04:46:06 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 2 Dec 2003 04:46:06 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id hB24k4Lh027619 for ; Mon, 1 Dec 2003 20:46:04 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 1 Dec 2003 20:46:03 -0800 Received: from apple.com ([17.112.74.134]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id hB24jSww000947; Mon, 1 Dec 2003 20:45:29 -0800 (PST) Message-ID: <3FCC1915.80203@apple.com> Date: Tue, 02 Dec 2003 11:20:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hans Ronne CC: Peter Garrone , xconq7@sources.redhat.com, mcdonald@phy.cmich.edu Subject: Re: Major problem with the path code References: <20031123101615.GB10513@leonardo> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003/txt/msg00947.txt.bz2 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