From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 567 invoked by alias); 3 Dec 2003 21:43:22 -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 560 invoked from network); 3 Dec 2003 21:43:21 -0000 Received: from unknown (HELO acaymail.tel-pacific.com) (203.88.255.16) by sources.redhat.com with SMTP; 3 Dec 2003 21:43:21 -0000 Received: from leonardo (i122076211.rivernet.com.au [203.122.76.211] (may be forged)) by acaymail.tel-pacific.com (8.12.8/8.12.8) with ESMTP id hB3LgwOq030631; Thu, 4 Dec 2003 08:42:59 +1100 Received: from garrone by leonardo with local (Exim 3.35 #1 (Debian)) id 1AR7Qe-0000ca-00; Tue, 02 Dec 2003 21:06:48 +1100 Date: Wed, 03 Dec 2003 22:24:00 -0000 From: Peter Garrone To: Stan Shebs Cc: xconq7@sources.redhat.com Subject: Re: Major problem with the path code Message-ID: <20031202100648.GA2348@leonardo> References: <20031123101615.GB10513@leonardo> <3FCC1915.80203@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FCC1915.80203@apple.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2003/txt/msg00957.txt.bz2 Message-ID: <20031203222400.SWNgFdgpgn_bpeCJ3EOCVBd1PnmAAhneopyB_fVvjCc@z> On Mon, Dec 01, 2003 at 08:46:13PM -0800, Stan Shebs wrote: > Hans Ronne wrote: > > > > 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 > The current structure has a wholesome consistent feel to it, in that all these networked instances share the same enormous state at multiple levels, against the thrust of modularity in software I suppose, but its sort of awesome in its own right. I suppose xconq is essentially an implementation of a language, the GDL. Are plans, tasks, doctrines implicit in the GDL? The thrust of kernel development will probably be in the direction of moving these concepts outside of the inner core, leaving actions as the essential common element. Regarding networking, if its possible to play something like xpilot online, it should be possible to share actions in "realtime". Generally xconq is categorised as a strategic turn-based game anyway, though in reality it isnt. I think it has a big niche as a strategic turn-based game. I would like to see a play-by-email mode, which is preety far from what it does now, I believe. Anyway, I am a long way from understanding it all, so I could be wrong, Regards, Peter