If you follow gaming at all, you know that the fourth edition of Dungeons & Dragons has been released. As I suspected, the rules are, essentially, the rules that govern a video game captured in book form. As I did not suspect, the result is actually pretty good. It’s still very crunchy (i.e. rules-heavy), but it is pretty well designed crunch, with a lot of design focus given to keeping what is fun and ditching what is not.

The effort is helped quite a bit by some interesting layout choices. In particular, their use of white comes as welcome change from their 3E design and somehow looks modern and slick. After years of role-playing products designed with ink on most of the page, usually with some kind of pale or gray image as the background, the open style used in 4E might change the way a lot of books get designed. I remember noticing the use of white in the gorgeous Ptolus and wondering why more RPG books didn’t use it. Fourth Edition’s color and font choices (mostly a family called Mentor) are also an interesting break from their past and, I think, well selected.

A few days ago, Wizards of the Coast finally unveiled their new Gaming System License (GSL). Not so good. It’s many shortcomings are being debated in forums all over now, but a thread on ENWorld is particularly notable, as it includes several publishers of 3E supplements using the Open Gaming License (OGL). Posts from a user named Orcus are worth reading, in particular, because he is a lawyer as well as a game publisher (Clark Peterson from Necromancer Games). Even though Necromancer’s page currently claims certain products will be ported to 4E, this forum indicates that at least some of the books mentioned (something called the Tome of Horrors, in particular) will not be, now that the details of the license have been unveiled.

One of the main issues is what some are calling the “poison pill” clauses (even though it isn’t really a classical poison pill). Essentially, it makes converting a “product line” (whatever that means) from the OGL to the new GSL a one-way process, and contains language that essentially would put a publisher’s future into the hands of Wizards of the Coast. I’m not a lawyer, but from how I read the GSL (PDF here), it seems to me that publishers would be fools to sign it as it is presently written, particularly if they already have created OGL content. It also pretty much shuts down any fan-based computer tools, like character trackers, reference tools and the like (though there will supposedly be a “fansite” related policy released later).

So, unless the license is changed, you can bet that not many publishers are going to fully embrace it, though many will probably make a few books for it. I’m guessing that most of the following will occur:

• Well established product lines (that is, those who could claim a measure of brand recognition and loyalty) will continue to publish these lines under the OGL. They will eventually be forced to remove the d20 logo from them, but it will probably not matter.
• Well established companies, if they publish for 4E at all, will do so with entirely new product lines. They will be able to leverage their name, but not their brands.
• A few new companies will arise that make only 4E products, but will focus more on adventures than anything else. At least one of these companies will, in fact, be owned by another established company that is still publishing OGL-only material.
• After realizing that the GSL won’t let it follow its current plans for 4E integration, Pathfinder will remain 3.5, and will become something of a flagship product for those still using the OGL, mutating into the semi-official mechanism by which the 3.5 rule set evolves.
• Because of this, friction will be created between Wizards and Paizo, Pathfinder’s publisher. Since Paizo has a very close relationship with Wizards, the result will be that Pathfinder will be sold before the year is over.
• More than half of newly created companies that enter into the D&D related publishing business will publish under 3E rules using the OGL.
• The amount of shelf space given to 4E products in gaming stores will not exceed that given to 3E products. Ever. In Borders and other large book stores, however, you won’t be able to find 3E products at all.
• Numerous fan sites will emerge that convert third party OGL content into 4E. They will be constantly under threat from Wizards of the Coast, who will pay a lot of legal fees to continually fight them as they shift around.
• Wizards will become more vocal about copyright infringement on p2p networks.

I’d love to see some other open source game take off in the wake of GSL backlash. Unfortunately, if this happens, it is likely to be Pathfinder, rather than a better system, such as FATE (also available under the OGL license) or Wushu Open (released under the Creative Commons). Even more unfortunately, there aren’t that many other viable alternatives. There are certainly a number of free RPGs out there, but few of them are open source.

Popularity: 5% [?]

For the next month or so, I’m running a d20 game for a couple of players who have never played it before. They both play spellcasters, and to get them familiar with their spells, I thought I’d create “spell cards”, which list each spell on a little card that they can use during play. Sure, I could spend six bucks on a spell card PDF to print out at my own expense and cut with a paper cutter, but why, when I can spend ten bucks to buy Avery® business cards and build the output myself. Never let good sense get in the way, I say.

This post acts as a how-to describing how you can build such cards yourself, should the muse strike you. More generally, it demonstrates how you can use two different but complementary XML-based technologies (XSLT and FOP) to format output for Avery business cards, mailing labels, etc. from an XML data source. An assumption is made that you know what XML is and have enough technical chops to install and setup the various technologies involved.

Formatting Objects Processor

The Formatting Objects Processor (FOP) is a free, cross-platform technology from Apache. It claims to be “driven by XSL formatting objects (XSL-FO)”. All this really means is that it makes use of a specific XML format called XSL-FO, which is built to represent printed page layout. FOP can read in this format and render it into a wide variety of output, including text, PostScript and the format we’ll be using here, PDF. The XSL-FO standard has enough in common with HTML that its basics are fairly simple to pickup if you know that language; however, it is more complicated and much more accurate, capable of millimeter-level control over the output.

In principle, all you need to to use FOP is a source file written in XSL-FO markup. Nearly every demo you’ll find on the web uses the same mechanism of generating this source that we will (XSLT, see below); however, FOP really doesn’t care where it comes from. Keep in mind that it’s just an XML file, so you could just as easily, say, build the XSL-FO with a Perl script or even by hand. Typically, you will also have some source of data in hand, such as a database or text file. In our case, we have some XML data in a totally different format.

The d20 Standard Reference Document in XML

The d20 game uses a (mostly) open standard, based around the d20 Standard Reference Document. Fortunately for us, an enterprising soul named Andargor has gone through the trouble of translating this SRD into XML and some other data-based formats. His XML files use a fairly straight-forward format of his invention. This format, of course, is pure data and nothing like the XSL-FO layout format. Nor should it be. So, what we need is something to translate the d20 XML into the XSL-FO markup describing the page layout we want.

Extensible Stylesheet Language Transformations

Many paths exist to convert the d20 XML into XSL-FO. Python scripts, Java, heck even sed. We’re using a technology meant to transform XML input into some other kind of output (usually XML, HTML or text) called the Extensible Stylesheet Language (XSL). XSL is yet another special XML format geared towards matching XML data and transforming it. (It is, believe it or not, turing complete.) It makes heavy use of a standard called XPath, which is a funky query language for specifying exact subsets of nodes within an XML document. Though XPath looks nothing like SQL, it is similar in purpose, except querying a hierarchy tree instead of relational tables.

An XSL transformation (XSLT) is specified in an .xsl file. Typically, such files are very specific, written exactly for the combination of data type being transformed and output format being written. That is, the XSL file we use here is specifically for turning the d20 SRD XML format into XSL-FO formatted for Avery business cards. If you need to change either end of this, you should make a copy of the file and mutate it into a new transformation that does what you need.

Tools

We need some kind of tool that allows a two-step workflow (or knows how to combine the two steps into one). First, we convert the d20 SRD XML data into XSL-FO using XSLT. (That’s a lot of acronyms.) Second, we take the result of that and feed it into FOP to build our PDF. The four files are involved are:

1. spells.xml - The d20 XML data containing all the spells in the SRD.
2. spellcards.xsl - The XSLT to do the translation into XSL-FO.
3. temp.fo - The XSL-FO generated by the transformation.
4. spellcards.pdf - The final PDF file.

A number of tools exist to do this. I happen to use oXygen, as it combines everything needed to run this process into a single step, and also functions as a very good XML and XSLT editor. It’s a powerful tool, but pricey. Stylus Studio costs even more. Some less feature-rich alternatives might be TestXSLT. If you want to go the Java route, your best bet is to download the recent FOP package, which contains the Xalan XSLT engine and a command line to use it. If you know of other tools, leave a comment with a URL.

Steps

Once you have the tools picked out, download the XML d20 SRD and find the spells.xml file. Now, take a look at the transformation file. It is fairly well commented. Save a copy of it to your local drive as your spellcards.xsl file. Now tell your tools to use spellcards.xsl to transform spells.xml into temp.fo, then channel it into FOP.

If using oXygen, do the following (note, there may be some changes between versions of oXygen, so this may not be exact):

1. Open the two files.
2. Make spellcards.xsl the active document and select the menu “Document → XML Document → Configure Transformation Scenario”.
3. In the dialog that comes up, click “New”.
4. Name the scenario “spellcards” or something similar
5. In the dialog’s “XSLT” tab, set the “XML URL” to your local copy of spells.xml. You should be able to leave the other settings alone on this tab.
6. In the dialog’s “FO Processor” tab, check “Perform FO Processing” and make sure the “XSLT result as input” is selected. You want to use the “pdf” method and the built-in FOP.
7. In the dialog’s “Output” tab, click the “Save As” radio button and provide a place to save the spellcards.pdf file. Click the “Open in browser” checkbox and the “Saved file” radio button.
8. Click OK to close the dialog.
9. Back in the “Configure Transformation Scenario” dialog, you can click “Transform Now” to test out your settings.
10. Hopefully, you should be looking at a PDF now. If you need to run the transformation again, you can hit the big red “play button” toolbar icon (which is called “Apply Transformation Scenario”).

If you are using the command line tool that comes with FOP instead of oXygen, the command you need should be something like this:

fop -xml spells.xml -xsl spellcards.xsl -pdf spellcards.pdf

Printing

Once you have the PDF created, make a test print of one of the pages. Put this page behind one of the Avery business card pages and hold it up to the light to see how it lines up. Every printer feeds slightly differently, so you may need to tweak the measurements slightly to align the cards just right. You do this by altering the spellcards.xsl file.

Search this file for the word “tweak”. You’ll find a couple, which identify spots in the file that measurements can be altered. One place is the margins for the whole page. The other is the padding within a table cell. Adjust these until your test page lines up with the Avery labels. Once this all works, print out a test page on the Avery label paper. Hopefully it will still match up. If not, tweak again. Once it works, print them all.

Note, the measurement tweaking locations (as well as some nearby tags) within spellcards.xsl can be altered more radically to support other types of Avery pages, such as index cards or mailing labels.

Filtering

You may not want to make cards of every single thing in the spells.xml file. You can use different XPath statements within the spellcards.xsl file to select subsets of the data. There are two logical places to do this in the file, both of which can be found by searching for “filter” in the text.

The primary location is the select of the main apply-templates tag. In the file, there are a half-dozen or so alternate examples for this statement that you can use. Just comment out the first one and uncomment the one you want. You should be able to find a statement close to what you want and alter it to taste.

For more exotic filtering, there is a very slim chance that you what you want can’t be done in the main select. You can, instead, examine each spell as it comes through and make more complicated tests. The transformation file contains a skeleton to do such filtering, but always lets everything through. You’d need to change this to set include to true.

Filtering this data is harder than it could be, because the level tag in the spells.xml file is a string that combines all of the level information into a single field, rather than more structured data. For example, if a line like:

<level>Cleric 6, Druid 6, Sorcerer/Wizard 6</level>

…was instead…

<level>
 <class>Cleric</class>
 <classlevel>6</classlevel>
</level>
<level>
 <class>Druid</class>
 <classlevel>6</classlevel>
</level>
<level>
 <class>Sorcerer/Wizard</class>
 <classlevel>6</classlevel>
</level>

…it would be a lot easier to do more powerful XSLT filtering and sorting.

Popularity: 6% [?]