From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23645 invoked by alias); 25 Nov 2003 17:05:56 -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 23636 invoked from network); 25 Nov 2003 17:05:52 -0000 Received: from unknown (HELO garm.central.cmich.local) (141.209.15.48) by sources.redhat.com with SMTP; 25 Nov 2003 17:05:52 -0000 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Nov 2003 12:05:43 -0500 Received: from localhost (unknown [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 26F2C7001D; Tue, 25 Nov 2003 12:05:41 -0500 (EST) Date: Wed, 26 Nov 2003 00:23:00 -0000 From: Eric McDonald To: Peter Garrone Cc: xconq7@sources.redhat.com Subject: Re: Major problem with the path code In-Reply-To: <20031125101734.GA1178@leonardo> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 25 Nov 2003 17:05:43.0860 (UTC) FILETIME=[5CA90740:01C3B376] X-SW-Source: 2003/txt/msg00921.txt.bz2 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