Loading ...
Sorry, an error occurred while loading the content.
 

Re: [pcgen-xml] Data restructuring

Expand Messages
  • Keith Davies
    ... I really should colorcode the diagrams. *Only* the framework would be built into the system, the various game-specific elements would be added for the
    Message 1 of 8 , Jan 20, 2004
      On Tue, Jan 20, 2004 at 12:23:09AM -0700, Steven Bethard wrote:
      > A brief note about terminology:
      >
      > 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.

      I really should colorcode the diagrams. *Only* the framework would be
      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
      mixed.

      > I would push for a /very/ generic input-to-PCGen schema, with system
      > 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.

      That is currently slated to happen in the loading layer, rather than
      having an additional external transformation from 'game-specific' to
      'generic structure'.

      > > > In my system, skills having Effects is not a problem - you just
      > > > 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
      > classes.
      >
      > 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).

      I'd have to see it. Remember that we're not the ones who have to use
      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, pick
      > > 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. =)

      heh, thanks. Or do kjd:Entity or something. Mmmm, namespaces.

      > > Oh, and FWIW (in this example, at least) basing level progression on
      > > 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?

      That can be dropped relatively easily, though. If level advancement is
      tied to XP and requires that XP be used to advance levels it's tied more
      intimately.

      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&D
      > > 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.

      As above, this would be done in the loader. <class> is more meaningful
      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 things
      > > 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.

      Well you should have said in an earlier post, then; we could have
      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* ever
      > > 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,

      I have no problem with that, though it's not obvious (and possibly
      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 system
      > 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.

      The attachment of ability score to Score is one based on the nature of
      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 could
      > 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.)

      I could actually see this one happening.

      > > > To some degree, this may be true. I've designed an event-driven
      > > > 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?

      It doesn't -- Effects are attached at the Item level, even above Entity
      (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 that
      > 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?)

      Speak Language gives knowledge of new languages to speak, Perform gives
      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 that
      > 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.

      Already done, as Effects are in Item (above even Entity).

      > > No, I think I understand now. I disagree with your design premise,
      > > 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.

      As have I, from the other direction.

      > It has commonalities with your approach too - it defines several
      > different types of "things" that may be associated with characters.
      > Your approach associates Scores, Rankings, Entities, Progressions,
      > Items, Ranks, Spells, etc with characters.

      associates those things with Entities, rather; I see no difference
      between a Character and a Spell (beyond complexity, of course).

      > My approach removes some of the arbitrary distinctions between these,
      > 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.

      I want to get all Entities down to a generic GameObject internal to the
      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 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.

      What about the people encoding the information to be used by the
      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
      troubleshooting.

      > They need only determine how to calculate Abilities or how to add 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.

      Again, how does this behave when there are thousands of entities in the
      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,
      > the XML input to the program does not have to be (and probably should not
      > be) the XML that Data Monkeys encode.

      Nope. Two or three, maybe, and just in this message, so far as I know.

      > The XML that I suggest is generic between role playing systems, and
      > 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.

      heh.

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

      > I hope I don't come across as being too argumentative here, but I do
      > 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.

      Heh, I was starting to get fairly frustrated with you, but that's mostly
      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
      --
      Keith Davies I gave my 2yo daughter a strawberry
      keith.davies@... Naomi: "Strawberry!"
      me: "What do you say?"
      Naomi: "*MY* strawberry!"
    Your message has been successfully submitted and would be delivered to recipients shortly.