![]() |
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.
|
Quote:
|
Quote:
|
Quote:
|
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. |
Quote:
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. :) |
Quote:
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> |
Quote:
|
@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....
|
Quote:
|
|
Quote:
|
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.
|
Quote:
|
Quote:
|
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?
|
Quote:
|
So what is official use of stat block?
|
Deleted
|
Quote:
|
Quote:
So in that way I like it. :) |
Quote:
Quote:
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. |
Quote:
|
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. :)
|
Quote:
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.
|
Quote:
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.
|
Quote:
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. |
All times are GMT -8. The time now is 02:45 AM. |
Powered by vBulletin® - Copyright ©2000 - 2024, vBulletin Solutions, Inc.
wolflair.com copyright ©1998-2016 Lone Wolf Development, Inc. View our Privacy Policy here.