[messages] [Developers] Design of property and piece XML for V4

Ainulindale ainulindale at gmail.com
Mon Sep 10 13:07:56 MST 2012


Here are the concated posts:


>     4. What's below is derived from what Ainulindale came up with two
> weeks
>     ago, but he hasn't seen my proposed templating system, so don't
> assume
>     he's endorsing it. :)



Likeable disclaimer :-)


>       <stringProperty id="name" value="101 Airborne"/>
>       <intProperty id="movement" value="4"/>
>       <floatProperty id="angle" value="60.0"/>
>       <enumProperty id="direction" value="north"/>
> 
>     (Question: Would it make more sense to have an "enum"
>     attribute for enumProperty, so that the enum referred to need not
> have
>     the same name as the enumProperty?) 



As I told you before, your use of the key of an enum as the id for the
instantiation of that enum seems to be a syntaxic abuse to me.
Plus, if we picture a piece such as a tank which will have a "direction"
it's going to, as well as a direction he's pointing to (being able to
rotate its guns), then we'd have two directions.
So in this specific case, I'd instantiate the property and define its
type, eg: <enumProperty id="movement" type="direction" value="north" />


>     This isn't intended to be an
>     exhaustive list of property elements. (Question: What other types
> might
>     we want? E.g., other numeric types---such as bool, or unsigned
> types, or
>     maybe numeric types range-limited in other ways---or dates, or a
>     refProperty which takes an id reference as a value.)
> 



I think we'll pretty much have to implement simple types such as int,
float, date, string, bool. After that we should apply constraints on the
elements.

For example let's take my point about tanks and assume that the
direction of the guns is between 1 and 6, and due to the rotation, wraps
at 1 when going beyond 6:


Code:
<intProperty name="direction" value="1" minValue="1" maxValue="6"
wrap="true" />



This emulates pretty much the numeric dynamic property, and I think this
has some value.
Obviously we should come up with a syntax which will be transversal to
types (so maybe as child elements).


>     Templates:
> 
>     Now for something abstract. A template establishes a pattern to be
>     reused elsewhere. Here's an example:
>     <snip>



What annoys me in your "template model" is that it is confusing if used
in the wrong way (as designers will obviously do).
Sure, we need to be able to refer to "rules" or behaviors from one piece
to another, that's agreed upon. But we also need to define types of
objects which will be of the same nature, that is, for C++/Java/OO guys,
inheritance. Maybe they're technically the same, but your way to explain
templates does not imply as much as I would like it to.

So for instance, let's say I have unit pieces which will always have a
specific property for their hit points, as well as a specific face for
when they're dead. I'd say:


Code:
<piece-type id="unit">
<parameter id="HIT">
<parameter id="DEAD">
<body>
<intProperty id="hit" value="{HIT}" />
<face id="dead" value="{DEAD}" />
</body>
</piece-type>

<piece id="tank" extends="unit">
<parameter id="HIT" value="10"/>
<parameter id="DEAD" value="images/goatse.jpg"/>
</piece>



So, to me, all major objects types should be templatable, doing a clear
distinction between an object type (face, piece, map) and a template (a
repeatable portion of XML). The former being of the same nature (one can
say "all units"), and the latter allowing concision in the code for
different pieces having the same behavior.
The next question is, should we treat such types as object inheritance
or interfaces, object-oriented wise? The latter may be more flexible
IMHO.


>      So, some questions:
> 
>     Does this look sufficiently powerful to capture what we want to
>     represent for pieces?



It's yet to be less verbose in my opinion (see above).
 

> 
> 
>     For those of you who might work with this by hand or with scripts,
> does
>     this look like something you'd want to use?



Obviously yes, although it lacks // and ;;

> 
>     Can you think of improvements to the syntax?



A lot but there's not enough room in the margin :-) 


Uckelman asked me to clarify. Here's the (hopefully effective)
clarification. Beware, it's long.

First, please consider that I'm more inclined towards types because I
think that this enforces a way to design which I deem more desirable. It
forces the designer to structure its objects in terms of a hierarchical
tree in which objects have shared properties.
A good example is the units, we'll have something such as :


Code:
             
             UNIT
      /                 \
INFANTRY              VEHICLE
                        /      \
                   TANK      BIKE




Translated: a bike is a vehicle, but also an unit. An infantry isn't a
vehicle but is a unit. A tank is a vehicle but is not a bike.
Your typical object model.
The fact that one is strictly forced to model its thoughts using that
kind of thought process is of value, to me, in terms of what we allow
and what we will have to debug.

In terms of functionnality, Uckelman's concepts as well as mine are, I
think, the same with more or less verbosity depending on the situation.
I just think that his is too much permissive or doesn't give enough
information to the engine.
That's why I think that having a type hierarchy in the XML, with
"abstract" objects extended by implementing objects, is easier.

In the following examples, I assume that parameters are transferrable
through hierarchy of template or type uses, as well as the usability of
"id" as a parameter.

Here's an example. Consider 4 decks of cards, each with one color from 1
to K:

Both solutions will share this:


Code:
<image id="1-hearts" img="image/1-hearts.png" />
<image id="2-hearts" img="image/2-hearts.png" />
...
<image id="K-spades" img="image/K-spbackK-spades.png" />
<image id="back" img="image/tubgirl.png" />



----------------------------------
My proposal:
----------------------------------


Code:
<piece id="card" abstract="true">
  <parameter id="COLOR">
  <body>
    <stringProperty id="color" value="{COLOR}" />
    <face id="front" img="{id}-{COLOR}" />
    <face id="back" img="back" />
  </body>
</piece>

<deck id="carddeck" abstract="true">
  <parameter id="COLOR"/>
  <body>
    <piece id="1" extends="card">
    <piece id="2" extends="card">
    <piece id="3" extends="card">
    ...
    <piece id="Q" extends="card">
    <piece id="K" extends="card">
  </body>
</deck>

<deck id="hearts" extends="carddeck">
  <parameter id="COLOR" value="hearts" />
</deck>

<deck id="spades" extends="carddeck">
  <parameter id="COLOR" value="spades" />
</deck>

<deck id="clubs" extends="carddeck">
  <parameter id="COLOR" value="spades" />
</deck>

<deck id="diamonds" extends="carddeck">
  <parameter id="COLOR" value="spades" />
</deck>



----------------------------------
Uckelman's proposal:
----------------------------------

Code:

<template id="card">
  <parameter id="COLOR">
  <body>
    <stringProperty id="color" value="{COLOR}" />
    <face id="front" img="{id}-{COLOR}" />
    <face id="back" img="back" />
  </body>
</template>

<template id="carddeck">
  <parameter id="COLOR"/>
  <body>
    <piece id="1" extends="card">
    <piece id="2" extends="card">
    <piece id="3" extends="card">
    ...
    <piece id="Q" extends="card">
    <piece id="K" extends="card">
  </body>
</template>

<deck id="hearts" extends="carddeck">
  <use template="deck">
    <parameter id="COLOR" value="hearts" />
  </use>
</deck>

<deck id="spades" extends="carddeck">
  <use template="deck">
    <parameter id="COLOR" value="hearts" />
  </use>
</deck>

<deck id="clubs" extends="carddeck">
  <use template="deck">
    <parameter id="COLOR" value="hearts" />
  </use>
</deck>

<deck id="diamonds" extends="carddeck">
  <use template="deck">
    <parameter id="COLOR" value="hearts" />
  </use>
</deck>





Another example illustrating what I wrote before for units:

----------------------------------
My proposal:
----------------------------------

Code:
<piece id="unit" abstract="true">
  <parameter id="HITS">
  <body>
    <intProperty id="hits" value="{HITS}">
  </body>
</piece>

<piece id="vehicle" abstract="true" extends="unit">
  <parameter id="ONBOARD_PERSONEL">
  <body>
    <intProperty id="onboardPersonel" value="{ONBOARD_PERSONEL}">
  </body>
</piece>

<piece id="tank" abstract="true" extends="vehicle">
  <parameter id="GUNS_NUMBER">
  <body>
    <intProperty id="onboardPersonel" value="{GUNS_NUMBER}">
  </body>
</piece>

<piece id="bike" abstract="true" extends="vehicle">
  <parameter id="SPEED">
  <body>
    <intProperty id="speed" value="{SPEED}">
  </body>
</piece>


<piece id="panzer" extends="tank">
  <parameter id="GUNS_NUMBER" value="1"/>
  <parameter id="ONBOARD_PERSONEL" value="3"/>
  <parameter id="HITS" value="4"/>
</piece>

<piece id="namelessBike" extends="bike">
  <parameter id="ONBOARD_PERSONEL" value="1"/>
  <parameter id="HITS" value="3"/>
  <parameter id="SPEED" value="150"/>
</piece>

<piece id="soviet" extends="unit">
  <parameter id="HITS" value="1"/>
</piece>



----------------------------------
Uckelman's proposal:
----------------------------------

Code:

<template id="unit">
  <parameter id="HITS">
  <body>
    <intProperty id="hits" value="{HITS}">
  </body>
<template>

<template id="vehicle">
  <parameter id="ONBOARD_PERSONEL">
  <body>
    <use template="unit" />
    <intProperty id="onboardPersonel" value="{ONBOARD_PERSONEL}">
  </body>
</template>

<template id="tank">
  <parameter id="GUNS_NUMBER">
  <body>
    <use template="vehicle" />
    <intProperty id="onboardPersonel" value="{GUNS_NUMBER}">
  </body>
</template>

<template id="bike">
  <parameter id="SPEED">
  <body>
    <use template="vehicle" />
    <intProperty id="speed" value="{SPEED}">
  </body>
</template>

<piece id="panzer">
  <use template="tank">
    <parameter id="GUNS_NUMBER" value="1"/>
    <parameter id="ONBOARD_PERSONEL" value="3"/>
    <parameter id="HITS" value="4"/>
  </use>
</piece>

<piece id="namelessBike">
  <use template="bike">
    <parameter id="ONBOARD_PERSONEL" value="1"/>
    <parameter id="HITS" value="3"/>
    <parameter id="SPEED" value="150"/>
  </use>
</piece>

<piece id="soviet">
  <use template="bike">
    <parameter id="HITS" value="1"/>
  </use>
</piece>



Now if we suppose that in scripts or even in XML, we'd like to implement
behaviors such as "impassable for vehicles" (lets say, a river), here
comes the difference: uckelman's proposal will need to define a property
to define the type of the object. Mine won't as it's implicit in the
modelization.

Even though the functionnality is the same, I like to be able to say "a
river isn't crossable by vehicles", and see the same in the grammar,
say, hypothetical implementation:


Code:
<token id="river">
  <disallowedPieces>
    <piece type="vehicle" />
  </disallowedPieces>
</token>



I hope this gave you food for thoughts.

_______________________________________________
Read this topic online here:
http://www.vassalengine.org/forum/viewtopic.php?p=36001#p36001


More information about the messages mailing list