[ d20statblock.org ] a grammar

[jmettraux]

Like CRGreathouse said "That sounds good, but what is the purpose of this type of definition?
Is it primarily designed for human or machine reading? "

Perhaps if you could elaborate on the answers to these questions and why you feel a statblock should be used as a target for computer programs.

Currently, the grammar could be seen as way to define precisely how informations in a stat block should be displayed.
I came with this grammar because the style guide is rather fuzzy.

Generating parsers automatically is a secondary effect that is not immediately targeted.

What's great about XML is that it is also human-readable, what's great about a standard stat block format is that it is also computer-readable.

As dgsh conceptor I want to be able to get on an online generator site, copy a stat block and 'feed' it to dgsh without too much hassle. This could benefit to all 'in-flight' programs and DM Familiar for example, clearly states in its new features that it can parse other program's stat blocks.

If you don't want all the monsters you've taken out of RPM's database and displayed in stat blocks to be parsed by another's program : OK, don't use the standard.
But if Luke is listed in d20statblock.org's supporters, why not follow his path and support the standard (when it's stable ) ?

smetzger, you'll always be right, XML is a better format for programs interoperability.
But if a computer can parse a fiscal declaration why not stat blocks ?

If other RPG software developers could issue an opinion about a stat block standard, we could have a clear view about 'computers parsing stat blocks'.

 

[CRGreathouse]

As dgsh conceptor I want to be able to get on an online generator site, copy a stat block and 'feed' it to dgsh without too much hassle. This could benefit to all 'in-flight' programs and DM Familiar for example, clearly states in its new features that it can parse other program's stat blocks.

This is essentially why I want the statdnard - some programs are better at certain things than others, and having a single format makes it easy to use whatever's best for the particular job for just that job.

1) How should a weapon's range be displayed ?

2) The current grammar authorizes things like "Lolth / Drow, Spider and Evil". There is one domain that is not needed.

3) Are specialty spells (necromancers, invokers, ...) displayed like domain spells ?
(If you want I can just go a 'copy-paste-adjust' domainSpellsSection in specialtySpellsSection)

1. Range is listed (optionally) after crit: longbow +6 (1d8/crit x3, range 50 ft)
2. This is intentional - there are prestige classes (and an epic feat) that grant extra domains.
3. No, they're mixed in with normal spells. It hasn't caused problems yet, and I don't see why it would.

 

[jmettraux]

new revision of the grammar :

http://cvs.sourceforge.net/cgi-bin/...rev=HEAD&content-type=text/vnd.viewcvs-markup


"String" is not implicit. I used it in the beginning as a handy abstraction tool. Now we've defined it and it's fine.
Integer and Float aren't implicit too, but it isn't hard to define them.

In this new revision of the grammar I changed the reference from "String" to "string".

Concerning name and raceName... Will ever a computer program have enough common sense to differentiate two such strings ?
At least, here, the standard is clear for human beings, for the computer, it ends up manipulating 2 strings, not 2 concepts.

Thanks for the replies up there.
I brought the specialized spells on the "negociation table" because you clearly separated domain spells from other prepared spells. Specialized wizards have a bonus spell a day from their school, it's quite similar to a domain spell. (I also have less business logic to implement if the specialized spells are clearly tagged as such. )

 

[CRGreathouse]

"String" is not implicit. I used it in the beginning as a handy abstraction tool. Now we've defined it and it's fine.
Integer and Float aren't implicit too, but it isn't hard to define them.

In this new revision of the grammar I changed the reference from "String" to "string".

Concerning name and raceName... Will ever a computer program have enough common sense to differentiate two such strings ?
At least, here, the standard is clear for human beings, for the computer, it ends up manipulating 2 strings, not 2 concepts.

Thanks for the replies up there.
I brought the specialized spells on the "negociation table" because you clearly separated domain spells from other prepared spells. Specialized wizards have a bonus spell a day from their school, it's quite similar to a domain spell. (I also have less business logic to implement if the specialized spells are clearly tagged as such. )

OK, I'll define Integer and Float; I might as well do it now.

I don't think there's any way to tell the difference between name and raceName, since new raceNames are added constantly. If it doesn't cause problems for the parser generator, I don't care, but I thought it might.

I'm going to go through it again to use the new lowerAlpha and so forth. Really, this is a tricky part - names starting with a lowerAlpha *are* valid (e.g. PC's emBroth). I'll have to consider which special characters should be valid. For now, how about upperAlpha, lowerAlpha, accented characters, ', and -. Can you think of anything else?

 

[jmettraux]

Really, this is a tricky part - names starting with a lowerAlpha *are* valid (e.g. PC's emBroth). I'll have to consider which special characters should be valid. For now, how about upperAlpha, lowerAlpha, accented characters, ', and -. Can you think of anything else?

Anything UTF-8 should appear in both lowAlpha and upAlpha (it includes orcish alphabet, but not the kobold one...)

For special characters, I can't think of anything more than "'" and "-". They are ambushing somewhere on our way.

integer: zero | (nonZero digit*)
float: integer "." digit
zero: "0"
nonZero: "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
digit: zero | nonZero

 

[CRGreathouse]

lowAlpha
upAlpha

How's this for the skills and feats section?

skillsAndFeatSection:
		"Skills and Feats: " skills "; " feats "."

skills:		skill (", " skill)*
feats:		feat (", " feat)*

skill:		string " " modifier ( " (" ranks ")" )?
ranks:		Integer
skillName:	upAlpha lowAlpha* ((" "|"-") upAlpha lowAlpha*)*
feat:		upAlpha lowAlpha* ((" "|"-") upAlpha lowAlpha*)* ("(" string (", " string)* ")")?

Allowed: "Alertness", "Combat Reflexes", "Blind-Fight"
Disallowed: "alertness", "CombatReflexes", "Blind-fight", "*^%^$^^$^#@"

 

[smetzger]

lowAlpha
upAlpha

How's this for the skills and feats section?

What about feats with a comma in the name?
How is a parser supposed to distinguish the difference between a skill and a feat? A feat could have a + in the name followed by an integer, how would a parser determine if it was a skill or a feat?
How do you designate the 'subtype' of a feat? ex Weapon Focus
What if there are two or more subtypes? ex skill related feats that give +2 to two different skills
How do you designate virtual feats? racial feats?

 

[CRGreathouse]

What about feats with a comma in the name?

Disallowed. This would interfere with parsing the feats, since they're seperated with commas.

How is a parser supposed to distinguish the difference between a skill and a feat?

It doesn't have to. The semicolon between the skills and feats should give it away.

How do you designate the 'subtype' of a feat? ex Weapon Focus
What if there are two or more subtypes? ex skill related feats that give +2 to two different skills

As a parenthetical note. That's why that portion is in the style guide.

How do you designate virtual feats? racial feats?

Racial feats are included normally.

Virtual feats, now there's an issue... I wish I had a quarter for every *page* I've written about virtual feats and their place (or lack therof?) in a stat block. This is ambiguous in the format itself and will have to be decided.

It's not an issue for the parser, but it's a major issue for the format itself.

 

[CRGreathouse]

I've made lots of minor changes and comments, plus a rewrite of the skills and feats section.

 

[jmettraux]

New version of the grammar :
http://cvs.sourceforge.net/cgi-bin/...rev=HEAD&content-type=text/vnd.viewcvs-markup
diff :
http://cvs.sourceforge.net/cgi-bin/...rt_samples/standard.ebnf.diff?r1=1.10&r2=1.11

The skills and feats section may be ugly, but it seems it's the best way to define it. Well done.

Charles, could you attach your new versions ? It will be easier for me to commit it. Thanks in advance.