RE: [Xenocide-programming] GeoData.h

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Seems to me that we can do the swappable terrain type thing AND 
implement a seperate class for save data.  If we try to throw too much 
gamestate into geodata it will wind up with a bunch of stuff that 
doesn't relate.  Remember save games have to include player name, 
soldier names, research states, funding, etc.

The changeable terrain thing (I think) is simply a matter of granularity 
of tiles.  The geodata object in memory during the game has to know what 
terrain type each tile of the world is.  This can of course be changed 
by a scripting choice or mod dll (or post 1.0 code we write).  So long 
as it doesn't store terrain type as continent-sized chunks (maybe city-
sized?) a mod can replace tiles dynamically as the situation warrants.

That is the way I see it, anyway.  Someone correct me if I have anything 
wrong, as I'm just getting my brain around the project.

-Thalo

-----Original Message-----
From: chr...@ju...
To: xen...@li...
Date: Sun, 7 Mar 2004 05:55:13 GMT
Subject: RE: [Xenocide-programming] GeoData.h

> 
> 
> We also may want to think about how we want to save the state of the
> game.  We'll want to be able to save all crash/base/terror locations
> and and the locations of any aircraft in the air.  This is why I
> initially put all of this in GeoData.  I was thinking of this as being
> the class that essentially stored the state of the game.  So this state
> could be saved and reloaded with ease.  Of course starting a new game
> wouldn't require all of this other data.  But, saving a game in
> progress will.  Doing it this way would also allow the terrain data to
> be dynamic.  This may sound silly, but I can think of situations where
> it could be very beneficial.  Imagine the type of emotional impact that
> seeing Earth's cities destroyed would have.  Near the end of the game
> the Aliens could be given the ability to destroy entire cities or
> regions.  Of course this would have large economic and political
> impacts that would make the game much more challenging and engaging. 
> Storing the data this way would allow us to swap terrain types to 'city
> ruins' or 'nuclear wasteland.'  I think we could take the concept of
> putting the Earth in danger much much farther.  I know this is all post
> v1.0, but I think we should be creating an architecture designed to be
> easily extendable for v2.0.  That way 2.0 isn't a patch job or rewrite.
>  That's why I think we should store this data in GeoData.  It doesn't
> mean that every time an air vehicle's position changes that GeoData
> gets updated.  The save routine can do this at save-time, and the
> entire GeoData class can then be written to disk.  We could do the same
> thing with BattleScape using a BattleData class.
> 
> -chrisp
> 
> ---------- Forwarded Message ----------
> I imagine GeoData as a class to provide static data about the planet.
> The
> data itself will be stored in some data file, which will be tied to the
> image we present on the globe. If you replace the image and the data
> file,
> you get another planet.
> 
> No data must be hardcoded in the class itself.
> 
> Does it make sense to everyone?
> 
> Regards,
> mamutas
> 
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
> Cpt.
> Boxershorts
> Sent: Saturday, March 06, 2004 1:37 PM
> To: xen...@li...
> Subject: RE: [Xenocide-programming] GeoData.h
> 
> Is GeoData.h going to be hardcoded for each planet represented, or will
> it be data-dependant?
> 
> -The Captain
> 
> -----Original Message-----
> From: xen...@li...
> [mailto:xen...@li...] On Behalf Of
> Vlad Judys
> Sent: Saturday, March 06, 2004 10:59 AM
> To: chr...@ju...; xen...@li...
> Subject: RE: [Xenocide-programming] GeoData.h
> 
> 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
>  
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
> 
> 
> ---
> Incoming 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
>  
> 
> ---
> 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
>  
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
> 
> 
> ________________________________________________________________
> The best thing to hit the Internet in years - Juno SpeedBand!
> Surf the Web up to FIVE TIMES FASTER!
> Only $14.95/ month - visit www.juno.com to sign up today!
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming