On Fri, Mar 14, 2003 at 05:00:27PM +0000, Olivier Rolland wrote:
> --- In email@example.com, Keith Davies <keith.davies@k...>
> > Great. I'll point out, though, that you are referring to doco for
> > stuff that is not being done at the moment. Look in the 20030302
> > LST->XML folder. For now, we're doing a very direct translation,
> > with minimal change to the tags themselves.
> That's what I understand when reading the previous posts. But I am
> much more interested in the design of a d20 xml syntax. And if you
> don't mind, I will start to look further on this problem.
> > However, for future reference I'll discuss the points below. They
> > don't, by and large, apply to what we're doing right now, but I'll
> > discuss them anyway.
> > > - The meta tag: I don't understand why such a tag. It's very much
> > > like XML schemas but much less powerfull. With schemas, you could
> > > specify uniqueness or define keys to reference them later. Such
> > > construction are very usefull for example in list entities to
> > > verify that all items already exist.
> > The intent is somewhat similar to XSD, but to make it simpler and
> > more closely related to gaming -- more domain aware, if you will,
> > and getting rid of stuff that we don't need.
> > I know that we could probably get by with XSD, but I didn't want all
> > the baggage it brings.
> Of course, XSD provides a lot of stuff and is designed to be generic
> enough to be used in a wide variety of different frameworks. But it is
> in its way to be a standard (much more than DTDs) and libraries
> supporting it are already available in many languages (Java among
> others, see Xerces-J).
To be honest, I'm not all that familiar with XSD, but what I've seen has
given me hives <g>
I'm familiar with DTD, and apart from a lack of support for namespaces
I've found it meets my needs. I'm not opposed to XSD, meta was just
defined as a simpler subset of XSD, with a few 'extensions' that are
gaming-specific. It may be that those same extensions can be done with
XSD, but I don't know enough to say for sure. I am comfortable in
saying that meta is simpler than XSD.
> > > - benefit/prereqs: I do like very much these two tags and I think
> > > you could use them more often. For example, size provides bonuses
> > > or maluses on attacks, AC and hide skill. Something like this can
> > > be really handy:
> > >
> > > <def:size order="1" id="size.fine" name="Fine">
> > > <benefit>
> > > <add bonus="skill.hide" value="16"/>
> > > <add bonus="attack.bab" value="8"/>
> > > <add bonus="ac.full" value="8"/>
> > > </benefit>
> > > </def:size>
> > Such is the intent, yes.
> > > Further more, some benefits can be conditioned by a requirement.
> > > A construction of imbricated prereqs and benefits could then be
> > > considered. I do not have any immediate example, but I can find
> > > one if you want.
> > Well, I suppose there's
> > <def:class id="class.rogue">
> > <benefit>
> > <add-weapon-proficiency refid="weapon.rapier">
> > <presize min="size.medium" />
> > </add-weapon-proficiency>
> > </benefit>
> > </def:class>
> Yes. And I think "progression" can be handled the same way.
yep. That's the intent. The snippets below may not match what was
originally described in that doco; I'm up to my elbows in the schema
we'll actually be using in the short term and may be misremembering
things, or applying them differently. That said;
Progressions also allow for definition of recurring effects, such as
addition of hit dice, base attack bonus, etc. Fighter became really
<add-hit-die size="10" />
<recur test="not($rank % 2)">
<add-feat type="fighter" />
<add-feat type="fighter" />
> > > - score tag: Why do you use the same tag for abilities, saves,
> > > attacks and ac ? It prevents you to define the key ability of
> > > saving throws or attack bonuses.
> > The idea here was that, generally speaking, numeric scores (such as
> > abilities, base saves, and base attacks) are just that -- numbers.
> > They would be differentiated by type (for those processes that care)
> > and rules around bonuses would apply (for instance, save.fort would
> > be given a bonus based on the character's stat.con). They are not
> > directly linked because not every game uses them; they are
> > bonuses from having high stats.
> >  this schema was designed around being able to support multiple
> > games from not only different genres but different rules
> > systems.
> This will be quite hard to achieve, I guess...
Actually, while developing it was suprised at the range of games it
would be able to handle. Part of the reason I've been working on this
so long is that I kept seeing further abstractions that not only made it
easier to handle various rules (skills are progressions in d20, for
example, because various types of skills do different things at each
rank; in another game (HERO, say) they'd be just simple scores... but as
long as we can track both progressions and scores, it shouldn't be
terribly difficult to support (skills at least, under) both systems.
Really flexible and powerful... but possibly a bit trick to set up the
game modes. It doesn't particularly try to convert between games,
either; if you define a weapon in HERO, it won't be directly convertable
between systems. However, it may be possible, if rules for doing such
are conversion are created and made available, that the data *could* be
moved between them. Beyond the scope of what I'd come up with, though.
PCGen: <reaper/>, smartass
"You just can't argue with a moron. It's like handling Nuclear
waste. It's not good, it's not evil, but for Christ's sake, don't
get any on you!!" -- Chuck, PCGen mailing list