From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16865 invoked by alias); 4 Jan 2005 17:24:34 -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 16287 invoked from network); 4 Jan 2005 17:24:25 -0000 Received: from unknown (HELO gouda.execulink.net) (199.166.6.56) by sourceware.org with SMTP; 4 Jan 2005 17:24:25 -0000 Received: from opal.ansuz.sooke.bc.ca (dsl113.rba1.pppoe.execulink.com [66.203.174.114]) by gouda.execulink.net (8.11.6/8.11.6) with ESMTP id j04HO6r24573; Tue, 4 Jan 2005 12:24:06 -0500 Date: Tue, 04 Jan 2005 17:24:00 -0000 From: mskala@ansuz.sooke.bc.ca To: Lincoln Peters cc: xconq-developers@lists.sourceforge.net, xconq7 Subject: GIS and navigable rivers In-Reply-To: <1104633807.402.231.camel@localhost.localdomain> Message-ID: References: <41D64A45.4030403@phy.cmich.edu> <1104563991.402.156.camel@localhost.localdomain> <41D6D054.6030006@phy.cmich.edu> <1104613760.402.175.camel@localhost.localdomain> <41D71826.4060506@phy.cmich.edu> <1104633807.402.231.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005/txt/msg00016.txt.bz2 On Sat, 1 Jan 2005, Lincoln Peters wrote: > developed areas as part of the terrain, whereas Xconq would usually > treat them as units. As I think about this, the solution would > ultimately depend on the scale of the game and the resolution of the > 2. Handling rivers from GIS data: Should they be cell terrain, border I think both these issues illustrate my point that GIS->game conversion really depends on the game. If we're going to do it automatically, I think we should give the designer a lot of control to specify just what conversions should be done. > like Advances, Ancient Greece, or Ancient Rome, you'd probably want to > set up rivers so that they would simultaneously impede movement of land > units and allow movement of certain naval units. As far as I can tell, There's some discussion of the navigable-rivers issue in the designer's manual; if you make them borders so that they can impede land movement, then it's tricky for ships to travel along them, and if you make them connections so that ships can travel along them, they won't impede land movement. The documentation suggests making a chain of alternating lake hexes and river borders, and using the special "border slide" movement mode. Another thing one could do, although it's something of a hack, is to represent a river by a connection type *and* a border type, going in lines parallel to each other; the graphics could be designed either to make one of those invisible, or to make the two of them together look like a single river. That's actually quite an attractive idea; I think I'll try to find some time to design a sample game illustrating it. I think it would be worth researching what the old-style tabletop hex-grid games did about this issue, since they would have faced it too. The ones I'm familiar with did it in a makeshift way by having rivers be what XConq calls connections, and having the land within a cell containing a river be split into two chunks, with players required to keep track of which bank a given unit is on. I think that would be prohibitively difficult for XConq because it means changing the topology of the grid entirely. But there've got to be games that handled it in a more computer-friendly way. -- Matthew Skala mskala@ansuz.sooke.bc.ca Embrace and defend. http://ansuz.sooke.bc.ca/