From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18259 invoked by alias); 19 Sep 2004 23:44: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 18251 invoked from network); 19 Sep 2004 23:44:26 -0000 Received: from unknown (HELO rwcrmhc11.comcast.net) (204.127.198.35) by sourceware.org with SMTP; 19 Sep 2004 23:44:26 -0000 Received: from [192.168.181.128] (c-67-172-156-222.client.comcast.net[67.172.156.222]) by comcast.net (rwcrmhc11) with ESMTP id <20040919234425013008lqp2e>; Sun, 19 Sep 2004 23:44:25 +0000 Message-ID: <414E19B7.50402@phy.cmich.edu> Date: Mon, 20 Sep 2004 00:24:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) MIME-Version: 1.0 To: mskala@ansuz.sooke.bc.ca CC: Lincoln Peters , Xconq list Subject: Re: Using terrain coatings and existing code to model topography, weather, and vegetation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01190.txt.bz2 mskala@ansuz.sooke.bc.ca wrote: > Just a caution: This is a game. It's supposed to be fun. Before adding > any new complication, I think it's important to ask "Will this make the > game more fun?" There isn't only one right answer, since the answer > depends on who's answering, and on the context of the particular game in > which the feature will be used. But I think the question should be asked. Agreed. > That's one reason I said in one of my other messages that I think the > GIS/XConq translation process will need a lot of customization per map; > really, what it needs is customization *per game*. Some games will want > some of the data to be really detailed; others will want less of the data > and less detail in it. I think that in all cases the game's needs have to > come first, and they'll shape how the data is treated. Again, I agree. I think much of this can be controlled by predetermining how many bins someone wants in each categories, and which categories are even desired. Fewer bins -> coarser binning -> lesser detail -> more easily manageable from game design perspective. > I have similar reservations about Cooper's plan to make every hex its own > unique terrain type. I can see doing that as a work-around in order to > give every hex its own unique picture, but even that seems like a lot of > work and I think it would be a very special game that actually needed it. > It would be nice to instead do something like the recent "specify a > picture for an individual unit" patch to allow specification of a picture > for an individual hex, while leaving the hexes grouped into just a few > terrain types. This is reasonable. However, there is still the advantage that one terrain type per hex can be binned in multiple categories, which gives the ultimate in variety. But, again, you are right in that we should stop to ask how much matters to the player. > Clouds and unit altitudes sure > seem to be so cumbersome in the current interfaces as to be almost > unusable (if, in fact, they are implemented at all). Unit altitudes are currently ignored. Eric