Moving from InDesign to PrinceXML

I discovered this post in my drafts when I came here to post about changing my method again. I’m going to publish this for history’s sake, but as of the day I hit publish on this post I’m switching again, this time to using LaTeX.


I finally found a method for generating PDFs that fits my skillset: PrinceXML. This is a program that takes in HTML files and CSS and generates PDFs from it.

As I’ve discussed in previous posts, my workflow has me saving parts of my text for Binding World as individual files. I have one file for a magic item, and one file for a monster, and one file for the dungeon starter that contains both. That data is all compiled into JSON, then my page templates take in that JSON data to generate the final XML.

I used to be importing this XML into InDesign, and working on styling by mapping tags to styles. This seemed to work okay, but as I’m a web developer by trade I’m much more comfortable styling with CSS.

My new workflow has done two things. First, I’ve tweaked the XML generating step to include links to CSS files that PrinceXML uses to style the final product. Second, I’ve added some simple scripts to actually run the Prince compiler.

My new flow has me changing a file like stained_glass_dagger.md, which triggers a recompile of my game data into JSON, which recompiles my pages with that data into XML, which triggers Prince to compile those into PDF files.

New RPG Parser Structure

In the past I’ve written a tiny bit about my RPG Parser software that I use to store game data and insert it into templates and pages. I’ve recently rewritten it while I was working on playtesting character sheets for the compendium classes in Binding World.

The new RPG Parser code works in two parts: Data and Pages.

Whiteboarding the flow.

The Data Parser

Data takes all of the individual JS and Markdown files – each representing something in the game like a move, class, or tag – and puts them into a single gameData object that is saved as JSON.

Here’s the early stages of the file structure of the game data:

Folder structure of game data. Not complete.
Folder structure of game data. Not complete.

The file and folder structure is what determines where the data goes in the gameData object that the parser creates. All the information in game_data/classes/bloodbinder/index.js will be put into gameData.classes.bloodbinder. The .moves folder will ignore the folder they are in and go directly into gameData.moves 

Here’s the contents of the bloodbinder/index.js file:

The starting_moves and advanced_moves lists are all references to moves. The move data isn’t stored directly in the classes, but they are replaced with the full move data during the parsing stage so I can reference classes.bloodbinder.starting_moves[0].name to get the name of the first starting move.

The move files are done as markdown files for easy readability. When the parser encounters a markdown file instead of a JavaScript file it takes the first line as the name attribute and takes everything else as the description attribute. Later I’ll be added support for bold and italic text in the markdown.

The Pages Parser

The Pages parser takes XML documents that reference the game data with tags, inserts the real values, and exports them into multiple formats for InDesign, websites, GitHub, etc. The Parser uses the Mustache templating engine. I have a script for each output and am starting with the InDesign one. Here’s a sample page I’m working with:

A Pages XML file ready to be parsed into a usable InDesign file.

This file is put through the Pages InDesign parser and gives me this:

The output of the Pages parser with all the game data inserted.

What’s Next

Next I’ll be working on some basic InDesign printable sheets for the compendium classes of Binding World using these two parsers. Hopefully I’ll be able to do some playtesting with them soon. More upgrades will come to the software along the way.

Moving the GitHub Repos

I had initially written here that I would be storing the game information in a GitHub repo that incorporated a NodeJS website for display game data and a separate game_data folder with JS files for declaring the actual text of the game.

Screw that.

I’ve since moved the entire codebase to a new GitHub repo which you can find here. The game text is now written in simple markdown, and can easily be read straight off of GitHub. Anyone reading this can feel free to make suggestions for the project by making their own pull request.

The other system could still be implemented down the line, as the tooltips and data structure are quite useful. For now though it’s just a hindrance to writing the game. I find writing markdown easier, and I can make changes directly on GitHub’s website.

I’ve already made further changes to the game after copying over what I’d written on this blog. You can see the changes in this list of commits, but I’ll be writing about them in detail in future posts.

Vinquisition: The Codebase and Project

Technology Used

Part of the reason I wanted to start this project was to brush up on my NodeJS skills. As such, I’ve written the game into a Node project that runs as a website. The website uses:

  • NodeJS
  • Express
  • AngularJS
  • Bootstrap

I am currently hosting it on Heroku at http://vinquisition.herokuapp.com because it’s so easy to set up and share with people.

Continue reading “Vinquisition: The Codebase and Project”