Re: [Xenocide-programming] Tech Tree XML layout

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

Hi Cpt.

My suggestion was just one of many options. Having a enumerator is fine too,
as long as our validator will catch invalid values there. I do not remember,
can you enforce that in DTD? I think you can do it with attributes, but not
with tag values, right? If that is true, then attribute for state looks like
a better option for me. Also, I don't think we need to have both 'In
Progress' and 'Active', as the difference in them will be the number of
scientists allocated, right? But that information is not going to be stored
in that XML, but in some other places. We should avoid duplicate storage of
the same meaning in two different places, therefore I suggest to combine
those two states in one and rely on number of scientists.

Regards,
mamutas

----- Original Message ----- 
From: "Cpt. Boxershorts" <cpt...@te...>
To: "Mamutas Plaukotas" <ma...@pr...>;
<xen...@li...>
Sent: Thursday, January 01, 2004 5:38 PM
Subject: RE: [Xenocide-programming] Tech Tree XML layout

> 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
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Xenocide-programming mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>