Re: [Xenocide-programming] GeoData.h

[mamutas <mam...@ho...>]

Chrisp,

I understand where do you come from. I actually even expected a similar
reply. :)

I think that you attempt to put too much information into the one class.
That is very dangerous approach especially when information is not related
to each other tightly. OOP principles suggest implementation of very
granular objects - objects which are very selfcontained and very limited in
scope of data and functionality.

Actually, your ideas made me think, that whole GeoData approach is not
correct at all. We try to put too much data in it. It must be split in
multiple objects, which serve only specific data. Here is what coming to my
mind:
-- geographical information - terrain, continents, seas, etc.
-- political information - countries, regions (like Europe, North America,
etc.)
-- demographical information - cities, villages, cost of building a base,
etc.

So, when I need to know the landscape, I ask one class. There could be a
super class on top of all mentioned above, which will handle all data, but
we might wait till we see the need for it.

As regarding destroying cities and changing terrain, then nothing prevents
us to combine dynamic data with static. Let say, you have class with all
city information in the static storage. The same class has a dynamic
storage, which has higher priority than static. If one city got destroyed,
it is noted in dynamic storage, so when next time anyone asks about that
city, the dynamic data will be served. That dynamic data will be stored next
to game save stats. What do you say?

As for whole game state, then Cpt. Boxershorts is working on XML file. We
started this way, but eventually there will be a class which will work with
that XML file and represent all dynamic game data: research, bases, troops,
crafts, etc.

Regards,
mamutas
----- Original Message ----- 
From: <chr...@ju...>
To: <xen...@li...>
Sent: Saturday, March 06, 2004 11:55 PM
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