Monday 16 December 2013

RPG Software and Semi-Structured Data

My work has me dealing with a lot of data. Customers send us data and we use our software systems to help us analyse it. Now there are two types of data customers send us: Structured Data which is easy to input into our software systems, and Semi-Structured Data, which requires some messy work on our part to convert it to Structured Data.

Now 90% of the data that comes in is semi-structured, which means that it's harder for us to plug it in to our software. Why is that?

Because computers only know how to work with structured data, while people can just as easily work with semi-structured data. Not only that, but keeping your data fully structured takes a good deal of effort, so most people don't take the trouble until they are forced to.

RPG Management Software

So what does this have to do with Roleplaying Games? Because there are all these Virtual Tabletop and Campaign Manager computer programs out there. They can help you manage your game, but on the other hand, they often force you to move your game material from semi-structured to structured. When they do that, they are incurring a cost on you in order to get the benefit the software provides. And sometimes the cost exceeds the benefit.

Just look at your character sheet. In most cases, you don't even need a printed character sheet. You can just write down your character on a cocktail napkin and play just fine. But then, when you need to put your character into the Virtual Tabletop, suddenly it complains that you didn't fill in your saving throws or some other field. Or you are playing a homebrew class that isn't supported. Or you have an item that doesn't appear in the master list of items.

I'm not saying that you can't write the software in a way to allow semi-structured data. But it's not the most natural choice and anyway many of the features you will want to implement may require you to impose structure.

So, next time you're writing or considering using RPG software, keep this trade-off in mind. One of the great things about Pen & Paper Roleplaying Games is that they can be run quickly and easily with semi-structured data. So when your software imposes structure, you need to ask yourself "Is it worth it?"

Well? Is it, punk?


  1. This issue is part of why I like Roll20 - there are data structures, and they can go pretty deep if you want them to, but they're generally optional. Which is nice, because I tend to work mostly with semi-structured data, too.

    As a software designer, I often have to explain to the programmers, who are basically built from structured data, that not only do people often not HAVE totally structured data, they also often don't WANT it.

    So remember kids, mandatory fields make Jebus sad.

    1. Cool. Thanks for sharing your experience on this topic. I should really check out Roll20

  2. This is why I'd make sure to have a basic underlying code, and then use scripting to write the rest, with areas for scripting custom code. Roll20 does this to a very good extent, especially since it's dealing with multiple possible systems.

    That being said, many softwares offer no forms of customization (which is very annoying when I want to include PHB2 things into D&D 3.5).

    1. Yeah, I was impressed by our Roll20 trial last night. I'd like to see shortcut buttons for common script element: it's always easier to edit a script than to write from scratch, but it was good.

    2. Well, you can nest macros. One thing, though, that I would like to see is the ability to write a conditional statement into the macros.

  3. If you want all that fancy stuff, I think you have to pay for "mentor" status.