XconqGIS Reply Summary (Ironically Long)

XconqGIS Reply Summary (Ironically Long)

[D. Cooper Stevenson]

Dear Eric, Lincoln, Matthew, & Xconq mailing listers;

For the impatient, go here:
http://wiki.xconqgis.org/index.php?GeologicalInformationSystemInformationGuide

I'm condensing each of your feedback in the same email so that we're all
on the same page. I'll indicate who's talking where, kind of like a
script document.

> Lincoln Peters: Welcome to the list. This sounds like an exciting
project, and I think we would open up countless possibilities for new
games.

Thanks! 

> Matthew Skala: I've been working on making such a map for
Antarctica...a preliminary version is at
http://ansuz.sooke.bc.ca/temporary/map.g

I posted your terrain map to the Wiki here: wiki.xconqgis.org. This is
like fresh muffins on a Sunday morning. Basically, Cooper: Can we do GIS
stuff? Matthew: Yeah, I did it. Here you go...

> Matthew Skala: Most of the data I got came as ASCII lists of points
with decimal lat/long coordinates. I wrote some Perl scripts to
translate the ASCII lat/lon coordinates into hex-grid coordinates, take
a vote of surface types within each hex grid, and then assign the cell
the majority terrain type of points within the cell. There were a few
other subtleties which, again, I don't remember off the top of my head
but have written down to go into the document that will eventually
accompany the game module.

  Would you _please_ _please_ post and document this? I'm asking you-no
strike that-I'm begging you to! :)  This is _exactly_ spot on.

  I'll tell you what. I'll pull down the sattellite images from the USGS
and parse the graphics if I possibly can. If I get stuck I'll let you
know.

  So what you get is a spectacular looking satellite view of Antarctica
utilizing your coordinate system interface with Xconq and Xconq's game
play. By documenting what I do, I hope that we can "can" the solution
(within the limits Matthew hinted at) for the creation of other theaters
by pulling together the information we need to "feed to" Xconq. 

>Lincoln Peters: I suspect that Xconq's existing terrain libraries might
need to be modified (or a new, separate terrain library be written from
scratch) to accept the data you describe.

  Agreed. I am divided on this. On one hand, writing a GIS library to
interface with the Xconq kernel will be no small task. Also, Matthew
seems to have written a coordinate system that may just do the trick. On
the other, I beckon one of the fundamental laws of Unix
http://www.faqs.org/docs/artu/:

  "Design and build software, even operating systems, to be tried early,
ideally within weeks. Don't hesitate to throw away the clumsy parts and
rebuild them."

  This does not mean to imply that I think the library is clumsy. I
frankly think otherwise for it's purposes. I don't know if it would be
better for the libraries to be modified of if writing them from scratch
is necessary. I pray for the former. 

>Lincoln Peters: I have a few questions about the GIS data: 1. Does it
track vegetation separately from terrain?

  It sure does. Get a load of this:
http://wiki.xconqgis.org/index.php?GeologicalInformationSystemInformationGuide

  I know too that GIS permits ASCII dumps of individual layers. I'm not
clear on all aspects; I'm a GIS newbie.

>Lincoln Peters: 2. Does it provide meteorological statistics, such as
average rainfall, wind patterns, etc.? I can see that a game based based
on something as detailed as GIS data might want to include such
statistics...

  The tutorial does mention rainfall statistics. I believe this is the
case. I tried to test this, but my tutorial data did not include the
rainfall rastering layer that they mentioned in the tutorial.

>Lincoln Peters: 3. Does it provide any detailed information about area,
such as soil composition or specific kinds of vegetation?

  Yes. This includes soils.Kfactor, soils.Tfactor, (whatever these mean)
soils.ph, and soils.range. Also included is a separate layer for
vegetation.

>Lincoln Peters: There are a few technical difficulties involved with
such a project that I can see already. One thing that comes to mind is
its representation of rivers.

  You got me here. I'm an Xconq map newbie. I will be documenting things
as I learn...


Cooper Stevenson: I am working to build an aggressive new image set for
XCONQ.

Eric McDonald: Excellent.

  Thank you!

  Eric has more terrain map insight specific to Xconq. I have to look at
this more before I can give intellegent dialog. I will do this soon; I
hope that I have provided a good start.

> Matthew Skala: . If you or others want to talk about making Xconq maps
from GIS data in a serious way, I'd be interested in participating.

  Thank you.

> Matthew Skala: It's also possible that we might even put together a
paper about it that we could publish at a conference or something, since
doing it right will actually involve doing some new research on GIS that
the GIS research community would probably find interesting.

  I wholeheartedly agree. Assuming that I am not too busy actually
_writing_ the thing, I absolutely would be happy to pull together the
documentation from the various sources, pull them together, and post.

  Also, before you read the following, note that I am a _die_hard_
optimist. I think the following could be done with a lot of work. I
suspect that some of you have thought too along these lines:

  What would happen if the units you selected were actual human beings
connected to the main server via the Internet? To the individuals, the
game looks like a 3D game similar to Castle Wolfenstein: Enemy
territory. 

  So when you select troops at the batallion view and give them
waypoints to follow into battle, that looks to them like a green arrow
on the horizon for them to go. The best part is that there are human
units on the other team trying to do the same thing to you.

   Now, combine that with a 3D battalion view, generated in real time.
When the battalion commander selects tanks, he's selecting _real_
players. 
  Also, every game client reports the user's position back to the main
server their position as GIS data.


-Coop

-- 
--------------------------------------------------------------
| Cooper Stevenson        | Em:  cooper@gencom.us            |
| GenCom                  | Ph:  541.924.9434                |
| "Working For IT"        | Www: http://www.gencom.us        |
--------------------------------------------------------------

Re: XconqGIS Reply Summary (Ironically Long)

[Eric McDonald]

D. Cooper Stevenson wrote:

> By documenting what I do, I hope that we can "can" the solution
> (within the limits Matthew hinted at) for the creation of other theaters
> by pulling together the information we need to "feed to" Xconq. 

Good. This is the best direction to head in, I think.

> need to be modified (or a new, separate terrain library be written from
> scratch) to accept the data you describe.
> 
>   Agreed. I am divided on this. On one hand, writing a GIS library to
> interface with the Xconq kernel will be no small task. Also, Matthew
> seems to have written a coordinate system that may just do the trick. 

If you have not alrady read this:
   http://sources.redhat.com/xconq/manual/xcdesign_33.html#SEC145
then you might find it helpful. Actually, it is probably a good idea to 
start reading from:
   http://sources.redhat.com/xconq/manual/xcdesign_33.html#SEC142

As a caveat, since you are new to the list, it often occurs that Xconq 
documentation was not updated by other developers when they added, 
changed, or removed features, and so, almost any part of the 
documentation should be read with a grain of salt.

>>Lincoln Peters: There are a few technical difficulties involved with
> 
> such a project that I can see already. One thing that comes to mind is
> its representation of rivers.
> 
>   You got me here. I'm an Xconq map newbie. I will be documenting things
> as I learn...

Rivers, vegetation, elevation, etc... all apply to different aspects of 
the game. It would seem likely that when one was analyzing the data for 
each hex region in the hex grid overlay that not only would the hex be 
binned according to elevation, but to these other categories as well. 
And so, each hex <--> terrain type would end up belonging to multiple 
bins, one in each category (elevation, vegetation, etc...).

Elevation speaks to the movement rules (and possibly things such as 
vision range modifiers). Vegetation speaks to visibility, and possibly 
to materials storage/production. Rivers are interesting; the way to 
approach them might be to restrict water unit movement rules according 
to how riverine the terrain is and the size of the units (boats vs. 
ships, essentially).

One thing to keep in mind is that if each hex on the map corresponds to 
an unique terrain type (so as to have an unique terrain image), that 
Xconq presently only supports up to 32767 terrain types. Probably this 
is not a big worry since even a 100x100 map (10,000 hexes) is 
decently-sized. It looks like you get up to a 181x181 map with a 1:1 
correspondence between terrain type and hex; that it quite large given 
typical unit mobilities in most Xconq games.

   Also, before you read the following, note that I am a _die_hard_
> optimist. I think the following could be done with a lot of work. I
> suspect that some of you have thought too along these lines:

Yes. One of the problems with this project is that we have too few 
developers and too many ideas that have accrued. Nothing wrong with 
ideas, including ambitious ones, but it actually takes development 
effort to make them come into being....

Eric

Re: XconqGIS Reply Summary (Ironically Long)

[mskala]

>   Would you _please_ _please_ post and document this? I'm asking you-no

I grabbed some files and posted them in a tarball
here:  http://ansuz.sooke.bc.ca/temporary/antar-map.tgz

I'll attempt to post them in the Wiki as well, split into several pages in
a semi-sensible way.  There's other stuff on my computer at school, which
I'll go take a look at another day.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: XconqGIS Reply Summary (Ironically Long)

[Lincoln Peters]

On Sun, 2004-09-19 at 11:11, D. Cooper Stevenson wrote:
> >Lincoln Peters: I suspect that Xconq's existing terrain libraries might
> need to be modified (or a new, separate terrain library be written from
> scratch) to accept the data you describe.
> 
>   Agreed. I am divided on this. On one hand, writing a GIS library to
> interface with the Xconq kernel will be no small task. Also, Matthew
> seems to have written a coordinate system that may just do the trick. On
> the other, I beckon one of the fundamental laws of Unix
> http://www.faqs.org/docs/artu/:
> 
>   "Design and build software, even operating systems, to be tried early,
> ideally within weeks. Don't hesitate to throw away the clumsy parts and
> rebuild them."

More specifically, I'm thinking that a new terrain module might need to
be written.  You've probably noticed that in different games, terrain
sometimes looks the same, but not always.  This is because most games
use either stdterr.g or advterr.g to define their terrain types, or they
use a custom terrain library.

> 
>   This does not mean to imply that I think the library is clumsy. I
> frankly think otherwise for it's purposes. I don't know if it would be
> better for the libraries to be modified of if writing them from scratch
> is necessary. I pray for the former. 

A new terrain module capable of handling the data you describe would
certainly be more complicated than any of the existing terrain modules,
and would most likely require some modifications to the kernel, but I'm
sure that it can be done.  It might even be easier than it sounds, but I
can't make any promises.

> 
> >Lincoln Peters: I have a few questions about the GIS data: 1. Does it
> track vegetation separately from terrain?
> 
>   It sure does. Get a load of this:
> http://wiki.xconqgis.org/index.php?GeologicalInformationSystemInformationGuide

Interesting.

> 
>   I know too that GIS permits ASCII dumps of individual layers. I'm not
> clear on all aspects; I'm a GIS newbie.

I'm even more of a GIS newbie than you are.

I suspect that, if the GIS data allows you to track vegetation
separately from topography, it would make sense to use a new terrain
module capable of doing that.  Specifically, I'm thinking that most of
the terrain features (soil composition, vegetation, etc.) would be
implemented as terrain coatings.  If you look at the message "Bug in
day/night code?" that I posted yesterday, you'll find a pre-alpha
version of such a terrain module.

> 
> >Lincoln Peters: 2. Does it provide meteorological statistics, such as
> average rainfall, wind patterns, etc.? I can see that a game based based
> on something as detailed as GIS data might want to include such
> statistics...
> 
>   The tutorial does mention rainfall statistics. I believe this is the
> case. I tried to test this, but my tutorial data did not include the
> rainfall rastering layer that they mentioned in the tutorial.

I hadn't considered rainfall (I just considered the weather features
Xconq currently supports), but now that you mention it, I can see that
it would be important in modeling any other weather features.

> 
> >Lincoln Peters: 3. Does it provide any detailed information about area,
> such as soil composition or specific kinds of vegetation?
> 
>   Yes. This includes soils.Kfactor, soils.Tfactor, (whatever these mean)
> soils.ph, and soils.range. Also included is a separate layer for
> vegetation.

I'd guess that soils.Kfactor is a measure of the potassium in the soil. 
I'm not sure about soils.Tfactor (it doesn't seem to correspond to
anything on the periodic table the way that "K" does); I'll have to look
into that.

> 
> >Lincoln Peters: There are a few technical difficulties involved with
> such a project that I can see already. One thing that comes to mind is
> its representation of rivers.
> 
>   You got me here. I'm an Xconq map newbie. I will be documenting things
> as I learn...

To some extent, the implementation of rivers would depend on the scale
of the game.  As for implementing them as borders or connections, that
would likely depend on how they are used in a game, unless it is
possible for a game designer to make a border behave like a connection
and vise versa in the case of specific units.

I was hoping that someone else on the list will chime in on this, and it
looks like Eric has done so.

> 
> 
> Cooper Stevenson: I am working to build an aggressive new image set for
> XCONQ.
> 
> Eric McDonald: Excellent.
> 
>   Thank you!
> 
>   Eric has more terrain map insight specific to Xconq. I have to look at
> this more before I can give intellegent dialog. I will do this soon; I
> hope that I have provided a good start.

And I see that he has commented about the rivers issue.  I'm sure that
there are other people who could provide useful information about the
terrain code, but it looks like they haven't jumped in yet.

>   Also, before you read the following, note that I am a _die_hard_
> optimist. I think the following could be done with a lot of work. I
> suspect that some of you have thought too along these lines:
> 
>   What would happen if the units you selected were actual human beings
> connected to the main server via the Internet? To the individuals, the
> game looks like a 3D game similar to Castle Wolfenstein: Enemy
> territory. 
> 
>   So when you select troops at the batallion view and give them
> waypoints to follow into battle, that looks to them like a green arrow
> on the horizon for them to go. The best part is that there are human
> units on the other team trying to do the same thing to you.
> 
>    Now, combine that with a 3D battalion view, generated in real time.
> When the battalion commander selects tanks, he's selecting _real_
> players. 
>   Also, every game client reports the user's position back to the main
> server their position as GIS data.

This is an interesting idea, but I think that it would require a lot
more work than anything you've suggested so far.  Probably the most
important first step would be to improve the isometric view code (which
I think could be very useful when trying to determine line-of-sight,
e.g. when you want to set up an artillery unit so that it has
line-of-sight to its target).  Maybe if it was re-implemented with
OpenGL...

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

Lies!  All lies!  You're all lying against my boys!
		-- Ma Barker