D&D Datahead Community, II

In my last post I discussed the goals of the projects I'm working on. Pushing on, this post is about the means I am using to that end.

A long-winded definition: game software means software written to support paper-and-pencil games, board games, basically any kind of game that requires a bunch of friends to get together, learn the rules, and muddle through a session on their own. In this discussion, game software isn't about computer games, even CRPGs, although certain CRPGS (NWN comes to mind) lie on the border between that space and this one, especially where their construction toolkits are concerned. In particular, game software will mean software that helps Game Masters--GMs--create, recruit players for, publish modules for, and run their games.

The idea at the center of this is that developers should be able to write software for their favorite games. Enabling them to do so shouldn't be hard. The game software community currently suffers from a lack of cooperation. The open source "revolution" just hasn't found this niche yet. Software publishers all seem to start from scratch, nobody writes frameworks or talks about best practices or forms committees. Nobody standardizes anything. Games software suffers and its developers spin their wheels.

Goonmill will be my first attempt to make a standard for something. Like a lot of standards, it builds on other standards. In this case, it makes use of N3, shorthand for Notation3. N3 provides a wonderfully extensible data framework for this initiative. So extensible that it seems to be completely about extensibility.

Suppose I publish a document like this:

:goldDragonYoungAdult
p:cr 14;
p:alignment c:lawfulGood;
p:size c:huge;

p:initiative +4;

p:hitPoints "20d12+100";
p:damageReduction [ c:magic 5 ];
p:armorClass 27;
p:immunity c:fire, c:paralysis, c:sleep;
p:save [ c:fort +17 ], [ c:ref +12 ], [ c:will +16 ];

p:speed [ c:ground "60 ft." ],
 [ c:flight "200 ft. (poor)" ],
 [ c:swim "60 ft." ]
;
p:bab +20;
p:grapple +38;
p:space "15 ft.";
p:reach "10 ft. (15 ft. with bite)";
p:melee [ a c:AttackGroup;
 c:claw (+29  "2d6+5");
 c:claw (+29  "2d6+5");
 c:bite (+29  "2d18+10");
 c:wing (+28  "1d8+5");
 c:wing (+28  "1d8+5");
 c:tail (+28  "2d6+15");
];
p:abilityScore [ c:str 31 ],
 [ c:dex 10 ],
 [ c:con 21 ],
 [ c:int 18 ],
 [ c:wis 19 ],
 [ c:cha 18 ]
;
.

I won't get into the subtleties of syntax here, just present the bare bones; if you're waiting to hear about the D&D stuff, bear with me one little bit more. The above is pretty readable and pretty easy to write with a text editor, as well, which gives it two marks up on XML. The document above breaks down into a number of subject-verb-object statements. On most of the lines above, you see only the verb-object part followed by a semicolon; this is because the subject in every case is :goldDragonYoungAdult. Semicolons separate two S-V-O statements with the same Subject, so each of the following lines needs to give only a verb-object. In a similar fashion, commas separate statements with the same Subject and Verb, so only the Object is stated for the comma-separated groups. () presents an ordered list, and [] presents an anonymous subject, so e.g. [ :foo :bar ] means "there exists some thing, whose :foo is :bar".

However, the important thing here is that N3, like all triples formats, describes a set of unordered relations. Unlike, say, a relational database which stores tables of strongly-typed columns with relations, N3 essentially stores only relations.

Why Does N3 Matter?

This has gotten pretty long--more tomorrow in Part III.