RE: [Xenocide-programming] GeoData.h

[Vlad J. <vj...@au...>]

Hi chrisp,

I have put my answers inside your mail below.

Regards,
mamutas

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of
chr...@ju...
Sent: Tuesday, March 02, 2004 9:53 PM
To: xen...@li...
Subject: Re: [Xenocide-programming] GeoData.h




It wouldn't make sense to me either, just checking. :-)

I've been thinking along similar lines while working on this class.
However, I don't necessarily see these things being done by the actual
caller of GeoData, though.  What I was thinking was this would be an
adjacent class.  Whatever class ends up interfacing with GeoData also
interfaces with the rules class (GeoRules?).  
>> Yes, this is absolutely true. The caller of GeoData will need to
interface with other classes which will provide rules information on how to
interpret data. The GeoData class itself must not have any dependences on
the rules.

I was also thinking that we'll need to have a basic AI class for controlling
ufo and interceptor flight paths (GeoPilot?).  It doesn't have to be very
fancy.  Just add the right combination of randomness and logic to make it
believable.
>> This will be performed on the server side. There will be a separate class
for dynamic information. Remember, that GeoData class _must_ be concerned
only about static data of the globe. That is the data which does not change
in time: terrains, location of cities, country borders, etc. Everything
dynamic is out of scope of the GeoData. Crafts, bases, weather do not belong
to GeoData class.


I've been making progress on GeoData, and it seems that this is going to be
quite a massive series of classes.  When you take all of the data types I
defined (which is still not complete) and make them into full classes, you
get one massive header file.  
>> I would rather not to head that direction. Implementing all at once is
very big task. The beauty of OOP is that you can define functionality for a
very small scope of the program. My approach would be to do it in steps:
implement the most necessary data first and then add bells and whistles. So
far, I see the information about geo points as the most important. That
would include info about:
- terrain type (to determine whether we can build a base here. But remember
the determination will be done in other class!!); 
- continente (to determine cost);
- country (to determine major nationality of soldiers, but it is secondary
priority comparing to first two).

We may want to break this up into multiple headers and (sub) namespaces.
All of the functinality could still be encapsulated through GeoData.h  So,
we would have something like: GeoTerrainData.h GeoAirVehicles.h GeoSOI.h
(for Sites of Interest) and GeoRegions.h.  These would be included in
GeoData.h where the GeoData class would be responsible for interfacing with
all of this data.  Finally, I was thinking we may want to scale up the
continents/regions classes one step more and define a Planet class.  The
Planet class would be helpful to isoloate what's happening on Mars from
what's happening on Earth.  It would not help much with v1.0, but we may
have a real headache after 1.0 if we don't do this now.  Especially if we
want to do a full blown Mars vs. Earth scenario.
>> Not sure what benefit to have a Planet class. Remember, that GeoData has
no behaviour, but merely data server. I imagine it would read the data from
some file and then serve it to callers. The data will describe the planet
(we can have the Venus if we will want), not the code of GeoData.

One last questin.  Do we want to do some operator overloading on these
(GeoData) classes?  I get the impression we're going for the deluxe style
class implementations.  I can make these fully defined data types if that's
what's wanted.  It's not a big deal to me, but I think we may as well do
this now to allow for maximum flexibility.
>> Go with major simple classes first. Adding an operator or a method could
be always done later. If you are sure, we will need them add them now, but
don't focus on that entirely.

>> Great work! Thanks for contributions to the project!!

Regards,
chrisp 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004