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

Julien Cassignol ainulindale at gmail.com
Mon Sep 10 03:55:27 MST 2012

On Sun, Sep 9, 2012 at 11:18 PM, uckelman <uckelman at nomic.net> wrote:

> 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

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:

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

> 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:

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

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

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

Julien Cassignol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vassalengine.org/pipermail/messages/attachments/20120910/70780f39/attachment.html>

More information about the messages mailing list