From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15603 invoked by alias); 20 Aug 2004 03:29:59 -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 15596 invoked from network); 20 Aug 2004 03:29:58 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org with SMTP; 20 Aug 2004 03:29:58 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i7K3V5eE003474 for ; Thu, 19 Aug 2004 20:31:05 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Thu, 19 Aug 2004 20:29:57 -0700 Received: from apple.com ([17.219.205.8]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id i7K3TeOa003165; Thu, 19 Aug 2004 20:29:40 -0700 (PDT) Message-ID: <4125702A.1030009@apple.com> Date: Fri, 20 Aug 2004 15:26:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Eric McDonald CC: Hans Ronne , xconq7@sources.redhat.com Subject: Re: Clearing the Air (long) References: <412556EF.80401@phy.cmich.edu> In-Reply-To: <412556EF.80401@phy.cmich.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00969.txt.bz2 It's almost never a good idea to guess that there must be secret evil intent, and react as if that were really the case. There are about a half-dozen interconnected ideas being kicked around, and I think everybody is operating with different assumptions, some of which have probably not been written down yet. To put things in perspective, this is a depth of modelling that the professional game designers don't even want to get into; if you "deconstruct" an A-list game, you'll see that they carefully restrict the rules, for instance to avoid stacks of units entirely by making each unit have a physical size in a fine-grained coordinate system. And of course the rules themselves have minimal variability. One of Xconq's attributes is a high degree of flexibility, but as we've seen many times, it can be difficult to take advantage of it; try something really exotic in a game module, and interfaces are unintelligible, the AI doesn't know what to do, etc. So the goal is to find a set of parameters that model the kinds of games you want to be able to play, but that means that you need to start with an agreement about what those games are. Just a "might want to" or "would be nice" is not enough; Xconq is littered with stubbed-out code that started with that thought and was never finished. Do we want to enhance the standard game, add new tactical possibilities to the panzer game, design new games that weren't possible before, what? After all, this whole discussion started with Hans just trying to fix bugs... Stan