Menu
▾
▴
RE: [Xenocide-programming] Tech Tree XML layout
|
From: mamutas <ma...@pr...> - 2003-12-11 04:55:22
|
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...=20 >[mailto:xen...@li...] On=20 >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=20 >interrogating medics and engineers aren't random. Medics will=20 >only give either that race, or the associated race (so a=20 >snakeman will give you Snakeman or Chrysillid, a sectoid will=20 >give you sectoid or cyberdisc, etc). Engineers can only give=20 >you data on the ship they were in (so no matter how many large=20 >scouts you capture, you won't get Battleship info). > >That being said, I think your layout is good place to start. =20 >I was thinking of something similar, only instead of a=20 >'random' attribute (since it's not really random), have them=20 >contained within an <xor> element (similar to the way=20 ><prerequisite> elements can be within an <or> element). =20 >You're right though, the internal code will have to handle the=20 >details about which one specifically to choose. > >My main idea about having a node obsolete itself after all of=20 >it's <grants><xor> fields have been finished is just to make=20 >it more user friendly. The player can still remove live=20 >aliens from containment...but either way, they won't be=20 >cluttering up the research window. > >-The Captain > > > > >-----Original Message----- >From: xen...@li... >[mailto:xen...@li...]On=20 >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"=20 >><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,=20 >>because it would make it easier to mod in the future. Adding a new=20 >>rank (or alien race, for that matter) is that much better defined. =20 >>This way, the topic "Grey Commander" (stored as (name=3D"Grey"=20 >>rank=3D"commander") is parsed as a grey (sectoid) first, and commander = >>second. >> >>I agree that we should minimize extraneous attributes (or=20 >elements, for=20 >>that matter). >> >> >>Which leads us, of course, into adding a new field for dealing with=20 >>multiple researches of the same topic. I can see two ways of doing=20 >>this : default, or specific. >> >>Default Method: Currently more or less what we have. Unless=20 >flagged in=20 >>some way (attribute or element), research topics are one-shot deals. =20 >>By default, >>parent (researched) nodes in the tree can only be researched once. >> >>Specific Method: In the original techtree xml file, there was an=20 >><obsoletes/> element, that would contain topics and items that the=20 >>player could no longer access. I took it out because the way it was=20 >>being used (to block earlier technologies) seemed to be a=20 >waste of time=20 >>at best, and counter productive at worst (AP ammo isn't obsolete just=20 >>because you have Lasers). However, we could use this to=20 >specify a node=20 >>obsoleting itself. This is the more flexible route, as it=20 >opens up all=20 >>sorts of possibilities in future versions. >> >>There might be some sort of condition possible in here as well...once=20 >>all possible child nodes are researched, then the node obsoletes=20 >>itself. Otherwise, you have the same annoying problem that x-com had,=20 >>where you end up with 20+ snakeman medics on your research list, even=20 >>though you researched one 6 months ago. > >True, though you could gain a lot of "live alien" info by=20 >interrogating medics rather than having to go out and capture=20 >the aliens yourself. Still, I know what you mean, if you have=20 >about 20 aliens taking up containment space even though you've=20 >already interrogated them as much as you can. I don't think=20 >this should be dealt with by the research section, you should=20 >always be able to interrogate an alien prisoner. If you feel=20 >you don't want to, however, there should be an option to=20 >"throw them out" (execution, sell them to corporate labs,=20 >etc). That's not really relevant here though. > >Also, I agree with you that the 'obsoletes' field is pretty=20 >useless here. The only use for it I see is to mark a node as=20 >"done with" so it no longer shows up on the research tree - by=20 >this token, the only research topics that are never "done=20 >with" are live aliens. > >> >>However, there's another catch in here...when you research an=20 >engineer,=20 >>you aren't given a new topic or item....just new information. Just to=20 >>make things more complicated, the information (IIRC) depends on the=20 >>ship the engineer came from. Would that sort of thing be handled=20 >>entirely in the code itself? Or would the techtree need to list all=20 >>possible crafts as results from an engineer, and the research=20 >code just=20 >>picks the correct one off the list? > >I believe medics and engineers both give you a random entry=20 >each time you research one, until there are no more entries in=20 >that section, at which point they give you nothing. A possible=20 >idea is to decouple the research entries a research item=20 >enables from the XNet entries it shows. This way, a research=20 >topic can enable stuff in the tech tree, but will also show=20 >some XNet entries that aren't necessarily tech tree items. For=20 >dealing with randomly selected benefits (like UFOs and=20 >corpses) one could add a tag to indicate whether or not the=20 >UFO or whatever has been enabled already. For >example: > ><!--Sectoid Engineer--> ><topic name=3D"Sectoid" rank=3D"engineer" researchtime=3D"1000"> > ><prerequisite> > <Item name=3D"Sectoid" rank=3D"engineer" /> //reference to Item=20 >list </prerequisite> > ><researchbonus/> > ><grants> > <XNetEntry name =3D "Sectoid Interrogation"/> > <XNetEntry name =3D "UFOSpec1" random=3Dtrue/> > <XNetEntry name =3D "UFOSpec2" random=3Dtrue/> > <Item name =3D "Sectoid Corpse"/> ></grants> ></topic> > >So, the engineer (a researching dead-end, as I recall), would=20 >show a 'sectoid interrogation' entry no matter what, and will=20 >also randomly display one of the UFOSpecs (they've got that=20 >random tag). Also, researching an engineer could possibly=20 >yield a corpse or other items (a sectoid arm or something).=20 >Consistency of random UFO picks should probably be handled in=20 >the code, otherwise, we'd have to keep track of which UFOs=20 >have been picked for ALL engineer entries (one per sentient=20 >race). By consistency, I mean that if a UFO has been displayed=20 >already, another one should be picked. > >Andrew/"Nick Aragua" > >_________________________________________________________________ >Get holiday tips for festive fun.=20 >http://special.msn.com/network/happyholidays.ar>mx > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: SF.net Giveback Program.=20 >Does SourceForge.net help you be more productive? Does it=20 >help you create better code? SHARE THE LOVE, and help us help=20 >YOU! Click Here: http://sourceforge.net/donate/=20 >_______________________________________________ >Xenocide-programming mailing list=20 >Xen...@li... >https://lists.sourceforge.net/lists/listinfo/xenocide-programming > > > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program.=20 >Does SourceForge.net help you be more productive? Does it=20 >help you create better code? SHARE THE LOVE, and help us help=20 >YOU! Click Here: http://sourceforge.net/donate/=20 >_______________________________________________ >Xenocide-programming mailing list=20 >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 >=20 > --- 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 =20 |
