From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19073 invoked by alias); 20 Sep 2004 00:30:41 -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 19063 invoked from network); 20 Sep 2004 00:30:40 -0000 Received: from unknown (HELO smtp811.mail.sc5.yahoo.com) (66.163.170.81) by sourceware.org with SMTP; 20 Sep 2004 00:30:40 -0000 Received: from unknown (HELO ?192.168.1.101?) (sampln@sbcglobal.net@67.121.168.201 with plain) by smtp811.mail.sc5.yahoo.com with SMTP; 20 Sep 2004 00:30:39 -0000 Subject: Re: Using terrain coatings and existing code to model topography, weather, and vegetation From: Lincoln Peters To: mskala@ansuz.sooke.bc.ca Cc: Xconq list In-Reply-To: References: Content-Type: text/plain Message-Id: <1095640376.15989.25859.camel@localhost> Mime-Version: 1.0 Date: Mon, 20 Sep 2004 00:32:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01192.txt.bz2 On Sun, 2004-09-19 at 16:13, mskala@ansuz.sooke.bc.ca wrote: > On Sun, 19 Sep 2004, Lincoln Peters wrote: > > The more I think about this, the more I can see that, while writing the > > terrain module itself might not be such a difficult task (albeit a > > time-consuming one), re-writing the code for terrain coatings, as well > > as the existing weather code, will be a lot of work. On the other hand, > > when you consider the benefits that such a weather model could have on > > any existing or future game, I think that the return on such an > > investment would be enormous. > > 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. I would imagine that some of these details could be disabled in a particular game if necessary. I know that there are more than a few historical battles that were affected to a significant extent by weather. I also seem to recall that, in an old post I found in the archive, someone mentioned that voyages.g (and modules based on it, such as magellan.g) would be a lot more interesting if it could make the trip across the Atlantic as difficult as it was in real life. A better weather model would be an important first step toward that goal. > > My thinking is that as a player, I seldom if ever want to know (for > instance) how much potash is in the soil. At most, I might want to know > "this is fertile soil; that is unfertile soil". If there are more than > two or three levels of fertility, let alone more than one dimension of > fertility (nitrogen, potash, acidity...) then I'm just going to be > confused. I'm usually quite happy to have details abstracted. The level > of abstraction that's appropriate varies a lot depending on the individual > game. Some games are "strategic", some are "operational", some are > "tactical", and in general you see more detail and more complication at > the tactical level and less at the strategic level. In most cases, this kind of detail would be handled in the background. Perhaps no game would ever want to implement multiple dimensions of soil fertility in a game, but if nothing else, I could see it being used to build a more realistic system for creating random maps. > > 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. This could probably be handled by using variants in the terrain module, although it may be necessary to add a GDL method to enable or disable variants when including a module. > > 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. Ideally, you could specify custom pictures for just a few > hexes, or for every hex, according to taste - that way you could deal with > a wide range of different game needs. I was hoping that a terrain/weather mechanism like the one I described would allow for enough detail that one would not have to make each cell have a unique terrain-type. And, as you said, it should be possible to allow different cells with the same terrain-type to have different images, since the same thing can now be done with units. > > I also wonder about the user interface issues with extremely detailed > maps. I'm not sure how coatings are currently handled, but I'm guessing > that dealing with them may be cumbersome. 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). Temperatures seem to > be at least partially implemented, but when I've played games that use > them I've always ended up turning off the temperature display because it's > just too confusing. I'm not looking forward to what I'll have to do as a > player to stay on top of what's going on with four layers of coatings, if > they're all game-play significant. Weather maps are notorious for being cumbersome and difficult to read, but they *are* easier to read than the information given on the Xconq map. I can easily see temperature being displayed in isotherms (i.e. areas of a particular temperature would be shown in the same manner as elevations) as a way to clean up the interface significantly. Winds are trickier; wind in Xconq is not based on air pressure (as it is in real life), so you couldn't handle it by drawing isobars unless we were to re-write the wind code. As for clouds, I think that it would be easiest to represent them using the isometric code (or a variant thereof) to show them in some sort of 3D space. > > Anyway, if you can think of a game you'd like to build that would actually > use this level of weather simulation, then by all means go for it. My goal with this terrain/weather model is to provide a framework for the GIS data (which apparently includes weather statistics) so that it could be added to Xconq in as much exquisite detail as possible. I could see myself using it in knightmare.g, and I kind of suspect that Elijah could find a use for it as well. Even if the weather stuff I describe doesn't get implemented, some of the terrain coating things, such as implementing vegetation as one or more coating types, would add a lot of flexibility to Xconq. --- Lincoln Peters OKAY!! Turn on the sound ONLY for TRYNEL CARPETING, FULLY-EQUIPPED R.V.'S and FLOATATION SYSTEMS!!