RE: [Xenocide-programming] Tech Tree XML layout

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

MessageI think the separate attribute (at least for rank) is good idea,
because it would make it easier to mod in the future.  Adding a new rank (or
alien race, for that matter)  is that much better defined.  This way, the
topic "Grey Commander" (stored as (name="Grey" rank="commander") is parsed
as a grey (sectoid) first, and commander second.

I agree that we should minimize extraneous attributes (or elements, for that
matter).

Which leads us, of course, into adding a new field for dealing with multiple
researches of the same topic.  I can see two ways of doing this : default,
or specific.

Default Method: Currently more or less what we have.  Unless flagged in some
way (attribute or element), research topics are one-shot deals.  By default,
parent (researched) nodes in the tree can only be researched once.

Specific Method: In the original techtree xml file, there was an
<obsoletes/> element, that would contain topics and items that the player
could no longer access.  I took it out because the way it was being used (to
block earlier technologies) seemed to be a waste of time at best, and
counter productive at worst (AP ammo isn't obsolete just because you have
Lasers).  However, we could use this to specify a node obsoleting itself.
This is the more flexible route, as it opens up all sorts of possibilities
in future versions.

There might be some sort of condition possible in here as well...once all
possible child nodes are researched, then the node obsoletes itself.
Otherwise, you have the same annoying problem that x-com had, where you end
up with 20+ snakeman medics on your research list, even though you
researched one 6 months ago.

However, there's another catch in here...when you research an engineer, you
aren't given a new topic or item....just new information. Just to make
things more complicated, the information (IIRC) depends on the ship the
engineer came from.  Would that sort of thing be handled entirely in the
code itself?  Or would the techtree need to list all possible crafts as
results from an engineer, and the research code just picks the correct one
off the list?

-The Captain

  -----Original Message-----
  From: mamutas [mailto:ma...@pr...]
  Sent: December 7, 2003 9:58 PM
  To: 'Cpt. Boxershorts'; xen...@li...
  Cc: br...@pr...
  Subject: RE: [Xenocide-programming] Tech Tree XML layout

  You now make me think that some research topics did not have a visual
representation in the original game. More than that, it was possible to
research the same alien navigator and to get more and more of different info
from him. Everytime you research a navigator, you would get an info about an
alien craft. In that case, there multiple outcome from the research and
research item could be reused. It is very important to implement suppor for
such functionality in your XML format.

  Again, some research topics did not have a visual representation in the
original game at all. For example: laser weapons. There was nothing shown at
the end of research, except for 'You can research laser pistol and rifle
now'. The question, are we going to follow that scheme? Or we will have a
visual representation for each research topic? I do not know yet.

  So, now I am thinking, that since research tree is static and completely
defined at the beginning of the game, there is no need to introduce more
properties than it is necessary. For example, Nick suggested to separate
rank from race and I supported him. However, the approach he was suggesting
is good for dynamic game data, and not for static research tree. Therefore,
limit the number of attributes for necessary ones only.

  Regards,
  mamutas.
    -----Original Message-----
    From: Cpt. Boxershorts [mailto:cpt...@te...]
    Sent: Thursday, December 04, 2003 12:12 AM
    To: mamutas; xen...@li...
    Subject: RE: [Xenocide-programming] Tech Tree XML layout

    It's 'name' so that it fits with everything else in the tech tree.  This
is just a research topic...it won't hold actual alien data (stats and the
like), just information related to the tech tree.  The actual entry (made
commander just for extra fields) would look like this:

    <!--Sectoid Commander-->
    <topic name="Sectoid" rank="commander" researchtime="1000">

     <prerequisite>
      <Item name="Sectoid" rank="commander" /> //reference to Item list
     </prerequisite>

     <researchbonus/>

     <grants>
      <topic name="Psi Lab"/>
     </grants>
    </topic>

      -----Original Message-----
      From: xen...@li...
[mailto:xen...@li...]On Behalf Of
mamutas
      Sent: December 3, 2003 8:32 PM
      To: 'Cpt. Boxershorts'; xen...@li...
      Subject: RE: [Xenocide-programming] Tech Tree XML layout

      Yeah, that is exactly what I was suggesting.
      Unfortunately, I do not think it is possible to refernce IDs between
files, but things might have been changed recently...

      I suggest to go with second approach: different properties in
different attributes. And change 'name' to 'race': Sectoid, Floater,
Human...
        -----Original Message-----
        From: Cpt. Boxershorts [mailto:cpt...@te...]
        Sent: Monday, December 01, 2003 7:32 PM
        To: mamutas; xen...@li...
        Subject: RE: [Xenocide-programming] Tech Tree XML layout

        So, what you're saying is move the <filereferences> element into a
global item list?  That's no problem.
        Do you know if it's possible to enforce id integrity across files?
I know you can do it in a single file.

        Does anyone know how captured aliens will be recorded?  Will it be
an actual "Alien" class with a Rank property, or just a one line reference?

        Basically, I'm asking if it would be:

        <topic name="Sectiod Soldier"/>

        or

        <topic name = "Sectoid" rank="Soldier"/>

        The first is easier to do, but the second might be better for
future-proofing (for multiplayer, when you can capture enemy humans as well)

        -The Captain

          -----Original Message-----
          From: mamutas [mailto:ma...@pr...]
          Sent: December 1, 2003 2:47 PM
          To: 'Cpt. Boxershorts'; xen...@li...
          Subject: RE: [Xenocide-programming] Tech Tree XML layout

          Yes, visual representation is the images, text, models -
everything what is displayed to the user. I suggest to break down
information into separate files: one containing relationship for XNet DB
view, another with relationships and data for research, and another with
list of all entities and their visual representation (models, text, video,
etc.). Then first two files could refer to the last one. How is that?
            -----Original Message-----
            From: Cpt. Boxershorts [mailto:cpt...@te...]
            Sent: Monday, December 01, 2003 4:07 PM
            To: mamutas; xen...@li...
            Subject: RE: [Xenocide-programming] Tech Tree XML layout

            I'm not quite sure if I understand.  By "visual representation",
do you mean the part of the data that the player actually sees (i.e.: the
xnet info), or or you suggesting a further breakdown of the underlying data
(so there would be an XML file containing a simple list of all researchable
items, and separate file containing the relationships)?

            -The Captain
              -----Original Message-----
              From: xen...@li...
[mailto:xen...@li...]On Behalf Of
mamutas
              Sent: November 30, 2003 8:32 PM
              To: 'Andrew Franks';
xen...@li...
              Subject: RE: [Xenocide-programming] Tech Tree XML layout

              Looks pretty good to me.

              I take a look at the structure of XML file and did not really
checked the dependencies between researcheable items.

              I have one concern here: the definition integrates both
research tree hierarchy and visual representation for the entities. In my
opinion these two should be separated, perhaps in two XML files: first to
describe dependencies only, second to provide information for entry visual
presentation.

              In addition, I think that this project should be performed in
parallel with XNet DB model definition. ChrisP has started it, but not
finished yet. Here I think we need two XML as well: one to describe
categories and entities and another to describe visual representation of
entity. The second could be the same as the one for research, see?

              Regards.
                -----Original Message-----
                From: xen...@li...
[mailto:xen...@li...] On Behalf Of
Andrew Franks
                Sent: Friday, November 28, 2003 5:05 PM
                To: mamutas; xen...@li...
                Subject: RE: [Xenocide-programming] Tech Tree XML layout

                Okay, here's a first draft.  I included every field I could
think of...let me know if I missed anything.
                Is X-Net going to have it's own xml layout, or will it share
with the tech tree?

                Here's a short sample, see the attachment for more detailed
comments

                //Plasma Pistol
                <topic name="Plasma Pistol" researchtime="100">

                 <prerequisite>
                  <topic name="Plasma Weapons" />
                  <item name="Plasma Pistol" />
                 </prerequisite>

                 <researchbonus> // so if the player researched rifle before
pistol, pistol would only take 95% of researchtime
                    //these are cumulative, so if both were researched
already, pistol would take 90% of researchtime
                  <topic name="Plasma Rifle" bonus="5" />
                  <topic name="Heavy Plasma" bonus="5" />
                 </researchbonus>

                 <filepaths>

<unresearched>/xnet/texts/unresearched/plasmapistol.rtf</unresearched>
                  <xnet_image>/xnet/images/plasmapistol.3ds</xnet_image>

<xnet_text>/xnet/texts/weapons/plasmapistol.rtf</xnet_text>
                 </filepaths>

                 <grants>
                  <item name="Plasma Pistol"/>
                 </grants>
                </topic>

                 - Cpt. Boxershorts

                ---
                Incoming mail is certified Virus Free.
                Checked by AVG anti-virus system (http://www.grisoft.com).
                Version: 6.0.538 / Virus Database: 333 - Release Date:
2003/11/10

              ---
              Outgoing mail is certified Virus Free.
              Checked by AVG anti-virus system (http://www.grisoft.com).
              Version: 6.0.538 / Virus Database: 333 - Release Date:
2003/11/10

            ---
            Incoming mail is certified Virus Free.
            Checked by AVG anti-virus system (http://www.grisoft.com).
            Version: 6.0.545 / Virus Database: 339 - Release Date:
2003/11/27

          ---
          Outgoing mail is certified Virus Free.
          Checked by AVG anti-virus system (http://www.grisoft.com).
          Version: 6.0.545 / Virus Database: 339 - Release Date: 2003/11/27

        ---
        Incoming mail is certified Virus Free.
        Checked by AVG anti-virus system (http://www.grisoft.com).
        Version: 6.0.545 / Virus Database: 339 - Release Date: 2003/11/27

      ---
      Outgoing mail is certified Virus Free.
      Checked by AVG anti-virus system (http://www.grisoft.com).
      Version: 6.0.545 / Virus Database: 339 - Release Date: 2003/11/27

    ---
    Incoming mail is certified Virus Free.
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.545 / Virus Database: 339 - Release Date: 2003/11/27

  ---
  Outgoing mail is certified Virus Free.
  Checked by AVG anti-virus system (http://www.grisoft.com).
  Version: 6.0.545 / Virus Database: 339 - Release Date: 2003/11/27