[ d20statblock.org ] a grammar

At first, a supplication : please read the grammar before posting here.




hong said:
If your final objective doesn't involve making statblocks that are readable by computers, I still don't see why you need a grammar.

Not to mention that I also don't see why you need a statblock that's computer-readable anyway. As said before.

So Mr Hong, please enlighten us with your description of what a stat block should look like.
Please, don't forget all the details you were happy to mention in your initial post. But please, do it in another thread.

EBNF is just a tool.
 
Last edited:

log in or register to remove this ad

jmettraux said:

So Mr Hong, please enlighten us with your description of what a stat block should look like.

"For examples of what a stat block should look like, see the following."

[list 3 or 4 examples]

It's good enough for a lot of academic journals, when it comes to telling authors how to cite a reference. It should be good enough for a statblock.


Please, don't forget all the details you were happy to mention in your initial post.

These details are not part of a statblock, and I'm pretty sure they've never been.

But please, do it in another thread.

No.


EBNF is just a tool.

Of course.
 

hong said:
"For examples of what a stat block should look like, see the following."

[list 3 or 4 examples]

It's good enough for a lot of academic journals, when it comes to telling authors how to cite a reference. It should be good enough for a statblock.

http://www.d20statblock.org/standard/d20standard.html

We've done that, but it's not enough. I get many emails asking about specific nuances of the format, often the same minor aspect over and over, but sometimes a new feature I'd never really considered.

This is just the next step in a process for us.
 



CRGreathouse's question on another board got me looking at this. I think it is a good idea to have a standard format guide, but the restrictive way it's implemented seems excessive.

For instance, should we restrict string to a particular character set? Does that add something useful to the grammar? Sure, you need to keep out non-quoted delimiters, but why rule out, say, feat names like "Rock & Roll"? Another problem with the way this is done is that you haven't defined a character set. Very commonly, non-American platforms (even in English speaking countries) and even many older US computers will use different code pages from Latin-1 or alternative typefaces for localized encoding. If one of those is being used, you might be excluding half the alphabet and including any number of punctuation elements.

Also, if you do use UTF-8 (as someone recommended, and it's not a bad idea), restricting your characters the way you've done it will utterly hork with the encoding system. The only safe way to filter UTF-8 with single byte characters is to allow all 8-bit characters with the MSB set (see http://czyborra.com/utf/).

Personally, as an ex-software internationalizer, I would be inclined to recommend against any restriction on the makeup of strings besides what you need to avoid delimiter conflicts, which as far as I can tell excludes only ',' and ';' (and perhaps '(' and ')'). Maybe creating a field to indicate the character encoding would be good, but I think it's best left to the applications programmers to decide what they want to their apps to do with like Latin-4. Pass it through, don't mess with it if you don't have to mess with it.

Similarly, the capitalization restriction is unnecessary and potentially interferes with localization of the format. Many languages don't even have letter cases, and virtually all of those that do have different capitalization rules from English. Plus you again run into the problem that Ï in Latin-1 may not correspond to the capital of ï in a random character set.

Also, should type be restricted? If this is a general d20 format, I think it's safe to say there's a good chance that somebody with some d20 setting will want to use a different monster type someday. Same goes for Elemental subtypes. Dust, shadow, steam elemental, I've seen those in many contexts

It might be best not to wed the format to the 9-point alignment system either.

As a general rule with something like this, it's usually best not to restrict the options for the various fields any more than necessary.
 

Tarchon issued a nice piece of advice, thanks ! :)

We are perhaps losing ourselves with all these character sets.

We could step back a little (not defining "string") and leave those refinements to people that really want to generate parsers.

Our grammar should keep the focus on complementing the style guide. We could consider turning the grammar into a real parser generation grammar as a 2nd project.
 

I want to make something clear: This style guide is the English style guide. If it were not English, it would not include terms like "Skills and Feats" hardcoded.

The special characters are there for two main reasons:
* Many people play D&D using English for the rules and their native/preferred language for character names, etc.
* Many native English speakers use 'exotic' characters to make their names 'cool'.

I think that making style guides for other languages would be useful, but my command of foreign languages isn't great, I don't own a translated copy of the PH, and I think a native speaker would do a better job in all cases.
 

CRGreathouse said:
I want to make something clear: This style guide is the English style guide. If it were not English, it would not include terms like "Skills and Feats" hardcoded.

So let's remove accents in the grammar ! Simplification is good.

(My PHB is a french edition ;) )
 

jmettraux said:
So let's remove accents in the grammar ! Simplification is good.

It's as I mentioned - many English (American?) speakers like the 'exotic' feel of accented or Old English letters.

jmettraux said:
(My PHB is a french edition ;) )

How many of the hardcoded terms would have to be changed to make a French version? Obviously "skills and feats", but what about "Init", "Spd" ("Vit" sounds wrong, somehow), etc.?

I'm mainly just curious - though it's quite possible to make 3 versions once the main one's done (English/French/German).
 

Remove ads

Top