D&D Datahead Community, III

(Jump back to Part I.)

In a database of typed columns in tables, you must have a single schema, hosted at one location. Someone must be gatekeeper of what goes into it, and how it gets extended. To be able to use the data, applications written for it must trust the gatekeeper. If something goes into it, it becomes part of all applications written against it, and an app developer can't reject that data without making special cases in the application (blacklisting). Worse, if something useful doesn't go into it, your application can never make use of that thing. Your application loses the freedom of choice; neither the application itself nor its users can decide whether to trust some data and not other data.

An application built on published documents of triples, however, can be written so that both the application and the users of the application can choose which data to trust, by choosing from the list of URLs that the application loads as its data.

This goes right to the heart of the Paper and Pencil RPG world. This is a world of publish-or-perish; companies must produce lots of supplements to the rules of existing games, or fail to make money. Players, meanwhile, do not have the wherewithal to buy all supplements everywhere, so they pick and choose which rules to buy, and which ones ultimately to use in play. Not all publishers are equally popular, not all suplements are equally popular. Some gamers play extremely old versions of the rules; some even adapt supplements of the new rules to the old rules (the P&P version of a backport). And, any GM worth anything has his own set of House Rules, which he writes down only for the benefit of the rules lawyer in his group. In short, the RPG world is information anarchy.

In order for an open source software community to form in this environment, some of this chaos must be reigned in so that GMs can make use of the software in the crazy scenarios that actually exist at every game table. And I do mean every one; I have yet to meet a D&D player who took the stock PHB/DMG/MM and played strictly by those rules and only by those rules.

Supplements at the Application Level

The solution lies in a format that lets anyone publish their own rules. N3 is the basis, not for tables, but for documents, and documents can be published by anyone. But, unlike the pages of the SRD, these documents are unordered. This lack of order actually becomes an asset in this context! Think about XML. In order to modify an XML document, you must parse it, insert your concept, and then re-emit it. This makes you a publisher of the entire set of facts the document is describing. Therefore, anyone who wants to build on the original document but include your facts, must derive from your document, and so on.

In the unordered N3 format, however, all new facts just go on the pile. They can appear anywhere, even on another webserver. They do not have to be accompanied by a schema. In short, they are an explicit genuflection to the information anarchy of P&P game publishing. If you want to write an application about my dragon, and include the fact that dragons have a caster level of 15, you don't have to republish my entire dragon, just publish this document:

@prefix cdd: <http://thesoftworld.com/2007/monsters#>
cdd:youngAdultGoldDragon :casterLevel 15;

There, now anyone who wants to use a gold dragon and include its caster level in the facts about it, needs only whitelist my document and your new one at the same time. The facts might be new lists of monsters. They might be new rules to apply to already-published monsters--even in a blanket fashion: you can publish a statement such as "anything which is a monster has 15 Time Points", and now they do. They might even be cancellation of some other whitelisted rules if, for example, you like some parts of one publication but not other parts. An app can load any of these documents the developer wants to load, even cache them so they don't have to be requested over the Internet, but include only the facts that the application developer wants to include.

Or better yet, the ones the User wants to include. Because now that we've established these documents should be published somewhere, an application can simply collect all the documents it knows about and present them to the user as a list; the user can now pick and choose which rules his creatures obey and which ones his creature ignores. The user can even type in a new URL, and the application will fetch that document and include its facts, even though it didn't know about it before.

Communities can vote on these publications, so they get "most popular" and "highest rated" rankings and can compete with each other. Any member of the community can publish material, and instantly see how his new monster or new rules plays with any other member's stuff.

Next Steps

The technology, and in particular the standard, are only half-finished here, but they have a real application that needs them, which is Goonmill. Goonmill is far more than half-finished; in fact, I've already partaken of its delicious dogfood, and used the statblocks in my own campaign world. So I'm really not far from being able to publish real standards. But already there are some documents online that yearn to be pounded on by brutal application developers until they do something sensible. I am hosting them in what should be their permanent home, so developers will be able to link directly to these concepts and make use of them in their own applications.

1. For Goonmill to continue, I now get to undertake converting a SQL database made from the SRD, into a series of N3 documents representing the same concepts as triples. For monsters, the vast majority of the work has been done in Goonmill itself. Converting monsters is simply a matter of rendering all 650-ish of them to N3 instead of HTML, a labor which will eventually become monster.n3 at the above URL. Two of those files are in use by the application already, family.n3 and specialAbility.n3.

2. I'll then use the same process to convert all spells, skills, items and feats found in the SRD. When done, this will be a set of the core OGC documents, converted into a form that applications can easily load and understand, even access over the Internet. I cannot change the license they are published under, which is the OGL, but the OGL is a license that grants freedoms, not unlike the GPL as applied to game content.

3. An archive form of the document standard will have to be brainstormed and spec'd out. This format should allow us to zip/bundle N3 with a more prose-focused format like XHTML, so we don't have to crowbar a human-readable description of a red dragon into N3.

4. Tools will have to be written so game developers, who may not want to know what the inside of Vim looks like, can convert their content to the N3 format. But it need not be the publishers themselves who do this; any content which is OGC or CC-sharealike licensed can be easily converted by any fan of the material. It doesn't even have to be an application developer, just someone with a website who can publish mime-type "text/rdf+n3". It also must be noted that one reason I chose N3 as my format was so that a person can create these documents without a fancy XML editor, and by learning only a modicum of syntax. (I was, and am still, a fan of the "YAML" syntax, and N3 is simpler to learn than that.)

Conclusions

When these initiatives get under way in earnest--and I am not waiting for anyone's help, this is a banner I will take up for my own sake if nobody else is ready to jump in yet--others can and will write applications against it, including the data and even the N3 markup itself entirely within their applications, or loading them from their canonical site directly. We will start to see the beginnings of actual cooperation among game software developers, and maybe an increase in the number of game software developers.

As important, though, is that game developers take the opportunity to publish their game materials using a new standard that they've never had before. If you are thinking about writing or publishing game content, talk to me about this format, because I want to give you all the technical help I can give. I hope to publish some of my own game material this way to kick things off, which is really more like a #5 for next steps, since people will want to see how this thing really works when they consider whether to get on board.