RE: [Xenocide-programming] Tech Tree XML layout

[Cpt. B. <cpt...@te...>]

Hi Mamutas,

	You're right, it would be simpler computationally to keep separate
variables.  How about an actual enumerated state?  I see topics as having
four states:  Unresearched, In Progress (has some hours put into, but not
currently being researched), Active (currently being researched), and
Complete.

Would it be better to have it as attributes or elements?  I'd like to avoid
overloading the topic node with too many attributes.  What do you think of
something like one of these this for each topic:

<status> <!-- individual fields -->
	<started>False</started> <!-- has research begun on this topic? -->
	<completed>False</completed> <!-- has this topic been completely
researched? -->
	<hours>0</hours> <!-- hours researched -->
</status>

or

<status> <!-- state enum -->
	<state>Unresearched</> <!-- values ("Unresearched"|"In
Progress"|"Active"|"Complete") -->
	<hours>0</hours> <!-- hours researched -->
</status>

I think we will need a <location/> tag as well...while researched knowledge
is global (shared among the bases), when you open a saved game, the topics
that were actively being researched should still be active at the same lab
as when you saved.  It could just be however the facility is referenced for
the baseview.

-The Captain

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of
Mamutas Plaukotas
Sent: Thursday, January 01, 2004 10:12 AM
To: 'Cpt. Boxershorts'; 'Vlad Judys';
xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout


Hello Captain,

See my answers below.

Regards,
Mamutas

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...] On Behalf Of Cpt.
Boxershorts
Sent: Monday, December 29, 2003 12:28 AM
To: Vlad Judys; xen...@li...
Subject: RE: [Xenocide-programming] Tech Tree XML layout

Hi Mamutas,

	You're right, this layout is primarily designed for program
initialization,
rather than active games.  I agree, I think it could work  as a save game
too (and it's better to have just the one format to parse).  Is the research
tree going to be loaded into some form of database table, or just kept in
xml node format?

<mamutas>I think that it would be fine to keep loaded XML in the DOM of the
parser. The object which will load and provide interfaces to the DOM (fro
example XNet Data Loader object) will know where and how to access the
required data. And the XML will be parsed and validated once during the
loading and then it will be kept in the memory. I don't see any advantages
to convert XML to some internal representation, unless there will be
significant performance issues.</mamutas>

For the saved game version, rather than several fields, why just a single
numeric 'amount completed' field?  As I see it, knowing whether a topic has
been researched is the most important (must be quick/easy to find out)
factor.  'amount completed' has values ranging from zero to the topic's
researchtime property. This way, we keep the exact number of hours
researched, and finding out if the topic is complete is a simple calculation
('researchhours' = 'amountcompleted').

Possible values for 'amountcompleted' work out as follows:

0 = Not started.
1 to (topic.researchhours - 1) = Started, but incomplete.
topic.researchhours (max value) = complete

<mamutas>Yes, it is possible to use just one variable, but as you mentioned
than you need to keep in mind that '1' for 'just started topics'. It will
save us some memory, but will add a code complexity. I would rather have
explicit flags in this case, just to keep code clear.</mamutas>

Just to simplify it, maybe 'completed' status should be ('researchhours' <=
'amountcompleted'), rather than equals.  That would save alot of headaches
in calculating research hours.

<mamutas>This is valid comment. It is always better not to use exact
equality with real numbers. I learned that my first year in programming. :)
</mamutas>

Would it need a variable for where (which lab/base it's being researched at)
as well?  It might need to wait until the savegame layout for bases is done,
although we could always just put in a stub.

<mamutas>Not sure about that yet, but something like that should be
necessary as research tree is shared between all bases. In the same motion
we can think about storing number of scientist allocated and other things,
but I would leave it to later times to decide.</mamutas>


To answoer your other questions, what I sent out is not really for xenocide
per se...it's just a sample of the layout applied to the x-com tree so that
everyone has a common frame of reference.  The xenocide tree already has a
couple of differences in it (a 'Plasma Technology' node, for one).  Once the
format is settled, I'll write a xenocide version of the simple tree, as well
as a few variations I'd like to suggest.  The main reason I undertook this
was to show off the variants discussed in the 'Technology' workshop on a
webpage (it seemed easier to use the official layout than make one of my
own, and then I discovered it was incomplete).

I hate to say this, but I managed to lose the version I sent out :P Could
you please send me a copy back? Thanks!

<mamutas>:) The copy is attached.. </mamutas>

-The Captain

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003