Re: XconqGIS Reply Summary (Ironically Long)

[Lincoln Peters <sampln at sbcglobal dot net>]

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