RE: [Xenocide-programming] Other XML Layouts?

[Cpt. B. <cpt...@te...>]

Hey all,

    Please, critique away.  We're trying to write a great game, not just
'pretty good'.  :)

I agree that logically, having crafts in the hanger node makes more sense.
I was just thinking that in the object model itself, all a hanger needs to
know is A) is a craft assigned to it and B) is the craft currently in it.
The first is only used when purchasing or transferring, and the second only
for the baseview.  Everything else (Equip, Intercept, sell/sack (which hits
item A as previous)) looks at crafts as belonging to the base, rather a
specific hanger.  I thought it would be easier/faster to have a master list
of crafts, and the hangers just have a reference to an item on that list.

That's not necessarily the way we'll do it, of course, plus XML logic
doesn't need to copy internal logic anyways.  It doesn't matter to me which
way we do it...I just wanted to explain my thinking.

Here's a sample of how the craft would be portrayed (wherever it ends up):

<craft name="Interceptor1" status="Available"> <!-- name is uid. -->
  <type>Interceptor</type>
    <name>Interceptor 1</name> <!-- <name> is user editable title-->
    <hanger>Hanger1</hanger> <!-- reference to hanger.  moot if craft is
contained by hanger -->
    <currentHP>100</currentHP>

    <weapons>
     <item name="Cannon" ammo="500" hardpoint="1" /> <!--hardpoint indicates
index/uid of specific weapon location -->
     <item name="Ajax Launcher" ammo="6" hardpoint="2" />
    </weapons>

   </craft>

I agree that the transfer section is redundant.  Just wanted a second
opinion.  Consider it gone.

I like your suggestion of how to handle transfers.  Simple, elegant, and
does the job.  I'll try to have it in in the next version.

I'm not sure what else would go under <scientists> at this point.  Since the
scientists aren't individual units (in this version at least), there's
nothing else to keep track of.  I figured the Lab facility would keep track
of actual research topics.  Workshops would look pretty much the same.

<facility name="Laboratory1" type="Laboratory">
    <location x="3" y="2" />
    <complete>true</complete>
    <builddays>0</builddays>
    <capacity>50</capacity>
    <usedcapacity>10</usedcapacity>

    <contents>
     <scientist quantity="5">Laser Weapons</scientists>
     <scientist quantity="5">Medikit</scientists>
    </contents>

   </facility>

I agree that barracks and stores facilities have no need of <contents>
now...but I know that base damage is high on the list for v1+, and adding
that level of granularity now would save time in the future.  Of course, the
item itself could just have reference to the parent facility...but that's
the crafts/hanger argument again.

For v1, knowing which barracks a unit is in (randomly assigned when hired, I
assume) could be used to determine starting locations during base attacks,
and having stored items (weapons, primarily) available on the battlescape
during base attacks could be done easily ( Id don't know it that's on the
feature list for v1 or not).


-The Captain

  -----Original Message-----
  From: xen...@li...
[mailto:xen...@li...]On Behalf Of Vlad
Judys
  Sent: Saturday, January 24, 2004 7:52 PM
  To: 'Cpt. Boxershorts'; xen...@li...
  Subject: RE: [Xenocide-programming] Other XML Layouts?


  Hi Cpt. and all.



  I started to write the answer with critics, but it did not look good. So I
added this line here J Critics are below.

  Overall, I think that layout looks really well. However, I did not like
the <content> and <transfer> sections. I think they should be combined. The
item in content must have more information about it status, where content is
one of them. Let’s say you have a gun in stores. So, the status of it is
‘stored’ or something. Then you transfer it to another base, the item
changes the base it belongs to and its status is ‘transferred’. We might
even have the number of hours till arrival.

  Then for some specific content entries, for example scientists, we would
definitely want more information. But those are details which could be
flushed out later.

  More major issue is that whether contained items must be described within
container or base itself. For example, crafts. There is a section in the
<base> which lists crafts, but then there is a reference to them from
<hangar>. From programming point of view it is just difference in one method
of Base class: either retrieve list of crafts within Base object itself or
create a list of crafts from the crafts from all hangars. I would prefer
that crafts would be listed inside the hangars – the XML would be clearer.
But that is different for stores or living quarters: it is not important
what store the pistol is in or what barrack John Doe is in – we are not
going to display them differently or provide that kind of info for players.



  Regards

  mamutas



  ---
  Incoming mail is certified Virus Free.
  Checked by AVG anti-virus system (http://www.grisoft.com).
  Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004




  ---
  Outgoing mail is certified Virus Free.
  Checked by AVG anti-virus system (http://www.grisoft.com).
  Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004