Designer's Diary Articles
 

We've added a new form of "news" to our website in the form of a Designer's Diary blog! These articles will focus on tutorials, tips, tricks and other useful information on how to use Realm Works.

The first two entries are live now, go check them out!

Nice! I like this new feature. It is nice to have well-written, nicely laid out instructional material that doesn't require open a file in a PDF reader or MS Word. I'm looking forward to more Designer's Diary posts.

Excellent.

As a suggestion can we get some detailed information about the advanced import options with some test cases of the way we can expect the data to change based on the choices made.

I'm working on this stuff as fast as I can while still getting everything else done. :) Covering the advanced options is definitely one of the planned subjects, although it might actually end up being multiple articles. Coming up with material that is clear, concise, and not ridiculously technical is proving to be a lot more time-consuming than I first anticipated!

Mate as someone who managed it service desks for many many years and worked daily to improve the knowledge articles.. I really enjoyed the write ups :) they would have passed our QA checks.

Oh, and lest I forget, not a zillion pages long. :)

Ridiculously technical is ok if it is detail on the why or how of the process. The more we understand of that stuff the better we know what is and isn't possible.

"I have made this longer than usual because I have not had time to make it shorter." - Pascal

I have not yet used the export/import feature.

But reading these, you have made a complex undertaking simple and easy.
With a few mouse clicks!

Great work, on both the features and new instructions.

I've always seen that quote attributed to Mark Twain, using in the form of "I would have written a shorter letter, but I didn't have the time."

Time to hit up Google for some answers!

The next one is going to be really long, simply because there's a ton of stuff to cover. About three times the length of the initial two. Once you see it, let me know if it's TOO long. It COULD be broken up into multiple entries, but that seemed like more work, plus it would result in lots of folks not getting the complete details (i.e. those who only read part 1 and not part 2). I'll be interested to know what you guys think about bigger entries vs. multi-installment entries after you see it.

Note that the new long one is NOT intended to become the norm. However, there are a number of additional titles on my todo list that WILL be long. So I'm looking for guidance on how best to handle those in the future.

I anticipate that the new entry will be posted sometime on Friday, possibly late on Friday. Once it goes live, BJ or I will post an update here in this thread. So this is just a "heads-up" post for everyone. :)

Agree and disagree. The more technical it is, the more the techies will understand. But the more likely the non-techies will react negatively and feel that Realm Works is too technical for them. There are a zillion non-techies out there playing RPGs, so I have to be ever-mindful of that and do my best to cater to them as well. Consequently, I have to be as non-technical as possible, but I also have to be sufficiently technical to clearly explain the complicated aspects of everything.

It's NOT a fun dilemma to deal with, and everything ends up taking a whole lot longer as a result. <sigh>

Maybe the two can be combined.

Make a non-techie article.

Then inter-spaced within that article have some text boxes with gray background and write some technical/in-depth explanations, that are not needed to use the feature(s) in question.

Remember to make clear at the beginning that the gray text boxes are optional/not required and intended for those interested in the technical details.

I use this when making manuals for my instructors (they are not supposed to teach that which is in gray text boxes, it is for their in-depth understanding) and it works well.

Or just start the top with the low-technicality explanation, and provide a more technical explanation as a sub-section after that. It winds up being longer, but may be easier to manage overall.

Solid suggestions. I'm just worried that the articles end up:

1. Becoming much longer (and therefore "scary" to new users)
2. Have sections that all of us OCD gamers feel that we MUST read, even when we're told not to, which adds confusion
3. Take more time to both write and post with all the special formatting

So I'm also considering splitting them up into two articles, with one focusing on all the basics for everyone and a follow-on delving into the technical depths. Again, more work to write, but possibly a better approach with regards to less technical users. Even with theoretically simple stuff like this, nothing is ever easy. <sigh>

I for one would be happy for you to put your Magnum Opus on hold and push out the 5e changes instead, so I can get back to work entering stuffs for my campaign. :)

@BigSkyRPG: Rob is waiting for my birthday tomorrow. And then for the next business day. Sorry, it's all my fault. If it's any consolation, I agree with you but I totally realize we already burned our Luck stat last week to get weekend support. Rules are rules. Rob doesn't make then, he just enforces them....

lol:d

There's a new article up!

Making the Most of Official Content

I'm disappointed; Rob promised us long and wordy. :)

If these are going to be web pages here on the LWD site and not RTF documents downloaded with RW updates or some other way, then why not just add in some hyperlinks from the easy to understand to the more technical document? Just explain that we neophyte users don't have to follow the links, unless we want to be bored to tears. I'd split up the technical detail articles though so they are targeted to the specific part of an article from which the hyperlink came from.

I promised long. And I think I delivered. I hope it wasn't "wordy", since that means I rambled a lot, and I tried hard to make sure that didn't happen. :)

That wasn't long. We all read RPG books for fun.

I think you are hitting the mark with what you are doing and wouldn't worry about a two-level approach. The folks that expect this to be easy are not going to be (or won't remain after a brief flirtation as) your customers. Those who try it and complain because it doesn't read their mind and spew out a complete realm are not your target audience. GMs who will use this know world building is HARD and do not expect that a tool to do what they envision is something their pre-schooler can sit down at and immediately employ (not saying there shouldn't be an effort to make the features approachable, of course).

And the ADD generation is not your audience. If a long article scares someone off, they are never going to sit down and build a realm. They might buy RW to use content, but they won't use most of your program and will likely never go to the manuals, the sites, or anywhere but here to ask questions like "I searched here but I cannot find my problem - how do you create a new topic?"

So, I noticed in Designer Diary #3 that the statblocks presented at the bottom of topics does not use the "Statblock" snippet type. Could you elaborate on why this is considered a best practice?

An additional click is required to see the data, and you then have to navigate back to the original topic to continue with that particular encounter.

So what is official use of stat block?

Deleted

Never used it...

I actually use it for the sole reason that it is hidden. I put the "important" stuff from a statblock/NPC into individual snippets in the article/topic. Then I past the full statblock into the statblock snippet. This allows me "IF" I need something to get to the full information. But 99% of the time I don't need it as I have another tool that runs my combat (not-HL). This allows me to have the information I think is important at a glance or "ALL" the information a click away if I need it.

So in that way I like it. :)

We determined that statblocks really didn't offer anything of substantive value and had some drawbacks. As mentioned above, they require the user to make extra clicks to view them, and we found that less technical users would simply click on them instead of loading them into a separate tab, which forced the user to switch back and forth and incur the loading time for changing the contents of the tab. The additional drawback is that no linking can be performed from within statblocks. By putting the statblocks in a snippet that is auto-collapsed in the topic, the information is readily accessible, doesn't require navigating away, and can be fully linked.

Based on the above, the statblock snippet type is something that is available for anyone who wants to use it, but it's not something we'll be using in official content.

I was confused about the statblock snippet as well, seeing that HeroLab essentially IS a statblock. Was the statblock snippet originally designed for some other type of software?

Not all game systems have HeroLab support.

I suspect that what Rob is getting at is that the StatBlock snippet is something that sounded good in planning.. but proved not to be quite so good as expected when actually used.

Not all users also own Hero Labs.

Right, but I was wondering if there was going to be compatibility with other types of software or it would just have been for images/blocks of text. Either way, it's a bit of a moot point. :)

I get this. I've always been a little confused by the need to have a character topic and then a separate statblock screen for the same character. I ALSO get that sometimes you just have a one-time NPC that only shows up in one place and so they need to just show up in the topic where they "reside."

Having said that, there are a couple of other situations that I'm curious about in terms of the suggested best practices. They are...
(1) Major NPCs (which the diary and CSGs partially address), and
(2) Generic NPCs ("Monsters")

The Generic NPC category includes anything that is not unique in its identity, but ubiquitous as a category within the gaming system, in which all elements share the same statblock. Goblins in D&D, Stormtroopers in Star Wars, etc.

Two questions about these categories:

(1) Do these these types of NPCs show up as a stat block in every encounter where they appear? This seems very redundant to me - probably better to just the encounter off multiple tabs instead.
(2) Should the statblocks in the individual topics for these NPCs also appear in the Additional Details section? Or should they show up somewhere closer to the top?

Thanks, Rob. That makes sense.

I think I have partially answered my own questions, now - I see that each system has statblock data for the generic NPCs/creatures/monsters, etc.

But I still have one question that I can't figure out - when you have that Important NPC (say, the Big Bad for a multi-session campaign) that has his or her own topic, where should the statistics for that NPC reside? Is there a suggested practice for that?

In my first 3 adventures I wrote a lot of stuff into the scenes. I will try in my next one to keep it much shorter. Just the necessary bulletpoints enough to understand the tasks at hand. The scene topics will not contain statsblocks since i use a combat tool were i load those stats. However statsblocks are added for each npc / monster. Via the participants section i could open an npc relatively quick to check his / her stats.

For an NPC like that I build a full HL portfolio and save it as snippet in the NPC's topic. I can pretty easily add it to any encounter I need from there.

For systems that don't have HL support, I'd do roughly the same thing. I'd put the NPC's full statblock in the NPC's topic.