From: Andrew P. <a_p...@ho...> - 2003-12-09 17:38:02
|
>From: "Cpt. Boxershorts" <cpt...@te...> >To: "mamutas" ><ma...@pr...>,<xen...@li...> >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.armx |