RE: [Xenocide-programming] Other XML Layouts?

[Mamutas P. <mam...@ho...>]

Hi Cpt. and all,

Sorry for delayed answer. But better late than never! :-)

I can=92t argue with the reasons of having crafts and soldiers listed in =
base
and hangars and barracks just referencing them after your explanation. =
That
is OOD approach, but as you said that in XML we might think differently.
Lets leave it with your latest suggestion.

Everything else looks good. No critics in this reply. :-)

=20

Regards,=20

mamutas

=20

=20

   _____ =20

From: xen...@li...
[mailto:xen...@li...] On Behalf Of =
Cpt.
Boxershorts
Sent: Monday, January 26, 2004 3:59 PM
To: Vlad Judys; xen...@li...
Subject: RE: [Xenocide-programming] Other XML Layouts?

=20

Hey all,

=20

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

=20

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. =20

=20

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.

=20

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

=20

<craft name=3D"Interceptor1" status=3D"Available"> <!-- name is uid. -->

  <type>Interceptor</type>=20
    <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>
   =20
    <weapons>
     <item name=3D"Cannon" ammo=3D"500" hardpoint=3D"1" /> <!--hardpoint =
indicates
index/uid of specific weapon location -->
     <item name=3D"Ajax Launcher" ammo=3D"6" hardpoint=3D"2" />
    </weapons>
   =20
   </craft>

=20

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

=20

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.

=20

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.

=20

<facility name=3D"Laboratory1" type=3D"Laboratory">
    <location x=3D"3" y=3D"2" />
    <complete>true</complete>
    <builddays>0</builddays>
    <capacity>50</capacity>
    <usedcapacity>10</usedcapacity>
   =20
    <contents>
     <scientist quantity=3D"5">Laser Weapons</scientists>
     <scientist quantity=3D"5">Medikit</scientists>
    </contents>
   =20
   </facility>

=20

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. =20

=20

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).

=20

=20

-The Captain


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



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004
=20