SDM Design – Presenting Data is Hard! (4/4/2015)

data modelThe Question

Where do you put a stat block for a creature that appears multiple times in an adventure?

  • The first place they appear?
  • Every place they appear?
  • At the end in an appendix that has all the stat blocks?
  • Some mixture of these?

The same is true for their background. If a monster/place/character is mentioned in one location, but it’s really prominent until they appear another, should you?

  • Make a page reference to them?
  • Duplicate the information?
  • Present the information in bits and pieces (some one part of the text, some in others)?

These aren’t simple questions to answer, nor are the answers the same for every reader.

Example – Reading the test before the adventure:

If you’re reading the text before running it, you’ve got time to do extensive page skipping. It’s this case it’s nice to have all the text linked to each other but not duplicated. The flow is natural and you get all of the story in one place.

Example – Referencing the text during game:

When I’m running an adventure the LAST thing I want to is be flipping pages or clicking links to skip around. I need to know all the info for my location and everything in it all in one place! Here it doesn’t matter how many times data is duplicated because at any given time I’m just looking at one section and I want it all right there in front of me.

Example – Looking up related data:

If I remember there is a bunch of NPCs or monsters, or special items, and I want to get a list of all of them, then what do I want? Certainly not to have to flip pages or do a ton of related but not identical searches. Now I need an appendix that has them all together. And ties them together in the grouping that suits my needs RIGHT NOW.

These are super tricky to balance in any game text, adventures in particular. You might be using monsters in multiple locations and for sure those stat blocks are handiest when they are present because they are needed while the game is being run. But page counts is a consideration. The longer the doc the more expensive it is to print (if you’re printing it) and the slower it is to load, index, scroll through and search as a PDF. Also, data duplication can be dangerous. What if your monster has one set of stats in one area, and another in a second area. Say…skeletons equipped with sword vs. skeletons equipped with battle axes?

The trick is that our brains are too smart for our own good. We love patter matching and will sometimes do it as long as something is mostly the same. So adventure designer might have included three stat blocks for those skeletons, but the GM might very well use the first one they find and not even realize the difference. Frankly, pages and pages of stat blocks all start looking the same to me if I don’t have art to break them up.

Advice

This is pretty untested. I speak more from someone who has read/run adventures than someone who has written them, but here’s my thoughts:

  1. Kill trees, spill ink, take all the bytes. Boring as it may be for your prospective reader to see the same information multiple times, as long as there is a clear flag they can skip it (such as a stat block that looks just like the stat block they just saw) the reader doesn’t mind seeing the same data multiple times. In turn, when they have a page up during the adventure they will thank you profusely for having it all in one place.
  2. You talk too much. This is more me than you. Stone Dragon Mountain is currently 71 pages in a Google Doc. It’s 25,000 words and I haven’t even finished it yet. Damn! I really go on an on about some things. Think of your descriptions like a tweet. Write the whole thing, check your word count, then start cutting and cutting until you get it down. This has to do with sentence structure, with clarity, and with leaving room for the imagination. You don’t have to lead a GM by the nose and put all the pieces together for them Sean!
  3. Boxes! Boxes are great. Boxes let you put a little bit of text (under a header so everyone knows what the text is all about) in a box that can both be easily skipped and found later! You’ve got a new magic spell that a Magician or Ranger can learn in your game? Put it in a box. Until they want it the GM can easily skip over it. When the GM needs to find it, it catches the eye easily.
    When I say a fish made of gold you think I'm full of crap. When I show you this picture, you reach for a fishing pole!
    When I say a fish made of gold you think I’m full of crap. When I show you this picture, you reach for a fishing pole!
  4. Include page references and links! Yeah, it does get old to say “see page XX” but it gets even older to be reading your adventure and say “where the hell is that page!” In digital formats you can link them together but don’t assume someone hasn’t printed out your adventure and is running it off paper. Page numbers.
  5. A picture is worth… A LOT. Art does so many things. It brings descriptions alive, but it also serves as memory trigger for us. Where are Skill Factors in Torchbearer. When I’m looking at the digital copy I go to the linked Table of Contents (on page 3) and Click on Ability and Skill Factors (page 132). When I’m flipping through the book though, I just look for Gerald on the inside of a right page and know I’m next to Loremaster.

What do you think? Is there a better way to organize data? I know when I play Pathfinder I use d20pfsrd to look up EVERYTHING. Should adventure designers make easy to search Wiki’s for their products? What works best for you when you’re reading, running, or searching through and adventure?

One thought on “SDM Design – Presenting Data is Hard! (4/4/2015)”

  1. Lovely insight Sean. It also means that you care about layout and so your final product will be thoughtfully designed – it may not be everything to everybody, but it will be awesome.

    I personally always liked the removable ‘quick GM reference sheet’. That lists stat blocks and maybe the map? You know, like the old covers off modules that also doubled as a GM screen?

Leave a Reply

Your email address will not be published. Required fields are marked *

css.php