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

my schema: races/GUIs/code

Expand Messages
  • Steven Bethard
    Preface: I don t want to write them all below, so just to remind you, in my terminology * Score OrderedSetSelection (i.e. an integer value) * Rating
    Message 1 of 20 , Jan 20, 2004
    • 0 Attachment
      Preface:
      I don't want to write them all below, so just to remind you, in my
      terminology
      * Score <=> OrderedSetSelection (i.e. an integer value)
      * Rating <=> UnorderedSetSelection (will usually be selection of a Feature)
      * Feature <=> BinarySelection (e.g. anything the character either has or
      doesn't have)
      * Item <=> BinaryItemSelection (anything the character either has or doesn't
      have, but of item type, so is not guaranteed to be the same when, say,
      equipment applied changes. It's possible this could just be a Feature too,
      but it seems semantically different enough that I will continue to
      distinguish them until I'm convinced otherwise.)

      *** RACES ***
      <quote who="Frugal">
      > I have always thought that races should be class level 0.
      >
      > A first level human monk should be 0:Human, 1:Monk
      ..
      </quote>

      Just a side note, but in my scheme this would be simple to represent - the
      ClassForLevelX Ratings would start with X=0. Or, you could just associate a
      Race Rating with the character (exactly the same effect, just a different
      name for the variable.) And so that this doesn't sound "Airy-Fairy" ;), one
      possible implementation of this in my system.

      <!-- the rating you would have to define -->
      <rating id="rating.classforlevel0">
      <option refid="feature.race.human" />
      <option refid="feature.race.orc" />
      ...
      </rating>

      <!-- the race feature - would normally have a name, abbreviation, etc. -->
      <feature id="feature.race.human" />

      <!-- the race definition -->
      <effects sourceid="feature.race.human">
      <modify-score targetid="score.skillpointsperlevel">
      $tgtold + 1
      </modify-score>
      <!-- other effects of being a human -->
      ...
      </effects>

      Note that there is no mention of Class or Race in the XML schema itself (and
      thus in the input to the PCGen system). The ideas of Class and Race are just
      specialized structures built from the Rating and Feature structures of my
      schema, that happen to be recognizable by the creator.

      <quote who="Jim">
      > Of course, I think that races, monster levels, templates, and class
      > levels are all really the same thing at the core.
      </quote>

      Yes, exactly how I felt. I called this a Feature, and in the case of Races
      (since this is an unordered set from which a selection must be made), the
      Feature is selected as the value of a Rating (see the example above).


      *** GUIs ***
      <quote who="Frugal">
      > The other end of this problem is the presentation layer. If the input
      > is too generic then how is the GUI going to present this data ?
      </quote>

      I wouldn't claim that this isn't a problem to some degree, but as you can
      see in the GUI I sent out, you still know which Scores, etc. mean what, so
      you can certainly design the GUI around that. I haven't looked at the
      current GUI code, so I'm not sure how it accesses variables, but in theory
      (though I suspect not a very good one), you would just change it from
      accessing Scores directly to accessing scores by ID. My suspicion is that
      this is much easier to say than to do though.

      <quote who="Frugal">
      > I guess all that it would take to convert to a resonable character editor
      > is to have a character object that has a Collection of Scores and when you
      > create a new character register each score with the effect.
      </quote>

      Yup. That would be the plan. My Model isn't quite right now, but what
      should be done is that the Model stores an id-to-Entity map and a list of
      Effects. Creation of a character is just cloning the appropriate Scores for
      that character, and then using the list of Effects to apply all the
      appropriate Effects to these Entities, which will then automatically update
      as the character is modified. Note that if Effects are ordered the same way
      in the list as they are in the data, that Effects will be applied in the
      same order too.


      *** CODE ***
      <quote who="Frugal">
      > I do like this technique. Will it work with either schema? I can already
      > feel my "need to code cool new app" genes rising to the bait ;o)
      </quote>

      In general, yes, this should work with either schema. The disadvantage if
      you want to work with Keith's schema directly (instead of translating to a
      more general one like mine) is that you have a proliferation of Entity
      classes - mine would have 4, Keith's would have 10-20? (I haven't counted
      them, sorry!). In the technique I demonstrated, you need to define a
      different Effect class for each thing that can be affected by an Effect,
      e.g. in my schema: ModifyScore, ModifyFeature, ModifyRanking, ModifyItem.
      In a schema with a lot of different Entities, you probably have to define a
      lot of different Entity Effects. (You might be able to be smart about the
      inheritance hierarchy here though - my suspicion is that if I can come up
      with only 4 Entities, there exists some inheritance hierarchy in which
      Keith's classes derive from only 4 superclasses.)

      <quote who="Frugal">
      > Is there an easy way of lowering Varaibles without needing a 'reverse'
      > formula (i.e. as well as needing a "if >5 ranks bluff and oldVal<5 give +2
      > to variable.skill.diplomacy.synergy" we also have to have "if <5 ranks
      > bluff and oldVal>=5 then give -2 to variable.skill.diplomacy.synergy"
      </quote>

      If nothing else, we can provide a shorthand, say,
      <modify-score targetid="..." sourcethreshold="..." targetbonus="..."
      />
      I would then probably create a subclass of ModifyScore called
      ThresholdModifyScore, that contained the appropriate logic in code (instead
      of a formula in the XML). There might be a better way to write the formula
      - I'll have to think about it. But I suspect that we'll find that there are
      a number of useful shorthands, and as long as they don't seem too game
      dependent, I'm all for putting them in.

      <quote who="Frugal">
      > Following on from this: Is there an easy way to add and remove other
      > object with effects (i.e. feats). If we have the feat Toughness that give
      > +3HP, do we need to have the "removed toughness" effect of -3 HP.
      </quote>

      Using my newly introduced shorthand above you might have something like:
      <effects sourceid="feature.feat.toughness">
      <modify-score targetid="score.hp" sourcethreshold="1"
      targetbonus="3" />
      </effects>
      Where I've assumed that Features range in value between 0 (not present) and
      1 (present). Thus when the Feat Toughness is added,
      "feature.feat.toughness" increases to 1, and 3 HP are added. If Toughness
      is removed, "feature.feat.toughness" is decreased to 0, and 3 HP are
      removed.

      <quote who="Frugal">
      > How would an observer pattern deal with variables which do not stack.
      > I.e. if you have a +4 armuor bonus and you get an item that give a +2
      > armour bonus you should end up with a +4, not a +6
      </quote>

      The way I've planned on doing this so far is to have a separate Score for
      each type of bonus mod. In general, bonus mod Scores are set, not added to.
      So, for your example, your AC Score would be the sum of (maybe 10?)
      different bonus-type scores. When setting one of these bonus mod Scores,
      you could just do a max() of the calculated score for the mod, and the
      current score for the mod. (max() can be provided as a formula function, or
      a shorthand attribute depending on what we decide is cleaner.)

      <quote who="Frugal">
      > Has anyone approached Bryan to see about branching the code? I think that
      > with all of the proposed changes, and all of the changes that will occur
      > because of data model changes it might be better to brnach the code at
      > 5.7.1 and develop on a separate tree. These changes are going to be so
      > broad that people are not going to want a mostly broken PCGen for 6
      > months.
      </quote>

      I haven't brought this up, but I think this is a very good idea. Both Keith
      and I want to make some sweeping changes, and no matter which ones we go
      with, we'll end up having a broken product for a while. Branching the code
      sounds like a smart solution.

      Steve

      _____

      You can wordify anything if you just verb it.
      - Bucky Katt, Get Fuzzy
    • Frugal
      ... The problem is that I can have a piece of equipment giving a bonus of +4 to score.ac.mod.armor and a spell effect giving +5 to score.ac.mod.armour. 1 - How
      Message 2 of 20 , Jan 20, 2004
      • 0 Attachment
        On Tuesday 20 January 2004 16:54, Steven Bethard wrote:
        > <quote who="Frugal">
        >
        > > How would an observer pattern deal with variables which do not stack.
        > > I.e. if you have a +4 armuor bonus and you get an item that give a +2
        > > armour bonus you should end up with a +4, not a +6
        >
        > </quote>
        >
        > The way I've planned on doing this so far is to have a separate Score for
        > each type of bonus mod. In general, bonus mod Scores are set, not added
        > to. So, for your example, your AC Score would be the sum of (maybe 10?)
        > different bonus-type scores. When setting one of these bonus mod Scores,
        > you could just do a max() of the calculated score for the mod, and the
        > current score for the mod. (max() can be provided as a formula function,
        > or a shorthand attribute depending on what we decide is cleaner.)

        The problem is that I can have a piece of equipment giving a bonus of +4 to
        score.ac.mod.armor and a spell effect giving +5 to score.ac.mod.armour.

        1 - How does it know that the +5 does not stack with the +4 ?

        2- If I take the higher of the 2 (in this case +5) and then remove the +4
        equipment what is to stop the score.ac.mod.armour from dropping to +1 ?

        --
        regards,
        Frugal
        -OS Chimp
      • CC Noram Carstensen James
        Steve, I like what you re saying, but I m not sure PCGen is the forum for it. I would love a very open way to represent a character and the rules for
        Message 3 of 20 , Jan 20, 2004
        • 0 Attachment
          Steve,

          I like what you're saying, but I'm not sure PCGen is the forum for it.

          I would love a very open way to represent a character and the rules for
          generating it, so I could use the same generator for D&D, Champions, and
          any other game I play. I think what you're suggesting could handle
          that.

          However, I see this as being a pain to write. In a fairly rules-static
          game (say a closed source game where the publisher isn't adding new
          rules all the time), this isn't an issue. For something like D20, where
          there one of the design goals is to make it easy for people to
          understand and enter LST files by hand, I think what you have is
          overkill and harder to use because it's a step farther from what people
          are doing - coding D20. Or, as Keith would say, representing the
          problem set.

          Even considering different XML schemas, we'd be looking at: One generic
          master schema, one easy-user-entry schema, and one pcgen data schema,
          with the later two convertible to the first. From a debugging point of
          view (what you put in is really what you get), the user-entry schema and
          the PCGen schema should be the same.

          Which means you have a schema that users write and PCGen reads, and a
          master schema that it can be converted into. At this point, since
          neither the users nor PCGen read the master schema, it can be develop
          separately without impact on the PCGen project. I would actually be
          interested in discussing it - I have some ideas that I think fit very
          well with what you have already envisioned, but I'm not sure that
          for-PCGen-use is the place to consider this, at least at this point.

          Cheers,
          Jim
        • Steven Bethard
          ... I m not sure what the Master schema is - could you explain? I had in mind only two schemas currently: a easy-user-entry schema,
          Message 4 of 20 , Jan 20, 2004
          • 0 Attachment
            <quote who="Jim">
            > Even considering different XML schemas, we'd be looking at: One generic
            > Master schema, one easy-user-entry schema, and one pcgen data schema,
            > with the later two convertible to the first. From a debugging point of
            > view (what you put in is really what you get), the user-entry schema and
            > the PCGen schema should be the same.
            </quote>

            I'm not sure what the Master schema is - could you explain? I had in mind
            only two schemas currently: a easy-user-entry schema, and a generic pcgen
            data schema. I have been discussing the generic pcgen data schema here, but
            if this forum is intended mainly for the easy-user-entry schema (not the
            pcgen data schema), I can certainly start a separate forum for this
            discussion.

            Yes, it does mean that there are now two levels to debug - the code and the
            user data -> pcgen data transform. But I would contend that because of the
            simplicity of the encoding, both the code and the transform will be simpler
            to debug. If I'm wrong here though, I certainly see your point - two levels
            that are hard to debug is worse than one level that is hard to debug...

            Steve
            _____

            You can wordify anything if you just verb it.
            - Bucky Katt, Get Fuzzy
          • Keith Davies
            ... No need, as long as it s clearly indicated. Perhaps flag the subject with [int] and [ext]? I ve mostly be focusing on the easy-user-entry schema ([ext]);
            Message 5 of 20 , Jan 20, 2004
            • 0 Attachment
              On Tue, Jan 20, 2004 at 10:31:26AM -0700, Steven Bethard wrote:
              > <quote who="Jim">
              > > Even considering different XML schemas, we'd be looking at: One
              > > generic Master schema, one easy-user-entry schema, and one pcgen
              > > data schema, with the later two convertible to the first. From a
              > > debugging point of view (what you put in is really what you get),
              > > the user-entry schema and the PCGen schema should be the same.
              > </quote>
              >
              > I'm not sure what the Master schema is - could you explain? I had in
              > mind only two schemas currently: a easy-user-entry schema, and a
              > generic pcgen data schema. I have been discussing the generic pcgen
              > data schema here, but if this forum is intended mainly for the
              > easy-user-entry schema (not the pcgen data schema), I can certainly
              > start a separate forum for this discussion.

              No need, as long as it's clearly indicated. Perhaps flag the subject
              with [int] and [ext]?

              I've mostly be focusing on the easy-user-entry schema ([ext]); you were
              describing generic (internal) pcgen data schema ([int]). Both are
              appropriate for this list.

              > Yes, it does mean that there are now two levels to debug - the code
              > and the user data -> pcgen data transform. But I would contend that
              > because of the simplicity of the encoding, both the code and the
              > transform will be simpler to debug. If I'm wrong here though, I
              > certainly see your point - two levels that are hard to debug is worse
              > than one level that is hard to debug...

              ext->int provides a clear validation layer. As a result, you don't have
              to worry about even starting to load a file that turns out broken for
              syntactic reasons. This is very good.

              ext->int converts between something a user understands -- it looks like
              the data they're trying to encode, after all -- and something PCGen
              understands. This means that a knowledgeable reader will be able to
              easily get at both what he entered, and what PCGen understands. This is
              very, very good.

              In fact, we may even want to offer a facility for examining these
              files -- open the ext file and the int file (the elements in both
              should more or less correspond, or be made to) and visually compare
              them. This would probably help no end with troubleshooting data.

              Do you have a specification for your schema? I'm becoming very
              interested in how to map between them, and if your effects model suits I
              may lift that in toto.


              Keith
              --
              Keith Davies I gave my 2yo daughter a strawberry
              keith.davies@... Naomi: "Strawberry!"
              me: "What do you say?"
              Naomi: "*MY* strawberry!"
            • Steven Bethard
              Awesome, sounds like we re more or less in agreement on some important points. Woo-hoo! =) So we ll aim for a user-entry schema [ext] to be translated to a
              Message 6 of 20 , Jan 20, 2004
              • 0 Attachment
                Awesome, sounds like we're more or less in agreement on some important
                points. Woo-hoo! =) So we'll aim for a user-entry schema [ext] to be
                translated to a system-internal schema [int]. Note that exactly where the
                translation happens is not horribly crucial at the moment - we can either
                have a "compile" step for the users which actually outputs the transformed
                file, or the function that loads resources can take an optional XSLT
                parameter, and the transform can be applied immediately before the data is
                read in. Either way, the system only sees [int] data.

                I'd like to work on mapping your schema to mine, which will inevitably
                involve modifying my schema some to accommodate - but hey, that's part of
                the development process, right? I'll need to make sure I understand all the
                bits of your schema first, though, so I'm going to ask a few questions here
                first.

                kjd:Entities
                You said that kjd:Entities can be characters, spells, etc, and I can then
                "associate" any kjd:Entity with any other kjd:Entity. I'm a little unclear
                as to what "associate" means in system mechanics. If I associate a Feat
                entity with a Spell entity, what are the semantics here? Does this mean
                that the Spell (as a being) can use the Feat? Or that the Spell grants the
                Feat to the character using that Spell?

                kjd:Progressions
                Your progressions are a means of associating kjd:Effects with a variable,
                depending on the value of the variable, right? So if Strength is a
                kjd:Progression, I could define that at Strength 25, the kjd:Effect "grant
                character a Feat" would occur. Or if the Fighter class is a
                kjd:Progression, I could define that at Fighter class level 1, the
                kjd:Effect "increase base attack bonus by 1" would occur. Am I interpreting
                this correctly?

                kjd:Effects
                I know you haven't spent too much time on these yet, but can any kjd:Entity
                cause an kjd:Effect on any other kjd:Entity, or do they have to be
                "associated" kjd:Entities? (You may end up answering this in your response
                to my kjd:Entities section, so if so, please disregard it here.)


                For contrast, here would be the important elements for my schema:
                sjb:Features
                These are "things" (which generally cause sjb:Effects) that can be
                associated with game entities (I had assumed we would only be associating
                things with Characters, but it sounds like you have some good reasons for
                associating things with other game entities too, so I'm open to this
                interpretation as well.)

                sjb:Scores
                If my description of kjd:Progressions above is correct, sjb:Scores provide
                exactly the same functionality in my system. You associate sjb:Effects with
                the various values of a sjb:Score and those sjb:Effects occur when that
                value is attained (and are removed if that value later drops).

                sjb:Ratings
                These were just my way of requiring a character to select a sjb:Feature from
                the list. In retrospect, this sounds more like an attribute to the
                <add-feature /> sjb:Effect than an actual game Entity. Okay - drop 'em.

                sjb:Items
                These actually act much like sjb:Features, so they could probably be merged
                if I was careful about this. I only treated them different because I
                thought it might be useful to make a distinction between sjb:Features that
                always grant their Effects and sjb:Features which only grant their Effects
                when equipped. In retrospect though, it would be relatively simple to keep
                two lists - the list of sjb:Features currently applying to the character
                (this would include all Feats and any equipped Items), and the list of all
                sjb:Features in the posession of the character but that do not currently
                apply (e.g. unequipped items). Sure, get rid of sjb:Items. They're
                unnecessary.

                So the only elements in my (revised) schema are sjb:Features and sjb:Scores.
                I definitely need to wait for your responses here, but it sounds like we
                might have the beginning of a mapping:
                kjd:Entity -> sjb:Feature
                kjd:Progression -> sjb:Score

                Steve
                _____

                You can wordify anything if you just verb it.
                - Bucky Katt, Get Fuzzy

                P.S. I'm open to renaming some of my classifications once we've hashed some
                of this out, if it seems like that would make the translation clearer. We
                can talk about this once I'm more certain of the correspondence.
              • Keith Davies
                ... I was speaking a little imprecisely. Technically we *can*, but it doesn t always make sense to. Your example is a good case of that. To be more precise,
                Message 7 of 20 , Jan 20, 2004
                • 0 Attachment
                  On Tue, Jan 20, 2004 at 01:48:54PM -0700, Steven Bethard wrote:
                  > Awesome, sounds like we're more or less in agreement on some important
                  > points. Woo-hoo! =) So we'll aim for a user-entry schema [ext] to be
                  > translated to a system-internal schema [int]. Note that exactly where
                  > the translation happens is not horribly crucial at the moment - we can
                  > either have a "compile" step for the users which actually outputs the
                  > transformed file, or the function that loads resources can take an
                  > optional XSLT parameter, and the transform can be applied immediately
                  > before the data is read in. Either way, the system only sees [int]
                  > data.
                  >
                  > I'd like to work on mapping your schema to mine, which will inevitably
                  > involve modifying my schema some to accommodate - but hey, that's part
                  > of the development process, right? I'll need to make sure I
                  > understand all the bits of your schema first, though, so I'm going to
                  > ask a few questions here first.
                  >
                  > kjd:Entities
                  > You said that kjd:Entities can be characters, spells, etc, and I can
                  > then "associate" any kjd:Entity with any other kjd:Entity. I'm a
                  > little unclear as to what "associate" means in system mechanics. If I
                  > associate a Feat entity with a Spell entity, what are the semantics
                  > here? Does this mean that the Spell (as a being) can use the Feat?
                  > Or that the Spell grants the Feat to the character using that Spell?

                  I was speaking a little imprecisely. Technically we *can*, but it
                  doesn't always make sense to. Your example is a good case of that. To
                  be more precise, it is my expectation that it will be possible to
                  describe how they interact and are associated. If no such description
                  exists, there is no immediate association. I do not currently have a
                  way devised for specifying these relationships and associations.


                  > kjd:Progressions
                  > Your progressions are a means of associating kjd:Effects with a variable,
                  > depending on the value of the variable, right?

                  I suppose it could be seen that way.

                  > So if Strength is a
                  > kjd:Progression, I could define that at Strength 25, the kjd:Effect "grant
                  > character a Feat" would occur. Or if the Fighter class is a
                  > kjd:Progression, I could define that at Fighter class level 1, the
                  > kjd:Effect "increase base attack bonus by 1" would occur. Am I interpreting
                  > this correctly?

                  This is true. I expect to have recurring effects, though, so it isn't
                  necessary to repeat effects in each rank. For instance, I expect to be
                  able to say 'add 1 to BAB at each level' rather than, in each level, say
                  'add 1 to BAB'.

                  (incidentally, IMC I plan to define 'Good BAB', 'Medium BAB', and 'Poor
                  BAB' progressions (which add to BAB), then have class levels grant ranks
                  in these progressions. This means that a Sor1/Wiz1 will have a BAB of +1
                  rather than +0. Same thing for base saves.)

                  > kjd:Effects
                  > I know you haven't spent too much time on these yet, but can any
                  > kjd:Entity cause an kjd:Effect on any other kjd:Entity, or do they
                  > have to be "associated" kjd:Entities? (You may end up answering this
                  > in your response to my kjd:Entities section, so if so, please
                  > disregard it here.)

                  I expect that almost all Entities will only affect what they are
                  associated with. However, the effects available from an entity are
                  unlimited, the full range will be available. If desired, for example, a
                  feat can give an extra level of spellcasting ability, a rank of a skill
                  could give a level in a class, whatever.

                  Synergy bonuses are the only case I can really think of that isn't
                  immediately attached, and that's because I don't see that it would be
                  appropriate to include it in either the source skill or the target skill
                  of the synergy bonus. This is mostly for maintenance reasons, though;
                  I'm trying to make it so that adding a new entity to the system doesn't
                  require modification of another, old entity -- I'm trying to keep their
                  content static.

                  > For contrast, here would be the important elements for my schema:
                  >
                  > sjb:Features
                  > These are "things" (which generally cause sjb:Effects) that can be
                  > associated with game entities (I had assumed we would only be
                  > associating things with Characters, but it sounds like you have some
                  > good reasons for associating things with other game entities too, so
                  > I'm open to this interpretation as well.)

                  I think it's a good idea. Many things are subject to creation,
                  modification. or customization. For instance, magic weapons -- an
                  enchanted sword might be a longsword, plus a masterwork modification,
                  plus a number of ranks in 'enchanted weapon' progression, plus some
                  assorted other modifications (which themselves may be either entities or
                  progressions, depending how they behave). A spell... doesn't have a lot
                  of room for customization, unless we create new entities for spells with
                  attached metamagics (which might not be *that* bad an idea, actually).

                  I see no reason for characters to be a special case.

                  > sjb:Scores
                  > If my description of kjd:Progressions above is correct, sjb:Scores
                  > provide exactly the same functionality in my system. You associate
                  > sjb:Effects with the various values of a sjb:Score and those
                  > sjb:Effects occur when that value is attained (and are removed if that
                  > value later drops).

                  That seems right.

                  > sjb:Ratings
                  > These were just my way of requiring a character to select a
                  > sjb:Feature from the list. In retrospect, this sounds more like an
                  > attribute to the <add-feature /> sjb:Effect than an actual game
                  > Entity. Okay - drop 'em.

                  Okay. A rating (which you'll probably note isn't in the UML) was
                  originally a method of associating things, a constrained selection list.
                  I agree that it can be dropped; it doesn't really make sense if we're
                  going to have other ways of requiring associations anyway (such as 'each
                  character must have an attached race').

                  > sjb:Items
                  > These actually act much like sjb:Features, so they could probably be
                  > merged if I was careful about this. I only treated them different
                  > because I thought it might be useful to make a distinction between
                  > sjb:Features that always grant their Effects and sjb:Features which
                  > only grant their Effects when equipped. In retrospect though, it
                  > would be relatively simple to keep two lists - the list of
                  > sjb:Features currently applying to the character (this would include
                  > all Feats and any equipped Items), and the list of all sjb:Features in
                  > the posession of the character but that do not currently apply (e.g.
                  > unequipped items). Sure, get rid of sjb:Items. They're unnecessary.
                  >
                  > So the only elements in my (revised) schema are sjb:Features and
                  > sjb:Scores. I definitely need to wait for your responses here, but it
                  > sounds like we might have the beginning of a mapping:
                  > kjd:Entity -> sjb:Feature
                  > kjd:Progression -> sjb:Score

                  Given that kjd:Entity is something that we want to keep track of for its
                  own sake -- spell, skill, etc. -- then I think that looks about right.
                  An association between an Entity and a Progression does have a 'score'
                  (the number of ranks in that Progression).

                  So, if we've come this far and determined that they are in fact the same
                  thing, how 'bout we settle on using a single term for each of them? (of
                  course, I lean more toward mine...). I'm not at all concerned that you
                  take an ext:class and smash it down to an int:Progression; in fact,
                  that's what I expected to do.

                  How were you planning to associate effects to scores, though? In XML,
                  do something like:

                  <score id='score.str' />

                  <effect refid='score.str' test='$old < 25 and $new >= 25'>
                  <!-- do stuff -->
                  </effect>

                  ?

                  I can see that converting a Class progression to that wouldn't be too
                  hard, but what about the other direction? Or in memory, are the effects
                  associated to the thing they are based on, that is

                  Score {
                  Effect[] effects;
                  }

                  and when the score changes all effects are scanned and processed as
                  needed? (or scanned when doing output, for example).


                  Keith
                  --
                  Keith Davies I gave my 2yo daughter a strawberry
                  keith.davies@... Naomi: "Strawberry!"
                  me: "What do you say?"
                  Naomi: "*MY* strawberry!"
                • Steven Bethard
                  ... to ... Hey, sorry, you re right - I apoligize for not thinking about this one hard enough before I responded. What we really
                  Message 8 of 20 , Jan 20, 2004
                  • 0 Attachment
                    <quote who="Frugal">
                    > The problem is that I can have a piece of equipment giving a bonus of +4
                    to
                    > score.ac.mod.armor and a spell effect giving +5 to score.ac.mod.armour.
                    >
                    > 1 - How does it know that the +5 does not stack with the +4 ?
                    >
                    > 2- If I take the higher of the 2 (in this case +5) and then remove the +4
                    > equipment what is to stop the score.ac.mod.armour from dropping to +1 ?
                    </quote>

                    Hey, sorry, you're right - I apoligize for not thinking about this one hard
                    enough before I responded. What we really want here is a way that one
                    sjb:Effect can suppress another sjb:Effect. So, I think the way to do this
                    to declare for a sjb:Score the number of allowable sjb:Effects that can be
                    applied to this sjb:Score at one time. In XML, this could look something
                    like:
                    <def:score id="score.ac.mod.armor" maxeffects="1" />
                    The idea here is that you should only have one effect that grants a bonus to
                    the AC armor mod being applied at any given time.

                    For this problem, we also want which armor mod gets selected to be chosen by
                    selecting the one with the maximum value. I would suggest encoding this as:
                    <def:score id="score.ac.mod.armor" maxeffects="1"
                    effectpriority="maxvalue" />
                    Thus you select 1 sjb:Effect by choosing the sjb:Effect for this Score that
                    would produce the highest value.

                    The current code model I proposed does not directly support this, though I
                    believe there is still a relatively easy way with the Observer-Observable
                    pattern to support this kind of behavior (involving using a custom
                    Observable base class.) I'll hold off on comments about the code end until
                    I'm certain that this is true.

                    As far as the [int] schema is concerned, I'm convinced that we do need to
                    provide some additional attributes or something to allow for this type of
                    behavior. If there is a clearer (but still relatively game system
                    independent) way of representing this, I'm open to suggestions.

                    Steve
                    _____

                    You can wordify anything if you just verb it.
                    - Bucky Katt, Get Fuzzy
                  • Steven Bethard
                    ... Yeah, I agree. Much as I like namespaces, I wouldn t mind not having to write them anymore ;). Having discarded sjb:Rating
                    Message 9 of 20 , Jan 20, 2004
                    • 0 Attachment
                      <quote who="Keith">
                      > So, if we've come this far and determined that they are in fact the same
                      > thing, how 'bout we settle on using a single term for each of them? (of
                      > course, I lean more toward mine...). I'm not at all concerned that you
                      > take an ext:class and smash it down to an int:Progression; in fact,
                      > that's what I expected to do.
                      </quote>

                      Yeah, I agree. Much as I like namespaces, I wouldn't mind not having to
                      write them anymore ;). Having discarded sjb:Rating and sjb:Item, I like
                      your term Entity much better than my term Feature, so from now on, I'll use
                      Entity.

                      In the sjb:Score vs. kjd:Progression situation, I think that sjb:Score is
                      the more natural term. Effects are associated both with the values of a
                      variable in a kjd:Progression and with other Entities. The term
                      "progression" sounds to me like the Effects are an inherent part of
                      Progressions, whereas "entity" doesn't sound like Effects are an inherent
                      part of Entities. Note that D&D has a number of skills (which are
                      represented as Progressions) that do not cause Effects based on their value.
                      So it doesn't seem like Effects are inherent in kjd:Progressions. I guess
                      the terminology seems a little inconsistent to me, so unless you don't mind
                      calling them Scores, I'm inclined to put off merging the two terms until we
                      see better how Effects will be implemented in the two schemas (with the
                      hopes that the use of Effects will clarify which is the more natural term.)

                      <quote who="Keith">
                      > How were you planning to associate effects to scores, though? In XML,
                      > do something like:
                      >
                      > <score id='score.str' />
                      >
                      > <effect refid='score.str' test='$old < 25 and $new >= 25'>
                      > <!-- do stuff -->
                      > </effect>
                      >
                      > ?
                      </quote>

                      Frugal and I have been discussing some of these issues - I would now code
                      the example above something like:
                      <effects sourceid="score.ability.str" threshold="25">
                      <add-entity targetid="character.x.y" entityid="feat.uberstrength">
                      </effects>
                      With the idea being that if Strength reaches 25, the Feat "Uberstrength" is
                      added to the character with the id "character.x.y" (and vice-versa, if
                      Strength drops below 25, this Feat would be removed.)

                      I also expect to use the same kind of shorthands you do to indicate
                      recurring Effects (e.g. you should not have to indicate that for a class, at
                      a score of 1, you get a d8 HD, at score of 2 you get another d8 HD, etc.)

                      <quote who="Keith">
                      > I can see that converting a Class progression to that wouldn't be too
                      > hard, but what about the other direction?
                      </quote>

                      Sorry, I missed this one. What do you mean by "the other direction"? From
                      an Effects list back to a kjd:Progression?

                      <quote who="Keith">
                      > Or in memory, are the effects
                      > associated to the thing they are based on, that is
                      >
                      > Score {
                      > Effect[] effects;
                      > }
                      >
                      > and when the score changes all effects are scanned and processed as
                      > needed? (or scanned when doing output, for example).
                      </quote>

                      Yes, this is basically what the Observer-Observable pattern does - the
                      sjb:Score would tell all Effects dependent on it that its value had changed,
                      and then the Effects could correct themselves as necessary (which would
                      occasionally cause other sjb:Scores to update, etc.) The advantage of this,
                      is that we never scan irrelevant lists of things to update. Only the
                      Effects that depend directly on the value of this sjb:Score are called to
                      correct themselves. If we don't update these values at some point, they're
                      wrong, so it's not like we can avoid doing these updates forever.

                      The other solution to this (something similar to what Scott was suggesting,
                      I think) is to associate with each Score a flag that says "I could be
                      wrong!" and every time you need that Score, you first check it's "I could be
                      wrong!" tag and the "I could be wrong!" tags of any Scores that it depends
                      on. Note that even in this scheme, at some point, you'll have to go and
                      check all the Scores that the Score you want to update is dependent on. (Or
                      just check /all/ the other Scores if you don't want to maintain a dependency
                      list. This makes me nervous though because it doesn't necessarily guarantee
                      a reasonable order of Score updating.)

                      My experience is that the Observer-Observable pattern solves this problem
                      with the least hassle and the easiest to maintain code. If anyone has a
                      simpler or cleaner way to handle the update problem though, I'm open to
                      suggestions.

                      Steve
                      _____

                      You can wordify anything if you just verb it.
                      - Bucky Katt, Get Fuzzy
                    • Keith Davies
                      ... Sure. ... In most cases I prefer to store the definitions of the effects in the Progression because they don t make sense outside it. At at least one
                      Message 10 of 20 , Jan 20, 2004
                      • 0 Attachment
                        On Tue, Jan 20, 2004 at 03:54:02PM -0700, Steven Bethard wrote:
                        > <quote who="Keith">
                        > > So, if we've come this far and determined that they are in fact the
                        > > same thing, how 'bout we settle on using a single term for each of
                        > > them? (of course, I lean more toward mine...). I'm not at all
                        > > concerned that you take an ext:class and smash it down to an
                        > > int:Progression; in fact, that's what I expected to do.
                        > </quote>
                        >
                        > Yeah, I agree. Much as I like namespaces, I wouldn't mind not having
                        > to write them anymore ;). Having discarded sjb:Rating and sjb:Item, I
                        > like your term Entity much better than my term Feature, so from now
                        > on, I'll use Entity.
                        >
                        > In the sjb:Score vs. kjd:Progression situation, I think that sjb:Score
                        > is the more natural term. Effects are associated both with the values
                        > of a variable in a kjd:Progression and with other Entities. The term
                        > "progression" sounds to me like the Effects are an inherent part of
                        > Progressions, whereas "entity" doesn't sound like Effects are an
                        > inherent part of Entities. Note that D&D has a number of skills
                        > (which are represented as Progressions) that do not cause Effects
                        > based on their value. So it doesn't seem like Effects are inherent in
                        > kjd:Progressions. I guess the terminology seems a little inconsistent
                        > to me, so unless you don't mind calling them Scores, I'm inclined to
                        > put off merging the two terms until we see better how Effects will be
                        > implemented in the two schemas (with the hopes that the use of Effects
                        > will clarify which is the more natural term.)

                        Sure.

                        > <quote who="Keith">
                        > > How were you planning to associate effects to scores, though? In XML,
                        > > do something like:
                        > >
                        > > <score id='score.str' />
                        > >
                        > > <effect refid='score.str' test='$old < 25 and $new >= 25'>
                        > > <!-- do stuff -->
                        > > </effect>
                        > >
                        > > ?
                        > </quote>
                        >
                        > Frugal and I have been discussing some of these issues - I would now code
                        > the example above something like:
                        > <effects sourceid="score.ability.str" threshold="25">
                        > <add-entity targetid="character.x.y" entityid="feat.uberstrength">
                        > </effects>
                        > With the idea being that if Strength reaches 25, the Feat
                        > "Uberstrength" is added to the character with the id "character.x.y"
                        > (and vice-versa, if Strength drops below 25, this Feat would be
                        > removed.)
                        >
                        > I also expect to use the same kind of shorthands you do to indicate
                        > recurring Effects (e.g. you should not have to indicate that for a
                        > class, at a score of 1, you get a d8 HD, at score of 2 you get another
                        > d8 HD, etc.)

                        In most cases I prefer to store the definitions of the effects in the
                        Progression because they don't make sense outside it. At at least one
                        level, I'm trying to reduce the number of things to keep track of...
                        there's enough of them already, and blowing classes out to (potentially)
                        20 times the number of objects doesn't set right with me.

                        > <quote who="Keith">
                        > > I can see that converting a Class progression to that wouldn't be too
                        > > hard, but what about the other direction?
                        > </quote>
                        >
                        > Sorry, I missed this one. What do you mean by "the other direction"?
                        > From an Effects list back to a kjd:Progression?

                        Yes. We have to be able to export the definitions back out of the
                        program.

                        > <quote who="Keith">
                        > > Or in memory, are the effects
                        > > associated to the thing they are based on, that is
                        > >
                        > > Score {
                        > > Effect[] effects;
                        > > }
                        > >
                        > > and when the score changes all effects are scanned and processed as
                        > > needed? (or scanned when doing output, for example).
                        > </quote>
                        >
                        > Yes, this is basically what the Observer-Observable pattern does - the
                        > sjb:Score would tell all Effects dependent on it that its value had
                        > changed, and then the Effects could correct themselves as necessary
                        > (which would occasionally cause other sjb:Scores to update, etc.) The
                        > advantage of this, is that we never scan irrelevant lists of things to
                        > update. Only the Effects that depend directly on the value of this
                        > sjb:Score are called to correct themselves. If we don't update these
                        > values at some point, they're wrong, so it's not like we can avoid
                        > doing these updates forever.

                        Hrm. I'm familiar with Observer-Observable, but in this case doesn't it
                        lead to a huge number of links back and forth? Any Entity may have
                        observable properties, so wouldn't each Entity need to register?

                        Assuming, of course, that loaded Entities aren't locked down so they
                        cannot change.


                        > The other solution to this (something similar to what Scott was
                        > suggesting, I think) is to associate with each Score a flag that says
                        > "I could be wrong!" and every time you need that Score, you first
                        > check it's "I could be wrong!" tag and the "I could be wrong!" tags of
                        > any Scores that it depends on. Note that even in this scheme, at some
                        > point, you'll have to go and check all the Scores that the Score you
                        > want to update is dependent on. (Or just check /all/ the other Scores
                        > if you don't want to maintain a dependency list. This makes me
                        > nervous though because it doesn't necessarily guarantee a reasonable
                        > order of Score updating.)


                        > My experience is that the Observer-Observable pattern solves this
                        > problem with the least hassle and the easiest to maintain code. If
                        > anyone has a simpler or cleaner way to handle the update problem
                        > though, I'm open to suggestions.

                        There may not be really *good* way of doing it when we have this many
                        entities to track. Both Observer and Scott's solution depend on things
                        being readonly in order to avoid using lots of resources if any Entity
                        is subject to change.

                        . Observer would require that each thing that can change have an
                        observer attached; managing this would lead to massive resource
                        consumption.
                        . Scott's model would, since dependencies presumably run only one way,
                        require that invalidated data be checked frequently.

                        Now, if things are limited as to when they can change (either readonly
                        once loaded, or allowed to change only if in the file being edited [my
                        preference, since it allows for multiple edits at once], or readonly
                        unless 'edit mode' is entered) then the resources for Observer and
                        Scott's model both drop immensely.

                        I think we can simplify things for ourselves significantly if we make a
                        few rules. How do these sound?

                        0. a file may contain more than one type of Entity.

                        Convention and practice may choose not to do this ('only put skills in
                        this file') but it will not be enforced by us. It must be possible
                        to, for example, export everything needed for a campaign into a single
                        file (it is not necessary to implement this function, just that file
                        must be capable of holding this information).

                        1. a file may contain more than one Entity.

                        This one seems pretty obvious; if we have to define each spell in a
                        separate file it's going to get really old, really fast.

                        2. all Entities loaded from a file will have the same readonly status.
                        3. only Entities from the file being edited may be directly modified.

                        These two tie together. A file may depend on a number of files, but
                        when editing a single file, only things in that file may be directly
                        changed. Everything else is locked down. This will reduce the
                        potential number of dependencies that have to be managed at any given
                        time -- if I know that 'Fighter' isn't going to change I don't need to
                        watch for changes (Observer) or check for invalidated information
                        (Scott).

                        Entities in the file being modified still need to be watched, but that
                        is a very much smaller subset of what will be available to work with.

                        4. transaction-type operations in a file may modify Entities from
                        another file; this is expected to be done primarily in central files
                        to avoid loss.

                        This is for the MOD capability we have in LST now, though Doug and I
                        think we may have a better way of doing it. Basically, it means that
                        if someone wants to redefine something he can, but it does not change
                        the core definition. These changes should be kept in a central area
                        (not the core area, but under custom/ or something) so that it can be
                        reused.


                        Keith
                        --
                        Keith Davies I gave my 2yo daughter a strawberry
                        keith.davies@... Naomi: "Strawberry!"
                        me: "What do you say?"
                        Naomi: "*MY* strawberry!"
                      • Frugal
                        ... The easiest way to do this is to keep a track of which effect gave which bonus. i.e. when Score.update(int) is called also
                        Message 11 of 20 , Jan 21, 2004
                        • 0 Attachment
                          <quote who="Steven Bethard">
                          > For this problem, we also want which armor mod gets selected to be chosen
                          > by
                          > selecting the one with the maximum value. I would suggest encoding this
                          > as:
                          > <def:score id="score.ac.mod.armor" maxeffects="1"
                          > effectpriority="maxvalue" />
                          > Thus you select 1 sjb:Effect by choosing the sjb:Effect for this Score
                          > that
                          > would produce the highest value.

                          The easiest way to do this is to keep a track of which effect gave which
                          bonus. i.e. when Score.update(int) is called also pass the effect that is
                          calling this update so you have Score.update(Effect, int). Then store a
                          map from Effect->Integer.

                          When asked for the value of the Score you find the highest Integer in the
                          Map.

                          This would still need a little expanding for Effects that STACK and
                          untyped Effects that always Stack.

                          --
                          regards,
                          Frugal
                          -OS Chimp
                        • CC Noram Carstensen James
                          ... recurring Effects (e.g. you should not have to indicate that for a class, at a score of 1, you get a d8 HD, at score of 2 you get another d8 HD, etc.)
                          Message 12 of 20 , Jan 21, 2004
                          • 0 Attachment
                            Steve wrote:
                            > I also expect to use the same kind of shorthands you do to indicate
                            recurring Effects (e.g. you should not have to indicate that for a
                            class, at a score of 1, you get a d8 HD, at score of 2 you get another
                            d8 HD, etc.)

                            Would the ability not to do the shorthand still exist? For example, the
                            3.0 Dragon Disciple did have varying HD by level.

                            Hmm, which of course makes me think about the fun undead types that
                            change every previous and future HD to d12. Could something like that
                            be represented?

                            Cheers,
                            Jim
                          • Frugal
                            ... While spanners are cheerfully being thrown into the works: Unarmed Damage. It alters by level, by size category.
                            Message 13 of 20 , Jan 21, 2004
                            • 0 Attachment
                              <quote who="CC Noram Carstensen James">
                              > Steve wrote:
                              >> I also expect to use the same kind of shorthands you do to indicate
                              > recurring Effects (e.g. you should not have to indicate that for a
                              > class, at a score of 1, you get a d8 HD, at score of 2 you get another
                              > d8 HD, etc.)
                              >
                              > Would the ability not to do the shorthand still exist? For example, the
                              > 3.0 Dragon Disciple did have varying HD by level.
                              >
                              > Hmm, which of course makes me think about the fun undead types that
                              > change every previous and future HD to d12. Could something like that
                              > be represented?

                              While spanners are cheerfully being thrown into the works: Unarmed Damage.
                              It alters by level, by size category. Also certain prestige classes allow
                              you to change unarmed damge to the next size category larget, or to the
                              next dice size larger

                              --
                              regards,
                              Frugal
                              -OS Chimp
                            • Steven Bethard
                              ... Absolutely. It would only be a shorthand for the more explicit approach. If the bonuses applied by the
                              Message 14 of 20 , Jan 21, 2004
                              • 0 Attachment
                                <quote who="CC Noram Carstensen James">
                                > Steve wrote:
                                >> I also expect to use the same kind of shorthands you do to indicate
                                > recurring Effects (e.g. you should not have to indicate that for a
                                > class, at a score of 1, you get a d8 HD, at score of 2 you get another
                                > d8 HD, etc.)
                                >
                                > Would the ability not to do the shorthand still exist? For example, the
                                > 3.0 Dragon Disciple did have varying HD by level.
                                >
                                > Hmm, which of course makes me think about the fun undead types that
                                > change every previous and future HD to d12. Could something like that
                                > be represented?
                                </quote>

                                Absolutely. It would only be a shorthand for the more explicit approach.
                                If the bonuses applied by the shorthand are not what you want, you could
                                always go the explicit route.

                                I've got some thought about how to simplify some of the formulae in my code
                                (without losing any of the expressiveness). I'll try to get some time to
                                make these thoughts more explicit and post something in the next few days.

                                <quote who="Frugal>While spanners are cheerfully being thrown into the
                                works:
                                > Unarmed Damage.
                                > It alters by level, by size category. Also certain prestige classes allow
                                > you to change unarmed damge to the next size category larget, or to the
                                > next dice size larger
                                </quote>

                                Yup. So shorthands may not always be possible (though I think a clean
                                solution to part of this problem would be like what I did with size:
                                associate integer values with the different size categories, and just treat
                                increasing size category as increasing the variable in an
                                sjb:Score/kjd:Progression.)

                                --
                                regards,
                                Frugal
                                -OS Chimp



                                Yahoo! Groups Links

                                To visit your group on the web, go to:
                                http://groups.yahoo.com/group/pcgen-xml/

                                To unsubscribe from this group, send an email to:
                                pcgen-xml-unsubscribe@yahoogroups.com

                                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                              • Keith Davies
                                ... For that matter, I would expect that you could make it two recurring effects. One from levels 1-n, another from n+1-10 (or higher, if you go Epic). Keith
                                Message 15 of 20 , Jan 21, 2004
                                • 0 Attachment
                                  On Wed, Jan 21, 2004 at 10:07:40AM -0700, Steven Bethard wrote:
                                  > <quote who="CC Noram Carstensen James">
                                  > > Steve wrote:
                                  > >> I also expect to use the same kind of shorthands you do to indicate
                                  > > recurring Effects (e.g. you should not have to indicate that for a
                                  > > class, at a score of 1, you get a d8 HD, at score of 2 you get another
                                  > > d8 HD, etc.)
                                  > >
                                  > > Would the ability not to do the shorthand still exist? For example, the
                                  > > 3.0 Dragon Disciple did have varying HD by level.
                                  > >
                                  > > Hmm, which of course makes me think about the fun undead types that
                                  > > change every previous and future HD to d12. Could something like that
                                  > > be represented?
                                  > </quote>
                                  >
                                  > Absolutely. It would only be a shorthand for the more explicit
                                  > approach. If the bonuses applied by the shorthand are not what you
                                  > want, you could always go the explicit route.

                                  For that matter, I would expect that you could make it two recurring
                                  effects. One from levels 1-n, another from n+1-10 (or higher, if you go
                                  Epic).


                                  Keith
                                  --
                                  Keith Davies I gave my 2yo daughter a strawberry
                                  keith.davies@... Naomi: "Strawberry!"
                                  me: "What do you say?"
                                  Naomi: "*MY* strawberry!"
                                • CC Noram Carstensen James
                                  ... solution to part of this problem would be like what I did with size: associate integer values with the different size categories, and just treat increasing
                                  Message 16 of 20 , Jan 22, 2004
                                  • 0 Attachment
                                    Steve wrote:
                                    > Yup. So shorthands may not always be possible (though I think a clean
                                    solution to part of this problem would be like what I did with size:
                                    associate integer values with the different size categories, and just
                                    treat increasing size category as increasing the variable in an
                                    sjb:Score/kjd:Progression.)

                                    Could you have multi-dimensional kjd:Progressions? Frugal mentioned
                                    monk unarmed damage. To put this into array-speak, could you have a
                                    progression Unarmed[Level,Size] such that you can represent all of the
                                    different combinations, and also have easy ways of doing things like
                                    representing the enlarged (+1 size) monk who is wearing a Monk's Belt
                                    (bonus to monk level) because it just changes the lookup on the table.

                                    (I mention size because for some reason the 3.5 monk damage table for
                                    sizes other then medium doesn't quite follow the 3.5
                                    weapon-damage-change-by-size table.)

                                    -- Jim
                                  • Keith Davies
                                    ... I was doing something like this using an order attribute in rating but I think you may be right that a Progression may be a better choice. hrm. If we re
                                    Message 17 of 20 , Jan 22, 2004
                                    • 0 Attachment
                                      On Thu, Jan 22, 2004 at 12:15:50PM -0500, CC Noram Carstensen James wrote:
                                      > Steve wrote:
                                      > > Yup. So shorthands may not always be possible (though I think a clean
                                      > solution to part of this problem would be like what I did with size:
                                      > associate integer values with the different size categories, and just
                                      > treat increasing size category as increasing the variable in an
                                      > sjb:Score/kjd:Progression.)

                                      I was doing something like this using an 'order' attribute in rating but
                                      I think you may be right that a Progression may be a better choice.

                                      hrm. If we're using Progression for things that *aren't* being applied
                                      in layers (the functionality is quite similar) I think that you may be
                                      right that 'Progression' isn't a great name for the generic form. OTOH,
                                      I think that 'Score' isn't such a great name either... we may want to
                                      think of a different term altogether.

                                      > Could you have multi-dimensional kjd:Progressions? Frugal mentioned
                                      > monk unarmed damage. To put this into array-speak, could you have a
                                      > progression Unarmed[Level,Size] such that you can represent all of the
                                      > different combinations, and also have easy ways of doing things like
                                      > representing the enlarged (+1 size) monk who is wearing a Monk's Belt
                                      > (bonus to monk level) because it just changes the lookup on the table.

                                      I hadn't considered it, but it does make some sense. Actually, 'Array'
                                      might not be a bad name for a collection of related/linked effects.

                                      > (I mention size because for some reason the 3.5 monk damage table for
                                      > sizes other then medium doesn't quite follow the 3.5
                                      > weapon-damage-change-by-size table.)

                                      of course not, that would make sense.


                                      Keith
                                      --
                                      Keith Davies I gave my 2yo daughter a strawberry
                                      keith.davies@... Naomi: "Strawberry!"
                                      me: "What do you say?"
                                      Naomi: "*MY* strawberry!"
                                    • Frugal
                                      ... Can you then either change the Array you are dealing with, or assign a new level to the array? For one of the feats in
                                      Message 18 of 20 , Jan 23, 2004
                                      • 0 Attachment
                                        <quote who="Keith Davies">
                                        > On Thu, Jan 22, 2004 at 12:15:50PM -0500, CC Noram Carstensen James wrote:
                                        >> Could you have multi-dimensional kjd:Progressions? Frugal mentioned
                                        >> monk unarmed damage. To put this into array-speak, could you have a
                                        >> progression Unarmed[Level,Size] such that you can represent all of the
                                        >> different combinations, and also have easy ways of doing things like
                                        >> representing the enlarged (+1 size) monk who is wearing a Monk's Belt
                                        >> (bonus to monk level) because it just changes the lookup on the table.
                                        >
                                        > I hadn't considered it, but it does make some sense. Actually, 'Array'
                                        > might not be a bad name for a collection of related/linked effects.

                                        Can you then either change the "Array" you are dealing with, or assign a
                                        new level to the array? For one of the feats in Oriental Adventures you
                                        can change the monks unarmed damage progression to something comlpetely
                                        different...

                                        --
                                        regards,
                                        Frugal
                                        -OS Chimp
                                      • Frugal
                                        ... Variable ? -- regards, Frugal -OS Chimp
                                        Message 19 of 20 , Jan 23, 2004
                                        • 0 Attachment
                                          <quote who="Keith Davies">
                                          > hrm. If we're using Progression for things that *aren't* being applied
                                          > in layers (the functionality is quite similar) I think that you may be
                                          > right that 'Progression' isn't a great name for the generic form. OTOH,
                                          > I think that 'Score' isn't such a great name either... we may want to
                                          > think of a different term altogether.

                                          "Variable" ?

                                          --
                                          regards,
                                          Frugal
                                          -OS Chimp
                                        • Frugal
                                          ... You would not register the Entity, but rather the effects of the Entity. ... The other problem is that any time you add a new
                                          Message 20 of 20 , Jan 23, 2004
                                          • 0 Attachment
                                            <quote who="Keith Davies">
                                            > Hrm. I'm familiar with Observer-Observable, but in this case doesn't it
                                            > lead to a huge number of links back and forth? Any Entity may have
                                            > observable properties, so wouldn't each Entity need to register?

                                            You would not register the Entity, but rather the effects of the Entity.

                                            >> The other solution to this (something similar to what Scott was
                                            >> suggesting, I think) is to associate with each Score a flag that says
                                            >> "I could be wrong!" and every time you need that Score, you first
                                            >> check it's "I could be wrong!" tag and the "I could be wrong!" tags of
                                            >> any Scores that it depends on. Note that even in this scheme, at some
                                            >> point, you'll have to go and check all the Scores that the Score you
                                            >> want to update is dependent on. (Or just check /all/ the other Scores
                                            >> if you don't want to maintain a dependency list. This makes me
                                            >> nervous though because it doesn't necessarily guarantee a reasonable
                                            >> order of Score updating.)

                                            The other problem is that any time you add a new Effect or Score/Variable
                                            to the character you have to invalidate everything. You can not just
                                            invalidate the things that the Effect invalidates, because you have no way
                                            of knowing what newly invalidated Score/Variable will invalidate.

                                            > . Observer would require that each thing that can change have an
                                            > observer attached; managing this would lead to massive resource
                                            > consumption.

                                            Does anyone know just how heavyweight the Observer pattern is in Java?
                                            From what I understand the only thing that the Observable object adds is a
                                            lookup table of Observers (i.e. A reference per Observer (4bytes on a
                                            32bit system)).

                                            > Now, if things are limited as to when they can change (either readonly
                                            > once loaded, or allowed to change only if in the file being edited [my
                                            > preference, since it allows for multiple edits at once], or readonly
                                            > unless 'edit mode' is entered) then the resources for Observer and
                                            > Scott's model both drop immensely.

                                            I am a bit confused by your reference to Data being Editable... Can you
                                            explain under what circumstances an Entity gets edited?

                                            The way I currently view what people are saying is that the Character is a
                                            set of Progression/Score/Variable (what ever they get called) and a set of
                                            references to Entities that can manipulate those P/S/Vs.

                                            As a Character is defined by its' P/S/Vs it will need to have its' own
                                            local copy of each P/S/V that applies to that Character. So character
                                            Alice will have a P/S/V with the ID 'score.stat'. Bob will also have the
                                            P/S/V with the id 'score.stat' but the two P/S/Vs are not the same Object.

                                            As Entities are applied to a Character the character will have a reference
                                            to each Entity, but will never be able to alter it. Alice can have the
                                            Entity "feat.toughness" applied to her, and Bob can have the Entity
                                            "feat.toughness" applied to him. The two Objects will be the same object.

                                            Or are people talking about a completely different layer to me?

                                            --
                                            regards,
                                            Frugal
                                            -OS Chimp
                                          Your message has been successfully submitted and would be delivered to recipients shortly.