Open Source d20 API/Engine

[reanjr]

The thing is that history could easily be included in this. I said that I didn't think it should include calculated number or, at least, only calculated numbers. If we include both, the way it would work out is something like this:

<!--half-orc example-->
<character>
	<strength>13
		<modifier mod="2" source="race" />
		<modifier mod="1" source="level" level="4" />
	</strength>
	<dexterity>10</dexterity>
	<constitution>10</constitution>
	<intelligence>8
		<modifier mod="-2" source="race" />
		<modifier mod="1" source="level" level="8" />
	</intelligence>
	<wisdom>10
             	<modifier mod="-1" source="leveldecrease" level="8" />
             </wisdom>
	<charisma>8
		<modifier mod="2" source="race" />
	</charisma>

OK, in that case, we're on the same page. I have no problem supporting a history in the design spec. I just wanted to make sure it was built from current -> back rather than from starting -> forward so "dumb" clients could still use the character. I'm sold on that idea.

Good idea about the history tag. That would actually work well for one of the design issues I was trying to come up with a solution for - how to separate temporary modifiers from permanent ones (by temporary, I mean ones that are not saved to the character but are added from, for instance, a temporary spell effect or something like that). My initial thought was to go through the various "source" attributes checking to see if the source attribute was a permanent one or not, but it seemed clunky, which, of course, it was.

So you could have something like:

<strength>17
	<history mod="2" source="race" />
	<history mod="1" source="level" meta="4" />
	<modifier mod="4" source="spell" meta="1" />
</strength>

Notes:
- There's a good reason I used meta instead of level that I needn't go into now.
- The meta for spell is sort of an id for the spell that an event can be attached to so that, when the spell runs out, it can be removed.

Then when saving the character, any application that supported temporary modifiers could remove all modifier tags (and reduce the value accordingly) before saving. Unless you wanted to have an option to save exact state (if you leave off gaming in the middle of a battle or you are playing a PbP type game).

I think that would work pretty well.

[edit] Maybe even a third tag for non-permanent, but long term modifiers (such as a continuous magic item). I'll think more on that idea after I get the first two or three chapters of the PHB translated to markup.

 

[MaxKaladin]

OK, in that case, we're on the same page. I have no problem supporting a history in the design spec. I just wanted to make sure it was built from current -> back rather than from starting -> forward so "dumb" clients could still use the character. I'm sold on that idea.

Good idea about the history tag. That would actually work well for one of the design issues I was trying to come up with a solution for - how to separate temporary modifiers from permanent ones (by temporary, I mean ones that are not saved to the character but are added from, for instance, a temporary spell effect or something like that). My initial thought was to go through the various "source" attributes checking to see if the source attribute was a permanent one or not, but it seemed clunky, which, of course, it was.

So you could have something like:

<strength>17
	<history mod="2" source="race" />
	<history mod="1" source="level" meta="4" />
	<modifier mod="4" source="spell" meta="1" />
</strength>

How about we develop it a bit further to have a <base> tag. That way you have the starting point and all the modifiers both historical and current used to arrive at the final number. Thus:

<strength>17
	<base value="10" />
	<history mod="2" source="race" />
	<history mod="1" source="level" meta="4" />
	<modifier mod="4" source="spell" meta="1" />
</strength>

A program can ignore all that and just use the given strength number or it can derive its own number by reading the base tag and then applying the history and modifier tags to arrive at the proper number.

[edit] Maybe even a third tag for non-permanent, but long term modifiers (such as a continuous magic item). I'll think more on that idea after I get the first two or three chapters of the PHB translated to markup.

That's not a bad idea, but it might also be applied using the existing modifier tags. Just set the source to "item" and use the meta tag to identify which one somehow.

 

[nopantsyet]

Hi--Good thoughts everyone. I've set up a Wiki at my web site http://rpgengine.newtongamers.com/ if you'd like to start some work there. It's going to start out informal while we determine how the project will be governed. I would like this to be lightweight and straightforward, but all final works should have consistency with the design goals. I'll post some more thoughts on this tonight.

 

[Planesdragon]

I agree with you, but I do actually think .doc files keep change history of some kind. It's at least an option.

MS's Word .DOC format has an *option* of etiher tracking changes or saving a previous version. Both of these are not turned on by default, and can baloon a document's size to unwiedly proportions.

Just a Wednesday night FYI.

 

[Firzair]

Well, this is what I've accomplished since this discussion began (though a lot of it has been stewing in my head for quite some time).

Just wanted to post this up in case anyone wanted to take a look. This is the beginning documentation for what I call RPGML (RPG Markup Language). It includes most of the core functions that an interpreter must understand (it's missing the ones related to adding and deleting XML tags from a dataset). It should give you a more formal idea of what I've been blathering about in random spurts of XML. I've already coded a library of a dozen or so helper functions in this language to facilitate easier use, but I haven't had the time to document them.

Some of the helper functions include (C/Java equivilents with my function names in parentheses):

>= operator (gte)
<= operator (lte)
?: operator (if)
&& operator (and)
|| operator (or)
A simple switch statement (supports different branches on <, =, >) (compare)
A function that takes a number and normalizes it to a certain range (range)

In addition, I have the following rules coded up in RPGML:

The core mechanic.
Ability score modifiers.
Bonus spells based for high abilties.
A generic roll function that will take any-sided die with any modifier.
A function for each die (d6 function, d8 function, etc.).
Racial ability score modifiers.
Human bonus feat and skills.
Most Dwarven racial abilties (Stability was a pain, but I think I have the issue resolved now).

As you might imagine, I'm steadily moving my way directly through the SRD.

I currently left off on the racial rules to work on the core create-character function so that the engine knows what steps need to be taken (for instance apply race stuff AFTER ability scores) and I can work out how the language tells the app it needs input from an end user.

Hi reanjr,
this document's something I really like. One more thing to define would be the modifier because there's a distinct mechanic behind the modifier handling (stacking of different bonustypes). But if this could easily be done with the current ruleset (RPGL) I'd like to see how it comes out.

Greetings
Firzair

PS: I think I'll rewrite my script engine to use RPGL

 

[reanjr]

How about we develop it a bit further to have a <base> tag. That way you have the starting point and all the modifiers both historical and current used to arrive at the final number.

I suppose you could for clarity, but I'm not sure what use it would have except to introduce data integrity issues (if someone hand-edited and forgot to change one of the mods, but they changed the final). You can always backtrack it. There might also be a problem if you create a character in an editor that fully supports history then modify it in one that doesn't. It's something to think about, though.

 

[Firzair]

A bit OT, but I've got a question about XML: how would XML represent a char who has the feat toughness twice? Do you need a counter for this?

Greetings
Firzair

 

[reanjr]

Nope...

<character>
	<feat name="toughness" />
	<feat name="toughness" />
</character>

...or some such thing would work fine.

 

[Firzair]

Hi reanjr,
I think there is some more functionality needed from the RPGL:

• Some kind of SELECT for getting a collection of something used with a kind of FOREACH clause (e.g. Select from Feats where Feats.Type like "Fighter").
• I think there has to be a scope for each function (e.g. something that says this function belongs to the object creature)

Could this already be done or do you have to implement some more tags?

Greetings
Firzair

 

[reanjr]

Hi reanjr,
this document's something I really like. One more thing to define would be the modifier because there's a distinct mechanic behind the modifier handling (stacking of different bonustypes). But if this could easily be done with the current ruleset (RPGL) I'd like to see how it comes out.

Greetings
Firzair

PS: I think I'll rewrite my script engine to use RPGL

I thought I had responded to this... maybe not.

Anyway, yes it can be done in RPGML. I just need to decide how I want it to work. Since I haven't gotten to that part of the rules yet, I don't want to make a decision until I see how more of the data pans out. As an initial guess, It would probably be something along the lines of passing in a stat name and having the function iterate over all the modifiers that stat has and store them in a temporary context (you can think of a context as an XML element with any number of attributes and child elements), checking whether there is already a modifier in the temporary context with the same bonus type. Once it's done building the temporary context full of unique modifier, it would just go through and add them up.

In the long run, all you would do is call <get-mod name="search-skill" /> or something like that.