RE: [Xenocide-programming] Tech Tree XML layout

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

I guess the 'obsoletes' functionality could be handled in code...I just
thought it would be more flexible to have it in the data.  If the business
logic (for when/if a research node becomes unavailable) is hardcoded, it
limits future development.  The <or> tags (or the equivalent) will still be
needed, to flag the node so the code knows how to treat it.

-The Captain

-----Original Message-----
From: xen...@li...
[mailto:xen...@li...]On Behalf Of
mamutas
Sent: December 10, 2003 8:55 PM
To: 'Cpt. Boxershorts'; 'Andrew Pokrovski';
xen...@li...
Cc: br...@pr...
Subject: RE: [Xenocide-programming] Tech Tree XML layout

Great discussion is going on here!

I really have very little to add after Andrew's response. I was actually
thinking very similarly. I agree that XML should describe relationships
only, but code must check whether one type of craft is shown versus another.
I also think that in case of engineers and medics, there should be some
indications that no more info can be extracted instead of 'nothing' as it
was in the original game. After such message was received by player, it is
entirely up to him what to do with all those engineers and medics.

As for obsolete field, I do not really think it is necessary at all. Each
unresearhed technology potentially could be researched. Why would we hide
its name from list? In the case of medics/engineers as well as other alien
races/professions, they should disappear from research list as long as the
research of them will not yeild any new results. If sectoid engineer is not
going to tell anything else, why should it be on research list? Our
scientists are smart enough about what to present in the reports to their
management (the player).

Regards,
mamutas

>-----Original Message-----
>From: xen...@li...
>[mailto:xen...@li...] On
>Behalf Of Cpt. Boxershorts
>Sent: Tuesday, December 09, 2003 4:08 PM
>To: Andrew Pokrovski; xen...@li...
>Cc: br...@pr...
>Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
>
>Hey Andrew,
>
>	I'm pretty sure that the actual responses from
>interrogating medics and engineers aren't random.  Medics will
>only give either that race, or the associated race (so a
>snakeman will give you Snakeman or Chrysillid, a sectoid will
>give you sectoid or cyberdisc, etc).  Engineers can only give
>you data on the ship they were in (so no matter how many large
>scouts you capture, you won't get Battleship info).
>
>That being said, I think your layout is good place to start.
>I was thinking of something similar, only instead of a
>'random' attribute (since it's not really random), have them
>contained within an <xor> element (similar to the way
><prerequisite> elements can be within an <or> element).
>You're right though, the internal code will have to handle the
>details about which one specifically to choose.
>
>My main idea about having a node obsolete itself after all of
>it's <grants><xor> fields have been finished is just to make
>it more user friendly.  The player can still remove live
>aliens from containment...but either way, they won't be
>cluttering up the research window.
>
>-The Captain
>
>
>
>
>-----Original Message-----
>From: xen...@li...
>[mailto:xen...@li...]On
>Behalf Of Andrew Pokrovski
>Sent: December 9, 2003 9:38 AM
>To: xen...@li...
>Cc: br...@pr...
>Subject: RE: [Xenocide-programming] Tech Tree XML layout
>
>
>
>
>
>>From: "Cpt. Boxershorts" <cpt...@te...>
>>To: "mamutas"
>><ma...@pr...>,<xen...@li...
>ceforge.n
>>et>
>>CC: <br...@pr...>
>>Subject: RE: [Xenocide-programming] Tech Tree XML layout
>>Date: Mon, 8 Dec 2003 11:39:03 -0800
>>
>>I 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.
>
>True, though you could gain a lot of "live alien" info by
>interrogating medics rather than having to go out and capture
>the aliens yourself. Still, I know what you mean, if you have
>about 20 aliens taking up containment space even though you've
>already interrogated them as much as you can. I don't think
>this should be dealt with by the research section, you should
>always be able to interrogate an alien prisoner. If you feel
>you don't want to, however, there should be an option to
>"throw them out" (execution, sell them to corporate labs,
>etc). That's not really relevant here though.
>
>Also, I agree with you that the 'obsoletes' field is pretty
>useless here. The only use for it I see is to mark a node as
>"done with" so it no longer shows up on the research tree - by
>this token, the only research topics that are never "done
>with" are live aliens.
>
>>
>>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?
>
>I believe medics and engineers both give you a random entry
>each time you research one, until there are no more entries in
>that section, at which point they give you nothing. A possible
>idea is to decouple the research entries a research item
>enables from the XNet entries it shows. This way, a research
>topic can enable stuff in the tech tree, but will also show
>some XNet entries that aren't necessarily tech tree items. For
>dealing with randomly selected benefits (like UFOs and
>corpses) one could add a tag to indicate whether or not the
>UFO or whatever has been enabled already. For
>example:
>
><!--Sectoid Engineer-->
><topic name="Sectoid" rank="engineer" researchtime="1000">
>
><prerequisite>
>  <Item name="Sectoid" rank="engineer" /> //reference to Item
>list </prerequisite>
>
><researchbonus/>
>
><grants>
>  <XNetEntry name = "Sectoid Interrogation"/>
>  <XNetEntry name = "UFOSpec1" random=true/>
>  <XNetEntry name = "UFOSpec2" random=true/>
>  <Item name = "Sectoid Corpse"/>
></grants>
></topic>
>
>So, the engineer (a researching dead-end, as I recall), would
>show a 'sectoid interrogation' entry no matter what, and will
>also randomly display one of the UFOSpecs (they've got that
>random tag). Also, researching an engineer could possibly
>yield a corpse or other items (a sectoid arm or something).
>Consistency of random UFO picks should probably be handled in
>the code, otherwise, we'd have to keep track of which UFOs
>have been picked for ALL engineer entries (one per sentient
>race). By consistency, I mean that if a UFO has been displayed
>already, another one should be picked.
>
>Andrew/"Nick Aragua"
>
>_________________________________________________________________
>Get holiday tips for festive fun.
>http://special.msn.com/network/happyholidays.ar>mx
>
>
>
>
>-------------------------------------------------------
>
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive?  Does it
>help you create better code?  SHARE THE LOVE, and help us help
>YOU!  Click Here: http://sourceforge.net/donate/
>_______________________________________________
>Xenocide-programming mailing list
>Xen...@li...
>https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive?  Does it
>help you create better code?  SHARE THE LOVE, and help us help
>YOU!  Click Here: http://sourceforge.net/donate/
>_______________________________________________
>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.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

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Xenocide-programming mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenocide-programming