Long ago, GreyKnight wrote The Post To End It, a bit of fun about what goes into my writing a blog post here.
He almost absolutely nails it. ‘Paragraphs appearing’ being 5d20 is a bit of an exaggeration, maybe, but the rest of it is spot on.
The last table asks “Did everything turn out as expected?”
Yet again, the answer is “No, and that’s awesome!”
Up to now, I’ve been drafting the domains as their own entities in the document. First I expected two pages per domain, then found half a page would probably be enough, and then it looked like a full page, then pushed back out to two pages. Fine. That happens when I’m learning what the content should look like.
Then I thought about how I expect the domain aspects to be applied: look at the options for each field and see if anything jumps out as a good fit, especially in combination, but you have the option of rolling if you want that extra variability.
Having each domain be on a couple pages (likely a spread) makes this a little awkward, so I wondered if I could put each field on its own page, and the reader can just go field by field. I’d still have the original spreads, this is more of an appendix.
I’m thinking… maybe. But a good chance not. I have 35 domains and the layout mockup shows this fits on a single page if each entry takes only one line. There’s room for a small number that go to two lines, but that’s it. I might still do it, but I expect I’d have a mix of single page and spreads to deal with, and that’s okay by me if they line up the way I hope, but not if spreads end up going overleaf instead. (I can of course add filler pages, but that feels a bit off to me; I’m keeping this option in my pocket.)
There is an option that I can readily accept, though: make a workbook. A Excel file that has all the tables, and the user can use filters to show the bits of interest. I’m thinking of the following column, in no particular order:
- Field order index (so you can put them in the order they appear in the template.
- d66 roll to help pick domains.
- Doman name.
- Field name.
- Field roll (what die to roll to randomly select a value.
- 20 columns to hold values; only cells with values to be populated (i.e. if the roll is a d8, only the first 8 cells are filled).
I might include only abbreviated content, though. For instance, in ‘Color’ I don’t say why these colors (I do in the book), and I can see other abbreviations happening down the road. This is intended to be a tool, not a manual.
I’ve prepared a draft copy with just the Knowledge domain populated. It’s… industrial. Not the prettiest thing I’ve ever worked on. But it looks like it will work.
With six domains shown and the entire set of ‘Quest’ fields it still fits on my screen (thank you, 4k!). Five of the domains are basically unpopulated here, but I’m looking primarily at the footprint.
All in all, I’m pretty happy with it. I expect most of the time I’ll only need to see the first 10, sometimes 12, columns. I’m not making a lot of 20-entry random tables here, at least so far.
I suspect I might want to band the fields, though, give fields different colors. Or something; I can see that having multiple domains visible at once, it could become difficult for the user to read them clearly. Or I could leave that up to the user to manage. I think I’ll leave it up to the user.
Closing Comments
It amuses me sometimes, how often I end up creating something I didn’t plan to, or even anticipate. I think this particular workbook will be a very useful complement to the book: it gives the user the ability to slice and dice the elements on the screen however they want, and it captures the functionality of the book without replacing the value of the book.
I recognize also that this puts the ‘data’ of the book into a data-driven format, in a way that it could be easy to transform into other formats or consume by other programs. I am more than okay with this.
I might still put the ‘field tables’ in the book, but I have the feeling this workbook will be much more useful.