Re: [pcgen-xml] Data restructuring
- On Tue, Jan 20, 2004 at 12:23:09AM -0700, Steven Bethard wrote:
> A brief note about terminology:I really should colorcode the diagrams. *Only* the framework would be
> I tried to use the same terms you were using because I thought that
> people could, with some effort, translate from one use of the term to
> the other, and thus the schema would not seem so alien that people
> would dismiss it immediately. ;) Ratings in my system are used for
> similar things as Ratings in yours, Scores in my system are used for
> similar things as Scores in yours (though they'd also be extended to
> include the kind of things you encode as Progressions.)
> You'll note that I tried to compress your large number of terms into a
> smaller number because I believe that the current schema is tailored
> too much to the D&D system and will still make it hard to incorporate
> new systems into PCGen.
built into the system, the various game-specific elements would be added
for the game. The diagrams I put up were for d20 because, well, that's
what we're supposed to be focusing on. I can put up some alternate
examples for other games.
I don't *want* interoperability between games. Even if two games look
a lot the same (say, d20 and D&D2) I don't want the data to be readily
> I would push for a /very/ generic input-to-PCGen schema, with systemThat is currently slated to happen in the loading layer, rather than
> specific schemas for translating to this (and probably system specific
> GUIs too.) In fact, I would encourage you to take your current schema
> and make it as appropriate to D&D as you can. It could then serve as
> the D&D-specific schema which would be translated into a more generic
> one before being input into PCGen.
having an additional external transformation from 'game-specific' to
> > > In my system, skills having Effects is not a problem - you justI'd have to see it. Remember that we're not the ones who have to use
> > > associate an Effect with a change in the value of the skill Score.
> > I'm against this idea for anything I'm working with here (it does
> > work in other places) because of it depends on monitoring state of
> > things -- it becomes and event-driven system... something I don't
> > think is appropriate for this problem. I think it would involve
> > tying too many things together in the program. OTOH, I haven't put
> > a lot of thought into what it would take to implement the system
> > you're describing; I could be mistaken.
> Actually, the event-driven system is quite easy to implement - see the
> code that I posted. More importantly, it's very easy to maintain, and
> you don't have to worry about updating all the various values - this
> is handled by code already provided by the Observer-Observable Java
> And as far as what it requires on the data end, all you need to know
> is how one Score, Rating, Feature or Item affects another - exactly
> the things you already have to specify. Any common effects (like
> "INCREMENT W by X IF SCORE Y == Z") can be given shorthand encodings
> if it turns out they are easier to process that way.
> I know you're set against the idea of system designed around an
> Observer-Observable paradigm, but I'd urge you to take a close look at
> it - it provides very clean code, makes the code easy to maintain, and
> provides a simple manner of separating the model from the input data
> and the user interface. And it wouldn't even affect the encoding of
> things like Scores or Rankings - only the encoding of Effects (and
> even those, not too much).
this on a daily basis, but people with much less experience with this
stuff than we have. Apart from some initial confusion caused by
presentation, I understand where you're coming from -- I don't agree
with it yet, but I understand it -- but it's even less obvious than what
I'd come up with. The learning curve on this looks like it'd be pretty
steep for people with little or no background in the technology.
Incidentally, how will this behave with thousands of entities in the
system? That could make for a lot of interactions and relationships to
keep all the data accurate.
> > Well then you shouldn't use the words, then! I had them first, pickheh, thanks. Or do kjd:Entity or something. Mmmm, namespaces.
> > your own words! :)
> Heh heh. Well I'm going to continue to use the same terms because I
> think we really are representing similar concepts (though I have
> chosen a coarser grain of detail than you) but for your benefit, I
> will include both from now on. =)
> > Oh, and FWIW (in this example, at least) basing level progression onThat can be dropped relatively easily, though. If level advancement is
> > XP makes it markedly harder to get d20 Licensing (if we wanted to go
> > back that route again). If it's easy to remove it wouldn't be a big
> > deal, mind.
> You mean you can't include the level progression in the rules files?
> PCGen does this currently - see system\gameModes\35e\level.lst. I
> don't see why including this as an Effect in the XML data would be
> more of a problem than including it in the current LST data. Sorry,
> but could you explain this?
tied to XP and requires that XP be used to advance levels it's tied more
I don't think we're actually going to go back to the d20 License, I
mention it only as an aside.
> > I think a schema to describe D&D specifically should use D&DAs above, this would be done in the loader. <class> is more meaningful
> > terminology. XML, as far as I know, is best used when the markup
> > describes the problem domain.
> Right, and a schema to describe character generator data should use
> the generic character generation terminology, not terminology for a
> specific system. ;) Specific system terminologies should be
> (automatically) translated into the generic terminology.
to a data monkey than... <rating>, was it? I'm trying to keep the
markup closer to the problem domain to make it easier to understand for
people who are not interested in the implementation.
> > Looking at your examples, it looks like you describe how the thingsWell you should have said in an earlier post, then; we could have
> > are implemented, with indicators of what type of thing is being
> > described. That, to me, is ugly. YMMV.
> My standard response again ;) - this is the input-level, generic
> schema. You should build a separate D&D specific schema (that is
> pretty =) and translate.
avoided a lot of disagreement. If what you're describing is a way to
deconstruct the various entities, that's an entirely different beastie
than "a class should look like <rating kind='class'>".
> > "Save bonuses should be able to add Feats"? When does *this* everI have no problem with that, though it's not obvious (and possibly
> > happen in D&D? (Base) save bonuses can be prereqs for feats, but
> > I've never even heard of a case where having 'Fort BSB = +5' causes
> > something to happen. In my framework, if such behavior is desired
> > then Saves become progressions.
> I hope it doesn't happen in standard D&D or I'm doing something wrong.
> ;) I only bring it up because I think it's inevitable that something
> weird like this will be asked for at some point. If we stick with
> your system, I would encourage you to move any Scores (your
> definition) to Progressions,
unnecessary for D&D). A progression is probably overkill, but hell,
it's not that heavy.
> where effects could be associated with them. Even if the basic systemThe attachment of ability score to Score is one based on the nature of
> never needs this facility, it seems to me that if we have the
> potential to represent it, we hedge out problems in the future by
> addressing this issue now.
what we're trying to model. However, for other games it'd be easy
enough to change the definition.
Remember, too, that my examples don't try to capture every game in
existance, but only D&D. The framework is there to give support for
other games, without involving the D&D entities. Actually, I suppose
the framework might be more of a toolkit, since I don't want things
mixing between games too readily.
> (BTW, the save bonuses one does sound pretty silly to me, but I couldI could actually see this one happening.
> totally imagine a group deciding that if you get a Strength of 25, you
> get a new Feat of some sort. Not horribly likely, but again, why shut
> out the possibility if we don't have to.)
> > > To some degree, this may be true. I've designed an event-drivenIt doesn't -- Effects are attached at the Item level, even above Entity
> > > model where all Entites are equal, and can equally affect each
> > > other using Effects. Because it's event driven, Effects are
> > > associated with the Entities that cause them which may seem
> > > backwards to what you've proposed. However, because of its
> > > simplicity and generality, it allows me to support things like
> > > having Ability increases add Feats, having Hit Points add Items,
> > > etc.
> > I question why this is valuable, though. You're describe situations
> > that I have never seen in rules or published anywhere.
> It's valuable because it means we treat all game entities and Effects
> uniformly. (Here, by game entity, I mean anything associated with a
> character, e.g. for D&D this includes Abilities, Saves, Skills, Feats,
> etc.) Why limit only certain game entities to causing Effects?
(so even non-Entities (only Ranks at the moment) can have Effects).
> That is, why restrict the schema if we don't have to? I agree thatSpeak Language gives knowledge of new languages to speak, Perform gives
> most of the things I suggested are not part of current systems, but
> that doesn't mean they won't be in the future. Wasn't there a message
> a while back saying that ranks in some Skill gave you a Feat? (I
> think it was something like this that caused you to make them
> progressions, right?)
ability with new instruments (or used to, in 3e). Spell Knowledge IMC
gives knowledge of spells (as the name indicates), and so on.
It's not impossible we get rid of Scores altogether IMS (in my Schema)
and replace them with Progressions. OTOH, Progressions are usually
expected to be defined and used, not have stuff tacked on later; a rule
such as you suggested (STR 25 add a feat) would have to have the 25th
rank of the Str progression modified or inserted.
> Why not give our model the potential to deal with such Effects so thatAlready done, as Effects are in Item (above even Entity).
> if a publisher (or even a particular gaming group) does eventually
> want these facilities, we can support them? All it requires is
> unifying the Effects framework so that we can associate Effects with
> each type of game entity. That is, in your terminology, allow Effects
> associated with Scores, Rankings, Entities, Progressions, Items,
> Ranks, Spells, etc. Or in my terminology, allow Effects associated
> with Scores/OrderedSetSelections, Rankings/UnorderedSetSelections,
> Features/BinarySelections, Items/BinaryItemSelections.
> > No, I think I understand now. I disagree with your design premise,As have I, from the other direction.
> > I think it doesn't suit the problem terribly well, I think it would
> > greatly alienate the people who have to use it (even more than mine,
> > which is saying something! <g>), and I think it would lead to an
> > awkward and probably difficult implementation. This is all my
> > judgement and based on (I think justified) bias.
> Well, I would disagree strongly here. I've designed a solution that
> is quite general and can deal with pretty much any sort of situation.
> It has commonalities with your approach too - it defines severalassociates those things with Entities, rather; I see no difference
> different types of "things" that may be associated with characters.
> Your approach associates Scores, Rankings, Entities, Progressions,
> Items, Ranks, Spells, etc with characters.
between a Character and a Spell (beyond complexity, of course).
> My approach removes some of the arbitrary distinctions between these,I want to get all Entities down to a generic GameObject internal to the
> and condenses a couple dozen game entity types into four game entity
> types: Scores/OrderedSetSelections, Rankings/UnorderedSetSelections,
> Features/BinarySelections, Items/BinaryItemSelections.
> Reducing the number of game entity types reduces implementation
> difficulties rather than increasing them - you only have to define 4
> types of Effects (one for each game entity) instead of a dozen or so.
program, but haven't figured out a reasonable implementation of this.
I think (and I think you'll agree) that what we're actually doing here
is talking about both ends of the system -- I'm talking about file
organization and you're talking about internal structure once loaded.
That's added to the confusion <g>
I wonder... can you describe how things would map from one schema to the
other? I think my schema better suits the people who will be using it,
but that you're may be better for internal use. If this is true, and
you can demonstrate how to map back and forth between them, I suspect we
can come to an agreement.
> (Don't even start me on how many PCGen has right now ;)heh.
> In setting up this model, I have focused the detail on making theWhat about the people encoding the information to be used by the
> encoding of Effects simple, and have used an event-driven model to
> explain how one would implement such a model. However, as this is
> meant as a PCGen internal model, from the user end, the event-driven
> aspect of it is irrelevant - users will never see this.
program? Entity editors and whatnot will be great to have, but I still
want the Schema to be readily understandable by sight, both for manual
data entry (and there'll still be some of that going on) and for
> They need only determine how to calculate Abilities or how to add theAgain, how does this behave when there are thousands of entities in the
> results of Feats, etc. and insert the appropriate formulas (just as
> they already do now). I suggest an event-driven model for dealing
> with Effects because it's efficient, clean and easy to implement (if
> you don't believe this, take a look at the Java code I've posted) but
> there are certainly other ways of implementing Effects.
system? I think we can agree that we aren't really designing this to be
strictly just a character editor; we've both designed schema to support
a more generic 'entity editor'.
> I know I've said this a hundred times now, but I want to emphasize again,Nope. Two or three, maybe, and just in this message, so far as I know.
> the XML input to the program does not have to be (and probably should not
> be) the XML that Data Monkeys encode.
> The XML that I suggest is generic between role playing systems, andheh.
> thus is not the most concise way to write a description of any
> specific system. However, defining a simpler schema for each system
> and mapping it to this general one is an easy solution to this
> problem. In fact, I could probably write the transform for 90% of
> your schema (Scores -> Scores, Progressions -> Scores with associated
> Effects, etc.) so I even suggest that your schema might be a very good
> place to start for a D&D specific schema. I just think that the XML
> data input to the system should be in a system-generic format. That
> is, the system should not have to read in a D&D schema - it should
> read in a generic schema, even if (god forbid! ;) the generic schema
> is not mine.
I was planning to have this conversion happen in the loader. The
meta-level stuff I was working on was in part to describe how the
various game-level stuff was implemented ('class is a progression',
etc.) but largely because I discovered it was the easiest way to
implement the loader.
I'm hesitant to include a 'compile' step in creating data files, if it
has to be manually triggered. OTOH, it isn't entirely unreasonable to
have a transformation run -- using XSLT -- if the timestamps on the
files indicate it. That'd provide a validation layer before the file
gets loaded at all, which I like the idea of.
Okay, let's go with that. Files will be shipped in 'game' mode. A
'make' is done whenever a file gets loaded; if the 'game' file is newer
than the 'raw' file the 'raw' file gets rebuilt (using an XSLT that
either comes with the file, lives centrally, whatever). This provides a
clear validation layer before it hits the system. If the raw file is
present without a game file, nothing needs to be done (which may make
some people happier because it gives a mechanism to help nail down the
> I hope I don't come across as being too argumentative here, but I doHeh, I was starting to get fairly frustrated with you, but that's mostly
> feel that if we're going to spend the time to restructure the PCGen
> data, we should be developing a scheme for the long run, not just the
> immediate future. Developing game specific schemas that get
> translated to a game independent schema is, IMHO, the way to go.
because we were talking about different -- but related -- things and
that wasn't clear to me. OTOH, we didn't get so far as name-calling, so
it didn't get too bad <lol>
See above; I'm inclined to agree with you. I still prefer a state
machine structure to an event-driven one, but if the data can be mapped
from one to the other without involving the user, and performance is
reasonable in a fully-loaded system (I'm not satisfied that this will be
the case), I have nothing to complain about.
Keith Davies I gave my 2yo daughter a strawberry
keith.davies@... Naomi: "Strawberry!"
me: "What do you say?"
Naomi: "*MY* strawberry!"