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

Expand Messages
  • Frugal
    After andargor posted his sample Javascript based engine, I thought I would post yet another attempt at a Generic D20 engine that I have been playing with. It
    Message 1 of 28 , Jun 24, 2004
    • 0 Attachment
      After andargor posted his sample Javascript based engine, I thought I
      would post yet another attempt at a Generic D20 engine that I have been
      playing with.

      It is based on the files and schema in the playing.xml file that was
      posted to the group a while ago. This is a very rough implementation of a
      Java engine to handle that XML format.

      It all works (sort of). You can add entities and ranks to a character
      (which in turn in an Entity).

      One of the nice things is that you can get a different result for a
      variable depending on what you ask and who is doing the asking. i.e. if
      you ask the character what is the value of "var.combat.tohit" you will get
      the melee attack bonus. If you ask a dagger in the posession of the
      character the same question you might get a different answer depending on
      whether the character is proficient with the dagger, or if the dagger
      gives any toHit bonuses.

      The nice thing about this system is that it cuts down the number of
      variables you need, objects can modify variables just for them selves, and
      once an object has been asked for a variable, if the variable ever changes
      as far as the entity is concerned the entity will notify any observers
      about it.

      http://groups.yahoo.com/group/pcgen-xml/files/playing.zip

      You should be able to build it from the ant build script, and then run it
      will "java -jar build/playing.jar".

      This program will not work as a fully featured generic engine as it can
      not cope with certain key items: There is no way to say "give me the value
      of this variable at character level 'X'" which is needed for Epic. Nor is
      there any way of saying "when you add a rank of this progression,
      internally add a rank of these 2 progressions and return the highest value
      from each for any variable asked" which is needed for Gestalt characters.

      The choosers will just return the first item in the list rather than
      asking the user for input, and none of the python scripting works.

      --
      regards,
      Frugal
      -OS Chimp
    • Frugal
      ... I forgot to mention: To get it to dump all of the variables, ranks and properties of the character uncomment the three lines that look
      Message 2 of 28 , Jun 24, 2004
      • 0 Attachment
        <quote who="Frugal">

        > http://groups.yahoo.com/group/pcgen-xml/files/playing.zip
        >
        > You should be able to build it from the ant build script, and then run it
        > will "java -jar build/playing.jar".

        I forgot to mention: To get it to dump all of the variables, ranks and
        properties of the character uncomment the three lines that look like this:

        character.dumpVariableValues();
        character.dumpEntities();
        character.dumpProperties();

        in Character.java line 66

        --
        regards,
        Frugal
        -OS Chimp
      • andargor
        ... value ... Nor is ... value ... characters. ... It looks real good. I like the entity/object abstraction from the game system, and the granularity at the
        Message 3 of 28 , Jun 24, 2004
        • 0 Attachment
          --- In pcgen-xml@yahoogroups.com, "Frugal" <frugal@p...> wrote:
          >

          > This program will not work as a fully featured generic engine as it can
          > not cope with certain key items: There is no way to say "give me the
          value
          > of this variable at character level 'X'" which is needed for Epic.
          Nor is
          > there any way of saying "when you add a rank of this progression,
          > internally add a rank of these 2 progressions and return the highest
          value
          > from each for any variable asked" which is needed for Gestalt
          characters.
          >
          > The choosers will just return the first item in the list rather than
          > asking the user for input, and none of the python scripting works.
          >
          > --
          > regards,
          > Frugal
          > -OS Chimp

          It looks real good. I like the entity/object abstraction from the game
          system, and the granularity at the variable level.

          I think the problem with what you mention, getting a certain variable
          for a certain level, is tied to the use of formulas based on a
          progression. For example, "0.75 * class level" for BAB. I would just
          add an entity at the appropriate level ("rank") that increases BAB by
          one. The same would go for hit dice for races as classes progression:
          some levels do not grant anything. I'm also thinking Bloodline levels
          from UA having the same issue.

          For Epic bonuses and gestalt, if you have discrete entities for BAB,
          hit dice, etc., then all you need is a mediator object/entity
          (something like "OnAdd" for each entity type) which does the
          appropriate operation, e.g. "is the ECL (CL+HD+LA) > 20? then
          override the class' BAB entity and add an Epic bonus", or "is the BAB
          increase for this level greater for Class A than Class B? then add
          Class A's BAB entity"

          Overall, good work. Your XML is more concise than mine :)

          Andargor
        • Frugal
          ... I have a certain set of requirements for a truely generic system. These include (but are not limited to): - Support Core 3.0
          Message 4 of 28 , Jun 25, 2004
          • 0 Attachment
            <quote who="andargor">
            > I think the problem with what you mention, getting a certain variable
            > for a certain level, is tied to the use of formulas based on a
            > progression. For example, "0.75 * class level" for BAB. I would just
            > add an entity at the appropriate level ("rank") that increases BAB by
            > one. The same would go for hit dice for races as classes progression:
            > some levels do not grant anything. I'm also thinking Bloodline levels
            > from UA having the same issue.

            I have a certain set of requirements for a truely generic system. These
            include (but are not limited to):

            - Support Core 3.0 characters
            - Support Core 3.5 characters
            - Support Epic Characters
            - Support Exclusive Skills (i.e. the complicated calculations
            for maxRanks)
            - Support Gestalt Characters (in many forms: Take highest of 2+ values;
            take sum of 2+ values; take mean of 2+ values);
            - Support Adding a race and class level at the same time (i.e. in our
            campaign the DM has decided that the player with the Astral Deva
            character gets a different XP progression, but goes up a level of
            Deva and a level of cleric at the same time).
            - Support floating point variables (i.e. Monk/Rogue BAB of 3.75/3.75
            would give a BAB of floor(3.75+3.75)=7 rather than
            floor(3.75)+floor(3.75)=6 )


            I think that if I change the way the progressions are assigned then it
            should be possible to get the value for any variable at a specific level.

            Instead of the current way:

            character
            progression:Elf
            rank:Elf[1]
            rank:Elf[2]
            rank:Elf[3]
            rank:Elf[4]
            progression:Character Level
            rank:Character Level[1]
            rank:Character Level[2]
            rank:Character Level[3]
            rank:Character Level[4]
            progression:Fighter
            rank:Fighter[1]
            progression:Monk
            rank:Monk[1]
            rank:Monk[2]
            rank:Monk[3]

            We have this:

            character
            Progression:Character Level
            Rank:Character Level[1]
            rank:Elf[1]
            Rank:Fighter[1]
            Rank:Character Level[2]
            rank:Elf[2]
            Rank:Monk[1]
            Rank:Character Level[3]
            rank:Elf[3]
            Rank:Monk[2]
            Rank:Character Level[4]
            rank:Elf[4]
            Rank:Monk[3]

            Then it will make asking "character level[3]" for a value a lot easier.
            Not Trivuial, but easier.

            > For Epic bonuses and gestalt, if you have discrete entities for BAB,
            > hit dice, etc., then all you need is a mediator object/entity
            > (something like "OnAdd" for each entity type) which does the
            > appropriate operation, e.g. "is the ECL (CL+HD+LA) > 20? then
            > override the class' BAB entity and add an Epic bonus", or "is the BAB
            > increase for this level greater for Class A than Class B? then add
            > Class A's BAB entity"

            Hmmmm. I will have to look into how to apply that sort of thing to this
            style of program.

            > Overall, good work. Your XML is more concise than mine :)

            I started from the XML and I am now trying to write an application around
            it. I think I should have started with the requirements and built the data
            model around that, then built the XML model from the data model.

            I think it might actually be time to do this properly and write up a set
            of requirements and some use cases ;O)

            --
            regards,
            Frugal
            -OS Chimp
          • Frugal
            ... I have added an extention to the variables in formulas. You can now have @ to give you the value of a variable at a
            Message 5 of 28 , Jun 29, 2004
            • 0 Attachment
              <quote who="andargor">

              > I think the problem with what you mention, getting a certain variable
              > for a certain level, is tied to the use of formulas based on a
              > progression. For example, "0.75 * class level" for BAB. I would just
              > add an entity at the appropriate level ("rank") that increases BAB by
              > one. The same would go for hit dice for races as classes progression:
              > some levels do not grant anything. I'm also thinking Bloodline levels
              > from UA having the same issue.

              I have added an extention to the variables in formulas. You can now have
              <name>@<level> to give you the value of a variable at a certain level.
              Then you can do certain things like:

              <variable-bonus targetid="var.bab.nonepic"
              value="var.bab@20"/>
              <variable-bonus targetid="combat.toHit"
              value="var.bab.nonepic"
              kind="bab"/>
              <variable-bonus targetid="combat.toHit"
              value="max(0, ($ranks.character-19) / 2)"
              kind="epic"/>

              I have uploaded the new tarball to:
              http://groups.yahoo.com/group/pcgen-xml/files/playing.tgz


              I did a quick check and on my machine (2G Pentum with 768M of memory)
              running a loop of creating a 27th level Monk 50 times (dumping all output
              to /dev/null) gives the following timings:

              Client JVM: 100 seconds (2 seconds per iteration)
              Server JVM: 85 Seconds (1.75 seconds per iteration).

              --
              regards,
              Frugal
              -OS Chimp
            • andargor
              ... have ... level. ... memory) ... output ... I ll be out of town for a few days. I ll check it out when I get back. I admit I am uncomfortable with an @
              Message 6 of 28 , Jun 29, 2004
              • 0 Attachment
                --- In pcgen-xml@yahoogroups.com, "Frugal" <frugal@p...> wrote:
                > I have added an extention to the variables in formulas. You can now
                have
                > <name>@<level> to give you the value of a variable at a certain
                level.
                > Then you can do certain things like:
                >
                > <variable-bonus targetid="var.bab.nonepic"
                > value="var.bab@20"/>
                > <variable-bonus targetid="combat.toHit"
                > value="var.bab.nonepic"
                > kind="bab"/>
                > <variable-bonus targetid="combat.toHit"
                > value="max(0, ($ranks.character-19) / 2)"
                > kind="epic"/>
                >
                > I have uploaded the new tarball to:
                > http://groups.yahoo.com/group/pcgen-xml/files/playing.tgz
                >
                >
                > I did a quick check and on my machine (2G Pentum with 768M of
                memory)
                > running a loop of creating a 27th level Monk 50 times (dumping all
                output
                > to /dev/null) gives the following timings:
                >
                > Client JVM: 100 seconds (2 seconds per iteration)
                > Server JVM: 85 Seconds (1.75 seconds per iteration).
                >
                > --
                > regards,
                > Frugal
                > -OS Chimp

                I'll be out of town for a few days. I'll check it out when I get back.

                I admit I am uncomfortable with an "@" sign in a variable name,
                because of XPath/XSLT (@ = attribute name). Could cause some
                confusion.

                Also, remember the "table" vs "formula" debate in the main PCGen
                group? I'm in the "table" camp :) Would there be a major problem if
                you simply used var.bab1, var.bab2, etc... instead of a formula?

                It's just that formulas don't fit sometimes... Sure, there's
                the "standard" progressions, but a publisher can easily go off the
                beaten path.

                I realize that sometimes you don't have a choice but to use a formula
                (e.g.: Epic bonuses), but for levels <= 20 I still think tables are
                better.

                On the performance side, that's surprisingly good. I haven't worked
                on my engine for a couple of weeks now, but the last benchmark was a
                25th level Barbarian which is generated in 1.6s (so ~80s for 50
                iterations, C++ XML manipulation with JS game system scripting)

                My turkish $0.02

                Andargor
              • Frugal
                ... I ran out of characters that could be used as in a variable and were not already used as mathematical syntax ;O) I guess that just
                Message 7 of 28 , Jun 29, 2004
                • 0 Attachment
                  <quote who="andargor">
                  > --- In pcgen-xml@yahoogroups.com, "Frugal" <frugal@p...> wrote:
                  > I admit I am uncomfortable with an "@" sign in a variable name,
                  > because of XPath/XSLT (@ = attribute name). Could cause some
                  > confusion.

                  I ran out of characters that could be used as in a variable and were not
                  already used as mathematical syntax ;O)

                  I guess that just having '.n' at the end of a variable to indicate might
                  do. A better way would be to have a JEP function getvar(varname, level) to
                  do it.

                  Anyway, I am still not convinced that my way will work for all cases.

                  > Also, remember the "table" vs "formula" debate in the main PCGen
                  > group? I'm in the "table" camp :) Would there be a major problem if
                  > you simply used var.bab1, var.bab2, etc... instead of a formula?

                  Only because it would increase the number of variables by a factor of up
                  to 20 ;O)

                  > It's just that formulas don't fit sometimes... Sure, there's
                  > the "standard" progressions, but a publisher can easily go off the
                  > beaten path.

                  Like the Monk unarmed damage tables...

                  > I realize that sometimes you don't have a choice but to use a formula
                  > (e.g.: Epic bonuses), but for levels <= 20 I still think tables are
                  > better.
                  >
                  > On the performance side, that's surprisingly good. I haven't worked
                  > on my engine for a couple of weeks now, but the last benchmark was a
                  > 25th level Barbarian which is generated in 1.6s (so ~80s for 50
                  > iterations, C++ XML manipulation with JS game system scripting)

                  That is interesting. I get completely different results. Running
                  panther.exe with the supplied configuration (Fighter4/Bard10) takes 3.7
                  seconds including program startup.

                  If I put the character creation stuff in a loop, and create the same
                  character 10 times to offset any startup times I still get a loop time of
                  3.7 seconds... Running the loop on a 27th level Monk gives me 6.8secs per
                  loop

                  I am using the following command line to ensure that all output goes to
                  /dev/null so that the program is not slowed down by concolse display
                  speeds:

                  time /bin/yes | ./panther.exe 2&>1 > /dev/null

                  What sort of spec machine are you running on?

                  --
                  regards,
                  Frugal
                  -OS Chimp
                • andargor
                  ... (snip) ... (snip) ... time of ... 6.8secs per ... You using Cygwin or something like that? That command doesn t work for me, and I haven t made a makefile
                  Message 8 of 28 , Jun 29, 2004
                  • 0 Attachment
                    --- In pcgen-xml@yahoogroups.com, "Frugal" <frugal@p...> wrote:
                    (snip)
                    > > Also, remember the "table" vs "formula" debate in the main PCGen
                    > > group? I'm in the "table" camp :) Would there be a major problem if
                    > > you simply used var.bab1, var.bab2, etc... instead of a formula?
                    >
                    > Only because it would increase the number of variables by a factor of up
                    > to 20 ;O)
                    >
                    (snip)
                    > > It's just that formulas don't fit sometimes... Sure, there's
                    > > the "standard" progressions, but a publisher can easily go off the
                    > > beaten path.
                    >
                    > Like the Monk unarmed damage tables...
                    >
                    > > I realize that sometimes you don't have a choice but to use a formula
                    > > (e.g.: Epic bonuses), but for levels <= 20 I still think tables are
                    > > better.
                    > >
                    > > On the performance side, that's surprisingly good. I haven't worked
                    > > on my engine for a couple of weeks now, but the last benchmark was a
                    > > 25th level Barbarian which is generated in 1.6s (so ~80s for 50
                    > > iterations, C++ XML manipulation with JS game system scripting)
                    >
                    > That is interesting. I get completely different results. Running
                    > panther.exe with the supplied configuration (Fighter4/Bard10) takes 3.7
                    > seconds including program startup.
                    >
                    > If I put the character creation stuff in a loop, and create the same
                    > character 10 times to offset any startup times I still get a loop
                    time of
                    > 3.7 seconds... Running the loop on a 27th level Monk gives me
                    6.8secs per
                    > loop
                    >
                    > I am using the following command line to ensure that all output goes to
                    > /dev/null so that the program is not slowed down by concolse display
                    > speeds:
                    >
                    > time /bin/yes | ./panther.exe 2&>1 > /dev/null
                    >
                    > What sort of spec machine are you running on?
                    >
                    > --
                    > regards,
                    > Frugal
                    > -OS Chimp

                    You using Cygwin or something like that? That command doesn't work for
                    me, and I haven't made a makefile for Linux yet.

                    I've updated the file on my site with the latest version:

                    http://www.andargor.com/files/panther-demo.zip

                    I was testing in Debug mode, and the time is 1.6s for the 25th level
                    Barbarian. Note that I haven't coded in all the special abilities for
                    the classes.

                    In Release mode, it's ~850 ms. Memory usage is 20MB (I cache the XML
                    files in memory + JS engine which reserves stack/heap + some indexes).
                    I have a 2.8 G P4 512 MB and it's built under Win2K (for now :)

                    The total execution time like you calculate it, however, would include
                    loading the XML files. If you look under SRD/scripts in main.js,
                    you'll see that I calculate from before setting all the abilities,
                    adding the race, adding the class levels and skill ranks. So your
                    benchmark would depend on how fast you load the "database".

                    Andargor
                  • andargor
                    Just before I forget, I have been trying to craft an XSLT to convert your XML dump of the PCGen data files into a more neutral version, that doesn t have any
                    Message 9 of 28 , Jun 29, 2004
                    • 0 Attachment
                      Just before I forget, I have been trying to craft an XSLT to convert
                      your XML dump of the PCGen data files into a more "neutral" version,
                      that doesn't have any engine-specific stuff.

                      Would it be a lot of trouble for you to make an export that doesn't
                      have the nitty-gritty logic stuff in it or specific naming
                      conventions? Like, for example:

                      <feat id="Alertness">
                      <name>Alertness</name>
                      <type>General</type>
                      <fighter_bonus>No</fighter_bonus>
                      <multiple>No</multiple>
                      <stack>No</stack>
                      <prerequisite/>
                      <grant>
                      <bonus>
                      <skill>
                      <name>Listen</name>
                      <value>2</value>
                      <type>Unnamed</type>
                      </skill>
                      </bonus>
                      <bonus>
                      <skill>
                      <name>Spot</name>
                      <value>2</value>
                      <type>Unnamed</type>
                      </skill>
                      </bonus>
                      </grant>
                      </feat>

                      The reason I am asking is I think it would be great for data monkeys
                      to have an easy format for data entry without depending on the current
                      version of the engine, or for any particular engine for that matter.

                      For example, I could take this XML snippet and associate a piece of
                      code with it (say, "Alertness.js") which does the logic stuff. I can
                      modify the XML very easily with XSLT to fit my engine, and you could
                      do the same for yours.

                      This way, we have a stable neutral representation of the publisher data...

                      I would really like to have raw data to input into my engine for some
                      more tests. If it's not too much trouble for you, it would avoid me
                      having to reinvent your wheel... :)

                      Andargor
                    • Tir Gwaith
                      Just to throw a wrench in, because I think there will NEVER be an non-engine specific format, truely.... Your example IS engine specific....
                      Message 10 of 28 , Jun 30, 2004
                      • 0 Attachment
                        Just to throw a wrench in, because I think there will NEVER be an 'non-engine specific' format, truely....
                         
                        Your example IS engine specific....  <fighter_bonus>No</fighter_bonus> in and of itself is engine specific...  Types of feats that are choosable as class adjuncts are many, and not just "Fighter."
                         
                        There is no "neutral" version, just the perception of one.  As a data monkey, I've learned to challenge what my assumptions are, since publishers will always find new and interesting ways of looking at the game.  And there won't ever be a stable version, because new rules will always be written. 
                         
                        I don't see the point in striving to make things separate from the interpretor.  To me that is like designing a language without taking the listener into account.
                         
                        Tir Gwaith
                        LST Chimp
                        ----- Original Message -----
                        From: andargor
                        Sent: Tuesday, June 29, 2004 9:12 PM
                        Subject: [pcgen-xml] [Frugal] Converting the PCGen Data Files (WAS Re: (unknown))

                        Just before I forget, I have been trying to craft an XSLT to convert
                        your XML dump of the PCGen data files into a more "neutral" version,
                        that doesn't have any engine-specific stuff.

                        Would it be a lot of trouble for you to make an export that doesn't
                        have the nitty-gritty logic stuff in it or specific naming
                        conventions? Like, for example:

                        <feat id="Alertness">
                        <name>Alertness</name>
                        <type>General</type>
                        <fighter_bonus>No</fighter_bonus>
                        <multiple>No</multiple>
                        <stack>No</stack>
                        <prerequisite/>
                        <grant>
                          <bonus>
                           <skill>
                            <name>Listen</name>
                            <value>2</value>
                            <type>Unnamed</type>
                           </skill>
                          </bonus>
                          <bonus>
                           <skill>
                            <name>Spot</name>
                            <value>2</value>
                            <type>Unnamed</type>
                           </skill>
                          </bonus>
                        </grant>
                        </feat>

                        The reason I am asking is I think it would be great for data monkeys
                        to have an easy format for data entry without depending on the current
                        version of the engine, or for any particular engine for that matter.

                        For example, I could take this XML snippet and associate a piece of
                        code with it (say, "Alertness.js") which does the logic stuff. I can
                        modify the XML very easily with XSLT to fit my engine, and you could
                        do the same for yours.

                        This way, we have a stable neutral representation of the publisher data...

                        I would really like to have raw data to input into my engine for some
                        more tests. If it's not too much trouble for you, it would avoid me
                        having to reinvent your wheel... :)

                        Andargor
                      • Frugal
                        ... I think that a neutral version of the data can be farily easily created. The problem the D20 is not the data, but the
                        Message 11 of 28 , Jul 1 12:55 AM
                        • 0 Attachment
                          <quote who="Tir Gwaith">
                          > There is no "neutral" version, just the perception of one. As a data
                          > monkey, I've learned to challenge what my assumptions are, since
                          > publishers will always find new and interesting ways of looking at the
                          > game. And there won't ever be a stable version, because new rules will
                          > always be written.

                          I think that a 'neutral' version of the data can be farily easily created.
                          The problem the D20 is not the data, but the manipulation of the data.
                          Every time a company brings out a new rule the way the data is to be
                          manipulated needs to be changed. As you stated the problem is not the
                          data, but the extra rules that are always added.

                          As I see it encoding the rules can be done in 3 ways:
                          - The PCGen way: every thing is hard coded into the program, new rules
                          mean new code
                          - Put the rules in the data: As well as encoding the data, also encode a
                          scripting language to manipulate the data.
                          - Plugins: New rules get encoded as plugins that are loaded into the
                          program as needed. So a dataset would contain data and a list of plugins
                          that are required to manipulate the data.

                          --
                          regards,
                          Frugal
                          -OS Chimp
                        • Frugal
                          I have a certain set of requirements for a truely generic system. These ... I have a rough requirements document I keep adding to as I
                          Message 12 of 28 , Jul 1 3:44 AM
                          • 0 Attachment
                            <quote who="Frugal">
                            I have a certain set of requirements for a truely generic system. These
                            > include (but are not limited to):
                            >
                            > - Support Core 3.0 characters
                            > - Support Core 3.5 characters
                            > - Support Epic Characters
                            > - Support Exclusive Skills (i.e. the complicated calculations
                            > for maxRanks)
                            > - Support Gestalt Characters (in many forms: Take highest of 2+ values;
                            > take sum of 2+ values; take mean of 2+ values);
                            > - Support Adding a race and class level at the same time (i.e. in our
                            > campaign the DM has decided that the player with the Astral Deva
                            > character gets a different XP progression, but goes up a level of
                            > Deva and a level of cleric at the same time).
                            > - Support floating point variables (i.e. Monk/Rogue BAB of 3.75/3.75
                            > would give a BAB of floor(3.75+3.75)=7 rather than
                            > floor(3.75)+floor(3.75)=6 )

                            I have a rough requirements document I keep adding to as I experiment. I
                            currently have 89 requirements and growing ;O)

                            --
                            regards,
                            Frugal
                            -OS Chimp
                          • David Finch
                            ... Could you not move to making more of the rules coded into loadable javascript?
                            Message 13 of 28 , Jul 1 3:57 AM
                            • 0 Attachment
                              Frugal wrote:
                              > As I see it encoding the rules can be done in 3 ways:
                              > - The PCGen way: every thing is hard coded into the program, new rules
                              > mean new code
                              > - Put the rules in the data: As well as encoding the data, also encode a
                              > scripting language to manipulate the data.
                              > - Plugins: New rules get encoded as plugins that are loaded into the
                              > program as needed. So a dataset would contain data and a list of plugins
                              > that are required to manipulate the data.

                              Could you not move to making more of the rules coded into loadable javascript?
                            • Frugal
                              ... That was option 2 ;O) -- regards, Frugal -OS Chimp
                              Message 14 of 28 , Jul 1 4:09 AM
                              • 0 Attachment
                                <quote who="David Finch">
                                > Frugal wrote:
                                >> As I see it encoding the rules can be done in 3 ways:
                                >> - The PCGen way: every thing is hard coded into the program, new rules
                                >> mean new code
                                >> - Put the rules in the data: As well as encoding the data, also encode
                                >> a
                                >> scripting language to manipulate the data.
                                >> - Plugins: New rules get encoded as plugins that are loaded into the
                                >> program as needed. So a dataset would contain data and a list of
                                >> plugins
                                >> that are required to manipulate the data.
                                >
                                > Could you not move to making more of the rules coded into loadable
                                > javascript?

                                That was option 2 ;O)

                                --
                                regards,
                                Frugal
                                -OS Chimp
                              • David Finch
                                ... True. I kind of thought you meant adding some small scriptlets into tags. This would add to the completity. My vision of how it should work is a bit more
                                Message 15 of 28 , Jul 1 4:36 AM
                                • 0 Attachment
                                  Frugal wrote:

                                  > <quote who="David Finch">
                                  >
                                  >>Frugal wrote:
                                  >>
                                  >>>As I see it encoding the rules can be done in 3 ways:
                                  >>> - The PCGen way: every thing is hard coded into the program, new rules
                                  >>> mean new code
                                  >>> - Put the rules in the data: As well as encoding the data, also encode
                                  >>>a
                                  >>> scripting language to manipulate the data.
                                  >>> - Plugins: New rules get encoded as plugins that are loaded into the
                                  >>> program as needed. So a dataset would contain data and a list of
                                  >>>plugins
                                  >>> that are required to manipulate the data.
                                  >>
                                  >>Could you not move to making more of the rules coded into loadable
                                  >>javascript?
                                  > That was option 2 ;O)

                                  True. I kind of thought you meant adding some small 'scriptlets' into tags.
                                  This would add to the completity.

                                  My vision of how it should work is a bit more radical. Remove all the
                                  character creation specific code from the program all together. Change the
                                  LST/XML tags and java code with Javascript functions which are loaded to
                                  do the work. This has the disadvatage that they are harder for
                                  non-programmers but it would make modifications and updates simpler. (may
                                  be a simpler type could be made for the non-programers).

                                  To make this work there would be a fix data model of the character, this
                                  would enforce only stuff like: there are N abilities, they must have a Name
                                  and a Score and a Mod etc. Extra fields can be dynamically added but the
                                  Display part of the app, would need specific Java(script) to display them
                                  (for example see Mozilla). XML would be used only for the Character Sheet
                                  data all other data would be in the Javascript files.
                                • Frugal
                                  ... Have a look at the work andargor had been doing: http://www.andargor.com/files/panther-demo.zip -- regards, Frugal -OS Chimp
                                  Message 16 of 28 , Jul 1 4:37 AM
                                  • 0 Attachment
                                    <quote who="David Finch">
                                    > My vision of how it should work is a bit more radical. Remove all the
                                    > character creation specific code from the program all together. Change the
                                    > LST/XML tags and java code with Javascript functions which are loaded to
                                    > do the work. This has the disadvatage that they are harder for
                                    > non-programmers but it would make modifications and updates simpler. (may
                                    > be a simpler type could be made for the non-programers).

                                    Have a look at the work andargor had been doing:

                                    http://www.andargor.com/files/panther-demo.zip

                                    --
                                    regards,
                                    Frugal
                                    -OS Chimp
                                  • David Finch
                                    ... Very intresting, did this go any further or was it just a tech demo?
                                    Message 17 of 28 , Jul 1 6:54 AM
                                    • 0 Attachment
                                      Frugal wrote:
                                      > Have a look at the work andargor had been doing:
                                      > http://www.andargor.com/files/panther-demo.zip

                                      Very intresting, did this go any further or was it just a tech demo?
                                    • Frugal
                                      ... It is curently a tech demo in that this is as far as he has developed it over a couple of weeks. Like all of the tech demos there
                                      Message 18 of 28 , Jul 1 7:13 AM
                                      • 0 Attachment
                                        <quote who="David Finch">
                                        > Frugal wrote:
                                        >> Have a look at the work andargor had been doing:
                                        >> http://www.andargor.com/files/panther-demo.zip
                                        >
                                        > Very intresting, did this go any further or was it just a tech demo?

                                        It is curently a tech demo in that this is as far as he has developed it
                                        over a couple of weeks.

                                        Like all of the tech demos there is a huge difference between handling the
                                        basics and handling the more complicated stuff ( I know that I keep
                                        hitting problems doing some of the more esoteric things).

                                        --
                                        regards,
                                        Frugal
                                        -OS Chimp
                                      • andargor
                                        ... non-engine specific format, truely.... ... No in and of itself is engine specific... Types of feats that are choosable as
                                        Message 19 of 28 , Jul 4 4:14 PM
                                        • 0 Attachment
                                          --- In pcgen-xml@yahoogroups.com, "Tir Gwaith"
                                          <thoron-tir-gwaith@l...> wrote:
                                          > Just to throw a wrench in, because I think there will NEVER be an
                                          'non-engine specific' format, truely....
                                          >
                                          > Your example IS engine specific....
                                          <fighter_bonus>No</fighter_bonus> in and of itself is engine
                                          specific... Types of feats that are choosable as class adjuncts are
                                          many, and not just "Fighter."
                                          >
                                          > There is no "neutral" version, just the perception of one. As a
                                          data monkey, I've learned to challenge what my assumptions are, since
                                          publishers will always find new and interesting ways of looking at the
                                          game. And there won't ever be a stable version, because new rules
                                          will always be written.
                                          >
                                          > I don't see the point in striving to make things separate from the
                                          interpretor. To me that is like designing a language without taking
                                          the listener into account.
                                          >
                                          > Tir Gwaith
                                          > LST Chimp

                                          Nice wrench. :)

                                          I don't want ot discuss semantics, but the example I gave is not
                                          specific to any engine. For example, I do not plan to use the
                                          fighter_bonus tag in my program and I doubt Frugal or PCGen will ever
                                          use it.

                                          The point is to use XML for what it is intended for: tagging data,
                                          nothing more, nothing less. It is a machine readable version of
                                          publisher data, that's all.

                                          fighter_bonus gets transformed into engine specific tags:
                                          <bonus><type>Fighter</type></bonus> or <bonus id="Alterness"
                                          type="fighter.bonus"> or even TYPE:General.Fighter if you want to
                                          regenerate LST. You use XSLT to do that.

                                          The marvelous thing is that you only coded the publisher data once.
                                          All you have to do is maintain a transform (XSLT). Ain't that sweet?

                                          Andargor
                                        • andargor
                                          ... handling the ... Yes, it s only a demo as I m experimenting with the various options Frugal described for the logic and rules portion of the problem. I
                                          Message 20 of 28 , Jul 4 4:33 PM
                                          • 0 Attachment
                                            --- In pcgen-xml@yahoogroups.com, "Frugal" <frugal@p...> wrote:
                                            >
                                            > <quote who="David Finch">
                                            > > Frugal wrote:
                                            > >> Have a look at the work andargor had been doing:
                                            > >> http://www.andargor.com/files/panther-demo.zip
                                            > >
                                            > > Very intresting, did this go any further or was it just a tech demo?
                                            >
                                            > It is curently a tech demo in that this is as far as he has developed it
                                            > over a couple of weeks.
                                            >
                                            > Like all of the tech demos there is a huge difference between
                                            handling the
                                            > basics and handling the more complicated stuff ( I know that I keep
                                            > hitting problems doing some of the more esoteric things).
                                            >
                                            > --
                                            > regards,
                                            > Frugal
                                            > -OS Chimp

                                            Yes, it's only a demo as I'm experimenting with the various options
                                            Frugal described for the "logic" and "rules" portion of the problem.

                                            I tend to favor "option 3":

                                            - use a neutral version of the base data which isn't egine specific
                                            (enter data once, use many times)
                                            - Transform data into an engine specific format (Frugal's, mine,
                                            Engine XYZ) using XSLT
                                            - Have scriptlets that hook in to provide the rules aspect (I use the
                                            term "scriptlets" to denote small bits of code in the engine's
                                            preferred language: javascript, python, perl, whatever)

                                            The reason that I like this approach is that you don't have to agree
                                            on a very specific format for the neutral base data. It can be very
                                            loose, like I described. As well, option 2 is still too close to
                                            engine specific code, since everyone would have to agree on a language
                                            and an API.

                                            On the maintenance side, as publisher data is released you don't need
                                            developer-grade people to code in loose XML. There are a lot of people
                                            out there that are willing to help but that don't know LST,
                                            javascript, etc. So their task would be to enter the base data using
                                            guidelines. Sure a schema or DTD could be used, but we would have to
                                            agree on it, which is no mean task.

                                            The rules or logic portion would be then the responsibility of the
                                            developer-grade people for each engine. You distribute the workload,
                                            and you remove the engine dependency from the base data if an engine
                                            gets updated.

                                            My general philosophy is that we should minimize the requirements for
                                            standards, since that is what has stopped XML projects in the past.
                                            Everyone has his/her own view of how the XML data should be
                                            structured, and arguments. Let's just get something that can be
                                            machine readable and reused out there. The "small steps" theory.

                                            Frugal, is it possible for you to do a "neutral" dump as I described
                                            if it's not too much trouble? It would allow me to demonstrate what I
                                            mean. I could even craft an XSLT that would format the neutral data
                                            into one compatible with your engine (as much as possible). It would
                                            be much appreciated :)

                                            If you don't have the time, could you upload your LST parser so I can
                                            fiddle with it?

                                            Andargor
                                          • Paul M. Lambert
                                            ... I ve been reading this discussion and I d like to make sure I understand what you mean, andargor. Tell me what below matches your thoughts and what
                                            Message 21 of 28 , Jul 4 6:07 PM
                                            • 0 Attachment
                                              On Sun, 04 Jul 2004, andargor wrote:

                                              > Nice wrench. :)
                                              >
                                              > I don't want ot discuss semantics, but the example I gave is not
                                              > specific to any engine. For example, I do not plan to use the
                                              > fighter_bonus tag in my program and I doubt Frugal or PCGen will ever
                                              > use it.
                                              >
                                              > The point is to use XML for what it is intended for: tagging data,
                                              > nothing more, nothing less. It is a machine readable version of
                                              > publisher data, that's all.
                                              >
                                              > fighter_bonus gets transformed into engine specific tags:
                                              > <bonus><type>Fighter</type></bonus> or <bonus id="Alterness"
                                              > type="fighter.bonus"> or even TYPE:General.Fighter if you want to
                                              > regenerate LST. You use XSLT to do that.
                                              >
                                              > The marvelous thing is that you only coded the publisher data once.
                                              > All you have to do is maintain a transform (XSLT). Ain't that sweet?
                                              >
                                              > Andargor

                                              I've been reading this discussion and I'd like to make sure I understand
                                              what you mean, andargor.

                                              Tell me what below matches your thoughts and what doesn't, so we can get
                                              on the same page. Then I'll be able to tell if I actually agree with
                                              you. :-)

                                              As I see it your "data neutral" format idea could be re-expressed as a
                                              high level pseudo language. This language could then be converted into
                                              a given engine's native format (LST, PCGEN-XML--whatever that is,
                                              "plambertgen", whatever) if someone writes such a converter. And then the
                                              engine can handle that data as it sees fit.

                                              I see this to mean that the data neutral format would allow tag
                                              (re-)definitions, so, for example, <figher_bonus> could be a tag
                                              used in one data file, and it might be definied in coarser game
                                              terms in another. This would allow "libraries" of definitions for
                                              a given game system or rule set that would allow easy mapping to
                                              specific engines in the converters.

                                              I'm trying to think of a concrete example. Perhaps something like:

                                              <str>7</str>

                                              in a character definition for a 3.5 SRD character. And in the
                                              library data file for 3.5 SRD, you might have:

                                              <character>
                                              ...
                                              <attribute>
                                              <name>Strength</name>
                                              <abbr>STR</abbr>
                                              <tag>str</tag>
                                              <description>Physical strength and prowess</description>
                                              ...
                                              </attribute>
                                              ...
                                              </character>

                                              These are extremely rough non-scaling examples, of course, and not
                                              necessarily how I actually suggest doing attributes, but anyway...

                                              A converter then might take that information and turn it into LST data.
                                              The converter would know the limits of its target format. For example,
                                              if it's not possible to actually change/rename/add attributes in LST
                                              format, it would basically know to ignore the attribute definitions and
                                              use the ones inherent to the engine. If another were used, it could
                                              generate a warning or error.

                                              A converter might even have full internal knowledge of a given "library"
                                              as well, if it was a good choice for the coder/engine/etc. For example,
                                              an engine extremely specific to a certain game rule set (maybe an SRD3.5
                                              only web character repository, or whatever) could ignore the library
                                              entirely, since the author would know what was and wasn't defined in
                                              there.

                                              This would mean the libraries and the converters could be maintained by
                                              people with strong such skills, while the casual user who just wants to
                                              say "I'd like to add a Bow of Tumultuous Angst to my equipment lists;
                                              it's a Long Bow that gives +2/+4 only to Chaotic Neutral wielders."
                                              could do it with dirt-simple, straightforward tags. Still valid XML, but
                                              really simple tags whose inner workings are defined elsewhere, out of
                                              sight.

                                              However, if they want it to give the wielder +1 to hit for each pound of
                                              bat guano they're carrying, they'll need to dig deeper. But simple
                                              things will be easy and complex things will be possible. Right?

                                              Please let me know where I misunderstand.

                                              --plambert
                                            • andargor
                                              Answers inline. ... (snip) ... then the ... You sure think ahead :) Actually, what I propose is more basic: just convert publisher data into a machine readable
                                              Message 22 of 28 , Jul 4 6:49 PM
                                              • 0 Attachment
                                                Answers inline.

                                                --- In pcgen-xml@yahoogroups.com, "Paul M. Lambert" <plambert@p...> wrote:
                                                (snip)
                                                > As I see it your "data neutral" format idea could be re-expressed as a
                                                > high level pseudo language. This language could then be converted into
                                                > a given engine's native format (LST, PCGEN-XML--whatever that is,
                                                > "plambertgen", whatever) if someone writes such a converter. And
                                                then the
                                                > engine can handle that data as it sees fit.
                                                >
                                                > I see this to mean that the data neutral format would allow tag
                                                > (re-)definitions, so, for example, <figher_bonus> could be a tag
                                                > used in one data file, and it might be definied in coarser game
                                                > terms in another. This would allow "libraries" of definitions for
                                                > a given game system or rule set that would allow easy mapping to
                                                > specific engines in the converters.


                                                You sure think ahead :)

                                                Actually, what I propose is more basic: just convert publisher data
                                                into a machine readable format with a minimum of context (i.e. XML
                                                tags) so that it can be manipulated. Your library concept could then
                                                be implemented, if you wish to do so. First things first :)

                                                (snip)
                                                > This would mean the libraries and the converters could be maintained by
                                                > people with strong such skills, while the casual user who just wants to
                                                > say "I'd like to add a Bow of Tumultuous Angst to my equipment lists;
                                                > it's a Long Bow that gives +2/+4 only to Chaotic Neutral wielders."
                                                > could do it with dirt-simple, straightforward tags. Still valid
                                                XML, but
                                                > really simple tags whose inner workings are defined elsewhere, out of
                                                > sight.


                                                Yes, the general idea is to leverage the large quantity of people that
                                                have the willingess to help but not necessarily the coding skills.
                                                They could describe that bow very simply, and fill in the logic
                                                portion as a description. Someone with coding skills could then craft
                                                an engine specific XSLT and translate the logic into engine-specific
                                                "scriptlets" for a particular tool.

                                                Andargor
                                              • Frugal
                                                ... The LST parser is already up on the groups file section: http://groups.yahoo.com/group/pcgen-xml/files/sample_source-20031216.tgz As
                                                Message 23 of 28 , Jul 5 1:08 AM
                                                • 0 Attachment
                                                  <quote who="andargor">

                                                  > Frugal, is it possible for you to do a "neutral" dump as I described
                                                  > if it's not too much trouble? It would allow me to demonstrate what I
                                                  > mean. I could even craft an XSLT that would format the neutral data
                                                  > into one compatible with your engine (as much as possible). It would
                                                  > be much appreciated :)
                                                  >
                                                  > If you don't have the time, could you upload your LST parser so I can
                                                  > fiddle with it?

                                                  The LST parser is already up on the groups file section:

                                                  http://groups.yahoo.com/group/pcgen-xml/files/sample_source-20031216.tgz

                                                  As the date indicates this has not been worked on since the middle of
                                                  december. Be warned: "here be kludges".

                                                  Feel free to do with it as you will, There should be a GPL header at the
                                                  top of each file ;O)

                                                  --
                                                  regards,
                                                  Frugal
                                                  -OS Chimp
                                                • David Finch
                                                  ... A first good step would be that the data had been input. If the logic has been typed in english then at least when the conversion to PCgen format is done
                                                  Message 24 of 28 , Jul 5 3:03 AM
                                                  • 0 Attachment
                                                    andargor wrote:
                                                    > Yes, the general idea is to leverage the large quantity of people that
                                                    > have the willingess to help but not necessarily the coding skills.
                                                    > They could describe that bow very simply, and fill in the logic
                                                    > portion as a description. Someone with coding skills could then craft
                                                    > an engine specific XSLT and translate the logic into engine-specific
                                                    > "scriptlets" for a particular tool.

                                                    A first good step would be that the data had been input. If the logic has
                                                    been typed in english then at least when the conversion to PCgen format is
                                                    done someone can go though at 'specialise it' to PCgen format. This has the
                                                    added advatage that someone can check that the english logic matches the
                                                    real programming logic.
                                                  • andargor
                                                    ... 20031216.tgz ... of ... at the ... Yikes! There be kludges :) Well, I had to craft an Ant build.xml, and it seems to compile properly... What version of
                                                    Message 25 of 28 , Jul 6 5:36 AM
                                                    • 0 Attachment
                                                      --- In pcgen-xml@yahoogroups.com, "Frugal" <frugal@p...> wrote:
                                                      >
                                                      > The LST parser is already up on the groups file section:
                                                      >
                                                      > http://groups.yahoo.com/group/pcgen-xml/files/sample_source-
                                                      20031216.tgz
                                                      >
                                                      > As the date indicates this has not been worked on since the middle
                                                      of
                                                      > december. Be warned: "here be kludges".
                                                      >
                                                      > Feel free to do with it as you will, There should be a GPL header
                                                      at the
                                                      > top of each file ;O)
                                                      >
                                                      > --
                                                      > regards,
                                                      > Frugal
                                                      > -OS Chimp

                                                      Yikes! There be kludges :)

                                                      Well, I had to craft an Ant build.xml, and it seems to compile
                                                      properly...

                                                      What version of the data files were you using? The parser is croaking
                                                      on several of the 5.7.2 ones.

                                                      Andargor
                                                    • Frugal
                                                      ... Oh, yeah, oops. I was using Eclipse and it managed all of the building for me ;O) ... I was using the CVS data as of the date of the
                                                      Message 26 of 28 , Jul 6 5:43 AM
                                                      • 0 Attachment
                                                        <quote who="andargor">
                                                        > --- In pcgen-xml@yahoogroups.com, "Frugal" <frugal@p...> wrote:
                                                        >>
                                                        >> The LST parser is already up on the groups file section:
                                                        >>
                                                        >> http://groups.yahoo.com/group/pcgen-xml/files/sample_source-
                                                        > 20031216.tgz
                                                        >>
                                                        >> As the date indicates this has not been worked on since the middle
                                                        > of
                                                        >> december. Be warned: "here be kludges".
                                                        >>
                                                        >> Feel free to do with it as you will, There should be a GPL header
                                                        > at the
                                                        >> top of each file ;O)
                                                        >
                                                        > Yikes! There be kludges :)
                                                        >
                                                        > Well, I had to craft an Ant build.xml, and it seems to compile
                                                        > properly...

                                                        Oh, yeah, oops. I was using Eclipse and it managed all of the building for
                                                        me ;O)

                                                        > What version of the data files were you using? The parser is croaking
                                                        > on several of the 5.7.2 ones.

                                                        I was using the CVS data as of the date of the archive. So any new tags
                                                        will fail.

                                                        IT would be so nice if every time someone messed around with a data tag
                                                        they were forced to increment the LST version number. It would make data
                                                        management a lot easier if you could state which version of LST syntax
                                                        your LST files were.

                                                        --
                                                        regards,
                                                        Frugal
                                                        -OS Chimp
                                                      • andargor
                                                        ... tag ... data ... syntax ... Or if the data were in XML and the rule logic described somewhere for PCGen, the LST could be regenerated with each new version
                                                        Message 27 of 28 , Jul 6 10:09 AM
                                                        • 0 Attachment
                                                          --- In pcgen-xml@yahoogroups.com, "Frugal" <frugal@p...> wrote:
                                                          >
                                                          > IT would be so nice if every time someone messed around with a data
                                                          tag
                                                          > they were forced to increment the LST version number. It would make
                                                          data
                                                          > management a lot easier if you could state which version of LST
                                                          syntax
                                                          > your LST files were.
                                                          >
                                                          > --
                                                          > regards,
                                                          > Frugal
                                                          > -OS Chimp

                                                          Or if the data were in XML and the rule logic described somewhere for
                                                          PCGen, the LST could be regenerated with each new version ;)

                                                          Andargor
                                                        • Mark Coletti
                                                          On Thu, 1 Jul 2004 08:55:51 +0100 (BST), Frugal ... It was put the rules in the data that did it for me. What you re talking about is really a knowledge
                                                          Message 28 of 28 , Jul 14 12:56 PM
                                                          • 0 Attachment
                                                            On Thu, 1 Jul 2004 08:55:51 +0100 (BST), Frugal
                                                            <frugal@...> wrote:
                                                            >
                                                            > <quote who="Tir Gwaith">
                                                            > > There is no "neutral" version, just the perception of one. [...] there won't
                                                            > > ever be a stable version, because new rules will
                                                            > > always be written.

                                                            > I think that a 'neutral' version of the data can be farily easily created.
                                                            > The problem the D20 is not the data, but the manipulation of the data.
                                                            > Every time a company brings out a new rule the way the data is to be
                                                            > manipulated needs to be changed. As you stated the problem is not the
                                                            > data, but the extra rules that are always added.

                                                            > As I see it encoding the rules can be done in 3 ways:
                                                            > - The PCGen way: every thing is hard coded into the program, new rules
                                                            > mean new code
                                                            > - Put the rules in the data: As well as encoding the data, also encode a
                                                            > scripting language to manipulate the data.
                                                            > - Plugins: New rules get encoded as plugins that are loaded into the
                                                            > program as needed. So a dataset would contain data and a list of plugins
                                                            > that are required to manipulate the data.

                                                            It was "put the rules in the data" that did it for me. What you're
                                                            talking about is really a knowledge base; which makes sense in that
                                                            PCGen *is* essentially an expert system that relies on a
                                                            knowledge-base containing rules for various d20 based gaming systems.
                                                            The problem is that most of the knowledge is either hard-coded in Java
                                                            or in LST files, and most of the "inferencing" for the huge cloud of
                                                            rules is also hard-coded. (Think IF-THEN and SWITCH statements as a
                                                            crude sort of linear, data-driven 'inferencing'.)

                                                            JESS is a free, open-source, expert system implemented in Java. I can
                                                            easily see where most of the PCGen "knowledge-base" currently spread
                                                            among Java and LST files could be rolled into a knowledge-base
                                                            containing explicit rules. Specific systems would just add new
                                                            knowledge-bases that contain fresh sets of rules (including some that
                                                            may remove or modify existing ones).

                                                            A JESS (or similar system) based PCGen system would be inherently
                                                            smaller since the brunt of the inferencing will be left to the
                                                            inference engine, and the rules would be explicitly codified as, well,
                                                            rules. You could also set up the knowledge-base such that you can
                                                            generate explanations. One thing about the d20 systems is that
                                                            they're very complex once you consider all the different rules and
                                                            their respective interactions. If, say, a character has an 18 AC, it
                                                            might be nice to know *how* and *why* it's currently 18. All the
                                                            rules that trigger AC mods could contribute to explanatory text. "AC
                                                            base 10, +2 for Dexterity, +3 for ring of nimbleness, +3 to <mumble>
                                                            spell effect."

                                                            Of course this is all pie-in-the-sky ramblings implementing JESS in
                                                            PCGen would entail quite a bit of work. (Um, I think.) But, what the
                                                            hell, it makes for a pleasant gedankenexperiment. %-)

                                                            More info:

                                                            http://web.njit.edu/all_topics/Prog_Lang_Docs/html/jess51/

                                                            Cheers!

                                                            MAC
                                                            --
                                                            I'm taking reality in small doses to build immunity.
                                                          Your message has been successfully submitted and would be delivered to recipients shortly.