Adapting GIS data to Xconq

Adapting GIS data to Xconq

[Lincoln Peters]

I've been working on how to adapt the GIS data to Xconq, and have run
into a few problems that I thought need some discussion amongst the
other Xconq developers and players:

1. I don't think it's possible to un-define a terrain type once it has
been defined, so if, for example, a terrain module supported the use of
coatings to represent soil composition, there would be no way to disable
it (and thus free up some memory) in a game that doesn't need to deal
with soil composition.  How difficult would it be to implement such a
thing?

2. The NLCD system of classification used by the USGS treats developed
areas as a terrain type, whereas Xconq usually treats them as units.  In
scenarios such as Beirut and Gettysburg, I can see the advantages of
defining developed areas as terrain type(s), but games on a larger
scale, such as the Standard game, would not work if towns and cities
were treated as terrain types.  Perhaps the best solution would be to
define developed areas as terrain coating types, and allow developers to
make units that go on that terrain?  I'm really not sure.

3. If the terrain module is to define terrain types for developed areas,
how much detail would be required?  The NLCD system breaks it down into
three types: Low Intensity Residential, High Intensity Residential, and
Commercial/Industrial/Transportation.  I figure that the terrain module
should be able to handle infrastructure (various types of roads), and
depending on the answer to #2, at least one terrain type to represent
types of urban "terrain".


Eventually, I may want to find a way to synthesize realistic random maps
using this terrain module with its many facets (mostly implemented as
coatings), but that can wait.

---
Lincoln Peters
<sampln@sbcglobal.net>

There is a secret person undamaged within every individual.
		-- Paul Shepard

Re: Adapting GIS data to Xconq

[Eric McDonald]

Lincoln Peters wrote:

> 1. I don't think it's possible to un-define a terrain type once it has
> been defined, so if, for example, a terrain module supported the use of
> coatings to represent soil composition, there would be no way to disable
> it (and thus free up some memory) in a game that doesn't need to deal
> with soil composition.  How difficult would it be to implement such a
> thing?

Rather than attempting to deallocate something, I think it would be 
better to conditionally allocate it according to need. There is an "if" 
conditional GDL, but I have not attempted to use it. There is support 
for it in the code. I would suggest you try something like:

mygame.g:

...
(define USE_SOIL_COMP false)
...

omniterr.g:

...
(if USE_SOILCOMP
   (terrain-type soilcomp-k-lvl-0)
   ...
)
...

> 2. The NLCD system of classification used by the USGS treats developed
> areas as a terrain type, whereas Xconq usually treats them as units.  In
> scenarios such as Beirut and Gettysburg, I can see the advantages of
> defining developed areas as terrain type(s), but games on a larger
> scale, such as the Standard game, would not work if towns and cities
> were treated as terrain types.  Perhaps the best solution would be to
> define developed areas as terrain coating types, and allow developers to
> make units that go on that terrain?  I'm really not sure.

Interesting issue.

Eric

Re: Adapting GIS data to Xconq

[Lincoln Peters]

On Sun, 2004-10-31 at 10:39, Eric McDonald wrote:
> mygame.g:
> 
> ...
> (define USE_SOIL_COMP false)
> ...
> 
> omniterr.g:
> 
> ...
> (if USE_SOILCOMP
>    (terrain-type soilcomp-k-lvl-0)
>    ...
> )
> ...

This may be what I was looking for.  I'll give it a try.


I'll try to write a test module for the omniterr.g library to see if
it's at all playable.  However, in order for it to work as I envisioned
it, the axial-tilt bug and the coating display bugs will need to be
fixed.  Both of these bugs can be reproduced using the version of
omniterr.g on my website.

---
Lincoln Peters
<sampln@sbcglobal.net>

Matter cannot be created or destroyed, nor can it be returned without a receipt.

Re: Adapting GIS data to Xconq

[Eric McDonald]

Lincoln Peters wrote:
> On Sun, 2004-10-31 at 10:39, Eric McDonald wrote:
> 
>>mygame.g:
>>
>>...
>>(define USE_SOIL_COMP false)
>>...
>>
>>omniterr.g:
>>
>>...
>>(if USE_SOILCOMP
>>   (terrain-type soilcomp-k-lvl-0)
>>   ...
>>)
>>...

On second thought:

(if USE_SOIL_COMP)
(terrain-type solicomp-k-lvl-0)
...
(end-if)

> I'll try to write a test module for the omniterr.g library to see if
> it's at all playable.  However, in order for it to work as I envisioned
> it, the axial-tilt bug and the coating display bugs will need to be
> fixed.  Both of these bugs can be reproduced using the version of
> omniterr.g on my website.

I vaguely remember the axial tilt bug being mentioned. I do not remember 
what the exact description of the problem was. I do not think that I was 
ever given a test case for it. As far as coating display goes, I am not 
interesting in fixing it in the Tcl/Tk interface. I will deal with it in 
the SDL interface when the time comes.

Eric

Re: Adapting GIS data to Xconq

[Lincoln Peters]

On Sun, 2004-10-31 at 11:50, Eric McDonald wrote:
> On second thought:
> 
> (if USE_SOIL_COMP)
> (terrain-type solicomp-k-lvl-0)
> ...
> (end-if)

Got it.

> 
> > I'll try to write a test module for the omniterr.g library to see if
> > it's at all playable.  However, in order for it to work as I envisioned
> > it, the axial-tilt bug and the coating display bugs will need to be
> > fixed.  Both of these bugs can be reproduced using the version of
> > omniterr.g on my website.
> 
> I vaguely remember the axial tilt bug being mentioned. I do not remember 
> what the exact description of the problem was. I do not think that I was 
> ever given a test case for it.

You can use omniterr.g as a test case; just don't enable the "No axial
tilt" variant:

http://homepage.mac.com/lmpeters/omniterr.g

It would seem as if the illumination of the map behaves like a
spotlight, and when the axial-tilt is non-zero, the spotlight oscillates
north and south on what appears to be a sine wave.  This, of course, is
not what happens in the real world!

>  As far as coating display goes, I am not 
> interesting in fixing it in the Tcl/Tk interface. I will deal with it in 
> the SDL interface when the time comes.

Fair enough.

---
Lincoln Peters
<sampln@sbcglobal.net>

A plethora of individuals with expertise in culinary techniques contaminate
the potable concoction produced by steeping certain edible nutriments.