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

Re: [pcgen-xml] It lives! And is reborn!

Expand Messages
  • Fred Drake
    ... I m surprised technically-literate people are having a hard time with this. I don t even think the sections are all that similar, though I d expect the
    Message 1 of 19 , Sep 29, 2005
    View Source
    • 0 Attachment
      On 9/29/05, Keith Davies <keith.davies@...> wrote:
      > These two sections have different purpose and application, despite being
      > somewhat similar.

      I'm surprised technically-literate people are having a hard time with
      this. I don't even think the sections are all that similar, though
      I'd expect the structure of the second would largely mirror and extend
      the structure of the first.

      > Also, and very important to me, it runs the risk of introducing
      > inconsistency. If the definition of an entity changes, the information
      > in the second section could be rendered incorrect.

      I actually disagree on this point, however. As the sections have been
      described so far, I think of them this way:

      1. User decisions.

      2. Software decisions.

      3. Fluffy stuff.

      The third section can clearly be regenerated, but supplemental tools
      that only care about the "current" value of the information only need
      to look there. This is nice to have, but could be dropped.

      That leaves the first two, where all the contention seems to be.
      Section 1 is obviously necessary, and seems well defined. Section 2
      *appears* derivative of section 1 + game rule information (race &
      class definitions, etc.), and usually will be. Where you're looking
      at inconsistency, I see an opportunity to check that the character is
      being viewed relative to the right "universe" (the game rule
      information set); it also allows you to separate changes in game rules
      from the characters created under different versions.

      For example, suppose I create a character and play her until level 5.
      The GM decides he doesn't like some rule, so forks the universe by
      reducing the number of spells my character would have received at
      level 3. Whether my character loses a spell or not, since she's
      already in play, depends on the GM's policy for handling that. As
      described, section 2 allows that decision to be handled either way.
      The application that checks for this sort of inconsistency should
      allow the policy to be applied on a case-by-case basis by inserting
      "inconsistency approvals" into the second section for each
      inconsistency. This would allow a character from a legacy universe to
      continue to be used in the new universe in the same way that happens
      in real games.

      > I don't mind being *wrong*, but I had being inconsistent.

      Absolutely understandable!

      > It's probably a matter of preference. The first section as I've
      > described it is *necessary*. The second section isn't, but is useful.
      > I don't like mixing optional data and required data in the same
      > containers, especially when it isn't evident through examination which
      > is which.

      Understandable, but I think the information is necessary.

      > Also, frankly, the first section as described is pretty easy to
      > implement. The second will be harder and probably more error-prone.
      > There's a certain amount of overlap between them and probably code
      > reuse, but we can prove the first section fairly easily. The second
      > will be more work.

      Most definately. They also serve clearly different purposes.

      > 2. examination difficulty. This is a much more important one, IMO. If
      > you show the entire state, that means the whole thing needs to be
      > examined if you're trying to figure out what happened. If you only
      > highlight what changed (including the new (and possibly old) values)
      > then it's very easy to see the effects of the change.

      This is very valuable. Anything that makes development easier is a good thing.


      -Fred

      --
      Fred L. Drake, Jr. <fdrake at gmail.com>
      Zope Corporation
    • Keith Davies
      ... The structure probably would be very close to the first, just with more information. ... ... I didn t write that, but that summarizes what I was trying to
      Message 2 of 19 , Sep 29, 2005
      View Source
      • 0 Attachment
        On Thu, Sep 29, 2005 at 09:11:43PM -0400, Fred Drake wrote:
        > On 9/29/05, Keith Davies <keith.davies@...> wrote:
        > > These two sections have different purpose and application, despite being
        > > somewhat similar.
        >
        > I'm surprised technically-literate people are having a hard time with
        > this. I don't even think the sections are all that similar, though
        > I'd expect the structure of the second would largely mirror and extend
        > the structure of the first.

        The structure probably would be very close to the first, just with more
        information.

        > > Also, and very important to me, it runs the risk of introducing
        > > inconsistency. If the definition of an entity changes, the information
        > > in the second section could be rendered incorrect.
        >
        > I actually disagree on this point, however. As the sections have been
        > described so far, I think of them this way:
        >
        > 1. User decisions.
        >
        > 2. Software decisions.
        >
        > 3. Fluffy stuff.

        ... I didn't write that, but that summarizes what I was trying to say
        very well.

        > The third section can clearly be regenerated, but supplemental tools
        > that only care about the "current" value of the information only need
        > to look there. This is nice to have, but could be dropped.

        I agree. The second should provide sufficient information to regenerate
        the third section for the character at *any* point in the series of
        transformations.

        > That leaves the first two, where all the contention seems to be.
        > Section 1 is obviously necessary, and seems well defined. Section 2
        > *appears* derivative of section 1 + game rule information (race &
        > class definitions, etc.), and usually will be. Where you're looking
        > at inconsistency, I see an opportunity to check that the character is
        > being viewed relative to the right "universe" (the game rule
        > information set); it also allows you to separate changes in game rules
        > from the characters created under different versions.

        I agree that it could be used for sanity checks -- does this version
        match what the software thought before?

        That kind of falls down, though, in that if they differ between
        versions, they *should* differ (code or data patch, most likely). I
        wouldn't want to try to implement an automated check for this. Until we
        decide to do something with a discovery of a mismatch, I wouldn't worry
        about.

        > For example, suppose I create a character and play her until level 5.
        > The GM decides he doesn't like some rule, so forks the universe by
        > reducing the number of spells my character would have received at
        > level 3. Whether my character loses a spell or not, since she's
        > already in play, depends on the GM's policy for handling that. As
        > described, section 2 allows that decision to be handled either way.

        Or at least automatically discover it.

        > The application that checks for this sort of inconsistency should
        > allow the policy to be applied on a case-by-case basis by inserting
        > "inconsistency approvals" into the second section for each
        > inconsistency. This would allow a character from a legacy universe to
        > continue to be used in the new universe in the same way that happens
        > in real games.

        That's getting into the question of branching data and having multiple
        versions extant -- to the point of "this is how it is for *me*".

        I don't want to go here right now. It's an interesting idea, and
        potentially quite valuable, but I'd like to keep it simple for now.
        We're already going somewhere the program doesn't yet, let's not go too
        far.

        > > I don't mind being *wrong*, but I had being inconsistent.
        >
        > Absolutely understandable!

        Heh, I learned that working for government. You can make a mistake
        without it being *too* embarassing, but an inconsistency indicates you
        didn't even *check*... and that's *very* embarassing.

        > > It's probably a matter of preference. The first section as I've
        > > described it is *necessary*. The second section isn't, but is
        > > useful. I don't like mixing optional data and required data in the
        > > same containers, especially when it isn't evident through
        > > examination which is which.
        >
        > Understandable, but I think the information is necessary.

        I think the second section would be terribly useful -- not necessary,
        but from a pragmatic sense a damn good idea.

        What I want to avoid is "here's a bunch of stuff, some of which you need
        and some you don't, and it's up to the reader [program] to know which is
        which". This is much more complex than "here's what you need to know,
        and you need to know all of it". Simpler rules almost invariably lead
        to simpler software.

        > > Also, frankly, the first section as described is pretty easy to
        > > implement. The second will be harder and probably more error-prone.
        > > There's a certain amount of overlap between them and probably code
        > > reuse, but we can prove the first section fairly easily. The second
        > > will be more work.
        >
        > Most definately. They also serve clearly different purposes.

        Yes. Even though the first one could be derived from the second, being
        a subset of it.

        > > 2. examination difficulty. This is a much more important one, IMO. If
        > > you show the entire state, that means the whole thing needs to be
        > > examined if you're trying to figure out what happened. If you only
        > > highlight what changed (including the new (and possibly old) values)
        > > then it's very easy to see the effects of the change.
        >
        > This is very valuable. Anything that makes development easier is a
        > good thing.

        Such is my thought.


        Keith
        --
        Keith Davies "Always code as if the guy who ends up
        keith.davies@... maintaining your code is a psychopath
        keith.davies@... who knows where you live."
        http://www.kjdavies.org/ -- Damian Conway
      • Fred Drake
        ... Exactly how an application should respond to such a mismatch should not be defined by the data model. It s likely fine to start by expecting the model of
        Message 3 of 19 , Sep 29, 2005
        View Source
        • 0 Attachment
          On 9/29/05, Keith Davies <keith.davies@...> wrote:
          > I agree that it could be used for sanity checks -- does this version
          > match what the software thought before?
          >
          > That kind of falls down, though, in that if they differ between
          > versions, they *should* differ (code or data patch, most likely). I
          > wouldn't want to try to implement an automated check for this. Until we
          > decide to do something with a discovery of a mismatch, I wouldn't worry
          > about.

          Exactly how an application should respond to such a mismatch should
          not be defined by the data model. It's likely fine to start by
          expecting the model of the universe to match the fragments of the
          universe model exposed in the character data (section 2).

          I think it important to keep separate the (abstract) data model and
          the application requirements. If you don't require sharing data with
          an application that may have a different universe model, there's no
          need to ever perform the checks of even store section 2 (other than
          for debugging). However, the model should certainly *allow* an
          application that cares about interchage or a universe in flux can make
          the additional use of the information from section 2 to support
          whatever operations it cares about. (For some reason, this makes me
          think back to Jack Chalker's Flux & Anchor books; not really sure
          why...)

          > That's getting into the question of branching data and having multiple
          > versions extant -- to the point of "this is how it is for *me*".
          >
          > I don't want to go here right now. It's an interesting idea, and
          > potentially quite valuable, but I'd like to keep it simple for now.
          > We're already going somewhere the program doesn't yet, let's not go too
          > far.

          Again, we need to keep distinct the model and the application. PCgen
          is one application; perhaps it doesn't need all the bells and
          whistles. I work on web-based content-management applications with
          highly inter-related content objects, and the rules for checking and
          enforcing relationships always belong in the software. The data model
          needs to provide enough information for checks and future application
          evolution; keeping these sorts of aspects separated is amazingly
          important. (I also imagine any software I write that consumes more
          than section 3 of this format would be very interested in detecting
          changes in the universe after the fact rather than having to dig
          through characters every time something in the universe changed.)

          > What I want to avoid is "here's a bunch of stuff, some of which you need
          > and some you don't, and it's up to the reader [program] to know which is
          > which". This is much more complex than "here's what you need to know,
          > and you need to know all of it". Simpler rules almost invariably lead
          > to simpler software.
          ...
          > > Most definately. They also serve clearly different purposes.
          >
          > Yes. Even though the first one could be derived from the second, being
          > a subset of it.

          Certainly. It could even be stored as a single piece, but the data
          model should certainly distinguish the two aspects. Section 2 could
          be viewed as a set of annotations on section 1. Keeping them separate
          could make it easier for a human to consume the storage file directly
          (in a text editor, for instance). Keeping them together could make it
          easier for a human to modify the stored data in a text editor.

          So I'll go so far as to suggest that applications should write out
          both sections 1 & 2, and that humans armed with text editors remove
          section 1 if they modify section 2, and let applications regenerate
          that as needed.

          Hmm. Should the sections have better names yet? I could see
          something like Decision, Transformation, and Sheet sections. (Where
          Sheet sections can occur zero or more times, and each has a reference
          to the point in the Decision or Transformation section that it
          corresponds to.


          -Fred

          --
          Fred L. Drake, Jr. <fdrake at gmail.com>
          Zope Corporation
        • andargor
          ... I would strongly suggest that the character should be saved in a format based on a de facto XML standard for the sake of not reinventing the wheel, and
          Message 4 of 19 , Sep 30, 2005
          View Source
          • 0 Attachment
            --- In pcgen-xml@yahoogroups.com, Keith Davies <keith.davies@k...> wrote:
            > Hi All,
            >
            > I just finished an interesting IM conversation with Devon. Here's what
            > he's looking for -- and it's pretty easy, I think.
            >
            > Continue using LST format for PCC files, for now at least. We may
            > revisit it later and convert the LST files to XML.
            >
            > The character file would consist of three sections. Each section is
            > optional, but there are reasons for each.
            >

            I would strongly suggest that the character should be saved in a
            format based on a "de facto" XML standard for the sake of not
            reinventing the wheel, and interoperability. I have been citing
            OpenRPG for some time. (get it here:
            http://sourceforge.net/project/showfiles.php?group_id=2237&package_id=2193&release_id=201695))

            Look in the OpenRPG\orpg\templates\nodes\d20character.xml file for the
            format they use.

            It could be another format, such as Twin Roses' or DMGenie, it doesn't
            really matter, as long as tools out there can support the format.

            I realize that PCGen might need "internal representations" or
            additional info within the character just for PCGen. This is where the
            power of XML comes in: you just add a <pcgen version="x.x"> section
            and include whatever extra "mechanics" are needed by PCGen. The other
            tools that support OpenRPG will simply ignore it, and use the common
            OpenRPG data to import.

            Please let us be truly open, and allow PCGen to finally be able to
            work with other tools.

            As for data sets, that's an entirely different discussion, but we'll
            get to that eventually. I suggest you look at Frugal's stuff in this
            list. He is in the process of revamping his XML based character
            generator, and some ideas could be reused or expanded upon for the
            future of PCGen.

            Needless to say that I'm excited about this... :)

            Andargor
          • Edwin Holley
            ... From: pcgen-xml@yahoogroups.com [mailto:pcgen-xml@yahoogroups.com] On Behalf Of andargor Sent: Friday, September 30, 2005 10:17 To:
            Message 5 of 19 , Sep 30, 2005
            View Source
            • 0 Attachment
              -----Original Message-----
              From: pcgen-xml@yahoogroups.com [mailto:pcgen-xml@yahoogroups.com] On Behalf
              Of andargor
              Sent: Friday, September 30, 2005 10:17
              To: pcgen-xml@yahoogroups.com
              Subject: [pcgen-xml] Re: It lives! And is reborn! [Using defacto standards]

              >SNIP< I should look at this stuff :-)

              I would strongly suggest that the character should be saved in a
              format based on a "de facto" XML standard for the sake of not
              reinventing the wheel, and interoperability. I have been citing
              OpenRPG for some time. (get it here:
              http://sourceforge.net/project/showfiles.php?group_id=2237&package_id=2193&r
              elease_id=201695))

              >SNIP< I don't know that being open means that your software works with
              other programs. This program is very unique; it has capabilities far beyond
              any commercial program. I have compared any programs I could for evaluation
              and found them severely lacking in even half the features\capabilities that
              pcgen has. Even excluding some of the decent XML files. The available
              programs do not have the capability to incorporate the games or character
              classes that pcgen is currently includes or being used by various members.
              Including creating new worlds like ice planets. The capabilities that we
              wish to include in the data will require a level of sophistication far
              beyond anything else I have seen. Also by creating an output sheet, you are
              able to create your character in just about any format you can imagine.

              Please let us be truly open, and allow PCGen to finally be able to
              work with other tools.

              >SNIP< I agree

              Needless to say that I'm excited about this... :)

              Andargor






              Yahoo! Groups Links
            • Devon Jones
              ... In fact, in our discussions, section 2 will be the last to be implemented, as there are potentially major code hurtles. Section 2 is a debugging to IMHO,
              Message 6 of 19 , Oct 3, 2005
              View Source
              • 0 Attachment
                Keith Davies wrote:

                >It's probably a matter of preference. The first section as I've
                >described it is *necessary*. The second section isn't, but is useful.
                >I don't like mixing optional data and required data in the same
                >containers, especially when it isn't evident through examination which
                >is which.
                >
                >Also, frankly, the first section as described is pretty easy to
                >implement. The second will be harder and probably more error-prone.
                >There's a certain amount of overlap between them and probably code
                >reuse, but we can prove the first section fairly easily. The second
                >will be more work.
                >
                >
                In fact, in our discussions, section 2 will be the last to be
                implemented, as there are potentially major code hurtles. Section 2 is
                a debugging to IMHO, intended as a log so that we can more easily detect
                errors. I don't see a real use for section 2 outside pcgen developers.

                >I see no reason why you couldn't generate the third section "as at" a
                >particular transformation (right after 4th level, say), despite having
                >10 levels of information present. In fact, you could generate *just*
                >the third section, without including either of the others.
                >
                >
                Indeed, we essentially do now, the third section is for most intents and
                purposes already implemented - it's called base.xml. My goal here is to
                be able to drive exports completely from the new pcg format, as well as
                allow other programs to transform section 3 into usable input for their
                program.

                Here is how I see the sections:
                Section 1: this is designed to tell pcgen how to build a character.
                This is meant purely for internal pcgen consumption. Using this and
                cdom, there is no reason that we can't show a character at multiple
                points in their development. This section will be absolutely necessary
                if I want CDOM to happen.

                Section 2: This is a log, and as such is mostly useful as a debugging
                tool. This section in the hardest one to implement (for internal pcgen
                reasons I don't want to go into right now). This section contains a log
                of decisions and their consequences. It's really mostly useful for
                debugging.

                Section 3: This is for export, as well as import. This section allows
                us to show a complete character, sans lst data, and sans decisions. It
                can be used for exports, it can be use to generate character sheets, and
                it can be used to build an object structure in pcgen such that we can
                import read only characters from other programs.

                Devon
              • Devon Jones
                ... Ok, my position on this is that we probably shouldn t. By being xml, we are being open, and we can certainly build xslt to transform to other formats, but
                Message 7 of 19 , Oct 3, 2005
                View Source
                • 0 Attachment
                  andargor wrote:

                  >I would strongly suggest that the character should be saved in a
                  >format based on a "de facto" XML standard for the sake of not
                  >reinventing the wheel, and interoperability. I have been citing
                  >OpenRPG for some time. (get it here:
                  >http://sourceforge.net/project/showfiles.php?group_id=2237&package_id=2193&release_id=201695))
                  >
                  >Look in the OpenRPG\orpg\templates\nodes\d20character.xml file for the
                  >format they use.
                  >
                  >It could be another format, such as Twin Roses' or DMGenie, it doesn't
                  >really matter, as long as tools out there can support the format.
                  >
                  >I realize that PCGen might need "internal representations" or
                  >additional info within the character just for PCGen. This is where the
                  >power of XML comes in: you just add a <pcgen version="x.x"> section
                  >and include whatever extra "mechanics" are needed by PCGen. The other
                  >tools that support OpenRPG will simply ignore it, and use the common
                  >OpenRPG data to import.
                  >
                  >Please let us be truly open, and allow PCGen to finally be able to
                  >work with other tools.
                  >
                  >As for data sets, that's an entirely different discussion, but we'll
                  >get to that eventually. I suggest you look at Frugal's stuff in this
                  >list. He is in the process of revamping his XML based character
                  >generator, and some ideas could be reused or expanded upon for the
                  >future of PCGen.
                  >
                  >Needless to say that I'm excited about this... :)
                  >
                  >Andargor
                  >
                  >
                  >
                  Ok, my position on this is that we probably shouldn't. By being xml, we
                  are being open, and we can certainly build xslt to transform to other
                  formats, but we need more and different information then these programs do.

                  Section 1 is absolutely necessary. period.
                  Section 2 is not
                  Section 3 is IMHO utterly necessary, as I intend to drive our Sheet
                  exports off of it, and it makes a perfect interchange format, as it will
                  literally contain *all* the final data about a character, with zero
                  information that is driving the pcgen program.

                  Having looked at OpenRPG's format, their format is purely an internal
                  program representation, and (IMHO) not useful for really anything else -
                  it depends on things that are basically internal needs of their
                  program. What I intend with section 3 is essentially a representation
                  of a character that is utterly complete, and would result in the
                  capability of transforming into really any other data format that uses
                  xml. Furthur, if we *find* something that it can't be transformed to, I
                  would see us as adding to out format to make it capable of that kind of
                  transformation.

                  Finally, with this kind of transformation capability, we could finally
                  add the ability to save characters in these other formats, much like you
                  can save as rtf in word. The problem here is that these other programs
                  (OpenRPG, DMGenie and Twin Rose) were not designed as interchange
                  formats, and were designed with their programs in mind. I want to break
                  this model, and design a format that can function as a full interchange
                  format (section 3), and have sections designed in this format for other
                  usage (section 1 and 2). That being said, I would seriously consider a
                  section 4: external Apps. An optional section (since all the sections
                  are optional) that can contain the character, already transformed for
                  OpenRPG, DMGenie, Twin Rose, etc.

                  This is getting somewhat stream of consciousness now, but I could see us
                  developing one top level format that is intended to embed any number of
                  other formats, and then consider sections 1-3, and any other formats to
                  each be their own xml format, that is embeddable in the upper level
                  pcgen xml document.

                  Devon
                • Brass Tilde
                  ... Ah hah! Now I get it. If this was explained earlier, I apologize for not understanding. Put this way, it makes excellent sense, though I might prefer it
                  Message 8 of 19 , Oct 3, 2005
                  View Source
                  • 0 Attachment
                    > Section 1: this is designed to tell pcgen how to build a character.
                    >
                    > Section 2: This is a log, and as such is mostly useful as a debugging
                    > tool.

                    > Section 3: This is for export, as well as import. This section allows
                    > us to show a complete character, sans lst data, and sans decisions.

                    Ah hah! Now I get it. If this was explained earlier, I apologize for
                    not understanding. Put this way, it makes excellent sense, though I
                    might prefer it if the presence of the second section were a
                    configuration option. I don't feel very strongly about that, though.

                    In your design, I'm assuming that it would be possible to generate a
                    "section 3" from any set of levels in section 1, e.g. if I have 10
                    levels, but I want a sheet that shows what the character looked like at
                    level 9.

                    Good stuff. I wish I had more time to help with it.
                  • Brass Tilde
                    ... the ... we ... programs do. Honestly, I don t think you two are that far apart on this. andargor s element is Devon s section 1 .
                    Message 9 of 19 , Oct 3, 2005
                    View Source
                    • 0 Attachment
                      > > andargor wrote:
                      >
                      > >I realize that PCGen might need "internal representations" or
                      > >additional info within the character just for PCGen. This is where
                      the
                      > >power of XML comes in: you just add a <pcgen version="x.x"> section
                      > >and include whatever extra "mechanics" are needed by PCGen.

                      > From: "Devon Jones" <soulcatcher@...>

                      > Ok, my position on this is that we probably shouldn't. By being xml,
                      we
                      > are being open, and we can certainly build xslt to transform to other
                      > formats, but we need more and different information then these
                      programs do.

                      Honestly, I don't think you two are that far apart on this. andargor's
                      <pcgen version="x.x" /> element is Devon's "section 1".

                      > > andargor again.

                      > >Please let us be truly open, and allow PCGen to finally be able to
                      > >work with other tools.

                      This would be Devon's "section 3". The end product of all the
                      calculations and other stuff that PCGen does, in a format that can be
                      transformed to virtually anything anybody else needs. If a piece of
                      info isn't there, it can be added (as long as PCGen processes that
                      information).

                      Publishing the schema to section 3 enables other programs, should they
                      wish to do so, to publish transforms that can be used to use that data
                      in whatever way they want.

                      Brad
                    • Devon Jones
                      ... Section 2 will take a long time, and may never be fully realized. Section 2 may not appear it, but it s *hard* ... Precisely, we can even contain if we
                      Message 10 of 19 , Oct 3, 2005
                      View Source
                      • 0 Attachment
                        Brass Tilde wrote:

                        >
                        >Ah hah! Now I get it. If this was explained earlier, I apologize for
                        >not understanding. Put this way, it makes excellent sense, though I
                        >might prefer it if the presence of the second section were a
                        >configuration option. I don't feel very strongly about that, though.
                        >
                        >
                        Section 2 will take a long time, and may never be fully realized.
                        Section 2 may not appear it, but it's *hard*

                        >In your design, I'm assuming that it would be possible to generate a
                        >"section 3" from any set of levels in section 1, e.g. if I have 10
                        >levels, but I want a sheet that shows what the character looked like at
                        >level 9.
                        >
                        >
                        Precisely, we can even contain if we wish, more then one section 3, and
                        if we can get the code fast enough, that may end up defaulting to that
                        for each level. If not, it'll be optional.

                        >Good stuff. I wish I had more time to help with it.
                        >
                        >
                        >
                      • Brass Tilde
                        ... I ll reiterate someone else s point here though, that some things are *not* necessarily level dependent, such as one s possessions. It *is* true that most
                        Message 11 of 19 , Oct 3, 2005
                        View Source
                        • 0 Attachment
                          > > In your design, I'm assuming that it would be possible to generate a
                          > > "section 3" from any set of levels in section 1, e.g. if I have 10
                          > > levels, but I want a sheet that shows what the character
                          > > looked like at level 9.

                          > Precisely, we can even contain if we wish, more then one
                          > section 3, and if we can get the code fast enough, that
                          > may end up defaulting to that for each level. If not,
                          > it'll be optional.

                          I'll reiterate someone else's point here though, that some things are
                          *not* necessarily level dependent, such as one's possessions. It *is*
                          true that most people gather those things over the course of their
                          careers, so a strict "point in time" snap-shot section 3 would show
                          different equipment for each level.

                          However, in the case of losing one or more levels, the equipment would
                          need to be retained, and displayed for the new lower level. Not a
                          showstopper by any means, and not terribly difficult to implement I
                          imagine (I can think of at least one way to do it right now). The whole
                          thing implies a sequence to the character, even if part of that sequence
                          is going backwards!

                          Again, good stuff. Keep up the good work.

                          Brad
                        • Fred Drake
                          ... They were right, of course. Sections 1 and 2 are strictly level-based information; possessions or other point-in-time information ( broken arm ) is
                          Message 12 of 19 , Oct 3, 2005
                          View Source
                          • 0 Attachment
                            On 10/3/05, Brass Tilde <brasstilde@...> wrote:
                            > I'll reiterate someone else's point here though, that some things are
                            > *not* necessarily level dependent, such as one's possessions. It *is*
                            > true that most people gather those things over the course of their
                            > careers, so a strict "point in time" snap-shot section 3 would show
                            > different equipment for each level.

                            They were right, of course. Sections 1 and 2 are strictly level-based
                            information; possessions or other point-in-time information ("broken
                            arm") is separate. I don't know if this really belongs in section 3
                            or not, but seems parallel. Points in time also don't generally
                            correspond to level transitions. (If you require training in-game to
                            learn/advance skills, then levelling up earns skill points, and the
                            decisions on spending them happen outside the levelling process.)

                            I suspect that full point-in-time rollback should reasonably be
                            considered out-of-scope for the data format. This sort of
                            functionality is easily enough implemented using copies of the data
                            files, either directly on the filesystem or using an external revision
                            control system.

                            Which is not to say that it's a bad idea to included other timestamped
                            information: "Noon, 12 Octember 2345, -1 STR damage (permanent) from
                            cursed ray gun." But that's game time; real-world time should still
                            be handled externally. There's a lot of messy interactions between
                            game time and real-world time, and more tricks to pull if the game
                            world isn't on the Gregorian calendar.


                            -Fred

                            --
                            Fred L. Drake, Jr. <fdrake at gmail.com>
                            "Society attacks early, when the individual is helpless." --B.F. Skinner
                          Your message has been successfully submitted and would be delivered to recipients shortly.