Organizing Data

[llothos]

I have had realm works for some time but not until recently have I started really looking into it since my Star Wars EOTE game has begun. So I started using it to input some minor plot points as currently I am running a lot mostly off the top of my head. I want to change that and have more prepared for a session and actually utilize this for more then just the GM side and actually make use of the player view.

When I load up RW and go into my realm you have the topics on the left (sources, people, places, events, etc) so I started building a few NPC's, some places and then under events is where I was putting my main story points. I created a main storyline and for my topic of that nights session I would do a quest and within that I put scenes.

My main overarching storyline name is Order 32 and session (quest) 1.1 The Droid and under that I have two scenes, first one being the setup for the job and the second the actual retrieval of the droid. Session 2 (quest) 1.2 Artifact again I have 2 scenes, first one being the setup for their next job and then the second scene is the Jedi Temple they will be raiding.

I also played around with the storyboard and put things in the order that the players would be doing things.

Anyway over the last couple of days I finally got the chance to begin watching the Gen Con videos and I still have to go through the one about utilizing during session and I noticed that their topics weren't always organized via the main headings (sources....etc) but by the actual topics created (for example I would put my jedi temple scene under the planet it's on instead of nested under the quest.
Using this method now I would presume you would use the storyboard to organize the flow of that particular session. Otherwise your data would end up all over the place, but I guess you could alternatively create the main storyline and then nest the locations within the quest which works fine if they are only part of that quest but for planets they could end up going back for various reasons not related to that plot element.

The way I was organizing the people was by their type (Nemesis, Rival or Minion) and then put that NPC under that particular type with references to them within the scene. The couple of NPC's I have created are intended to become eventual thorns in the PC's sides and could end up anywhere so I wouldn't think putting them under specific planet they were on would be best although if I end up having a specific NPC only in one location it could make sense to put them under the location. Yes I do realize I don't' have to stat out every single NPC so it would only be the "important" ones that I would do more then just a name.

I am considering inputting over time all the stat blocks for the various NPC types from the core books and that way if I want to pull up a stormtrooper for example I will have it right there. My thought would be to put them under the world Almanac and move them to the story if they were going to be needed but they would be available very quickly as apposed to flipping through book (players sometimes get nervous when the GM starts flipping through the book(s) and the more I get the more books I would have to flip through)

Sorry for the long post but I am basically just looking to see how others are doing it and I want to start making better use of the program and actually start utilizing in session more. I also realize there is no "right" or "wrong" way of doing this but some opinions/observations from others is still nice. Like one of the other posts mentioned it would be great if there was someway to have a basic tutorial realm you can import into your realmworks so you can see how they have done it.

 

[Farling]

It really is designed to have the data arranged how you want.

I've been putting in a Pathfinder adventure path, which is based on a sandbox theme, so all my encounters and locations are stored under the relevant part of the world in which they occur. I also have a separate set of sections for describing the main threat of the plot, including a storyboard for each book.

 

[Jaynay27]

It really is designed to have the data arranged how you want.

I've been putting in a Pathfinder adventure path, which is based on a sandbox theme, so all my encounters and locations are stored under the relevant part of the world in which they occur. I also have a separate set of sections for describing the main threat of the plot, including a storyboard for each book.

Sounds very much like what I am doing with Kingmaker. About to start input of book 6 (tonight).

Quick question though - how do you deal with topics/locations that have the same name? For example I might have 2 locations called 'Gate' that relate to 2 completely separate locations in the game world.

What I have been doing is setting up the location with extra information to denote the specific location of the 'Gate' (E.G the gate in jaynay's castle would have a topic name of 'JC - Gate') but I am sure there must be an easier way to do this. Maybe? Names are getting pretty cumbersome using this method.

On a related note (don't want to derail the thread too much) - how do you name topics to as to not give away info to the players? If the main topic is 'Jaynay's castle' but the players don't know anything about jaynay, will revealing the topic effectively give them information they may not have discovered yet (e.g player asking who is Jaynay?)

 

[MaxSupernova]

On a related note (don't want to derail the thread too much) - how do you name topics to as to not give away info to the players? If the main topic is 'Jaynay's castle' but the players don't know anything about jaynay, will revealing the topic effectively give them information they may not have discovered yet (e.g player asking who is Jaynay?)

You could name it "castle" with an alias of "Jaynay's Castle". When you reveal the main topic, don't reveal the alias.

 

[Jaynay27]

You could name it "castle" with an alias of "Jaynay's Castle". When you reveal the main topic, don't reveal the alias.

Well I did try that, but then I have conflicts with other topics labelled 'Castle'.

I thought the prefix identifier would separate topics that have the same name, but I still get a conflict warning whenever I try to setup a new topic with the same name as an existing topic, and generic names like 'Castle' occur way to often in adventure material
Linking then becomes a chore as you have to manually point to the new topic whenever the name come up again.

I even thought about making keyed locations an alias (For things like D1, D2 etc) but this also creates conflicts if another adventure has a location with the locations based of the same letter/key. (lots of locations in kingmaker have text such as 'stairs lead up to area D1' for example, so having the link work off the room keys is advantageous).

I dunno - am I missing something here?

 

[AEIOU]

@Jaynay: Not revealing info to players came up a while back.

One solution that sounded best to me was to have a "Castles" container with topics named generically like "Castle A", "Castle B", Castle C". In that main "Castles" container, create a table of all the generic names with a cross reference to their actual names.

Another solution was to use generic names for each topic and an alias of the real name. Since aliases are hidden until revealed, you can have both the generic and the real in your list.

In my current campaign, the first option would work best as I don't want the alias clutter. But in most situations I think the aliases are the way to go.

 

[AEIOU]

@Jaynay: Same names for locations.

I simply decided I don't care. Every location I create has a prefix ID and a container so I can normally figure it out at a glance. The only time it's a problem is if I want to create a relationship -- and for those instances I open another tab so I can check the topic's contents to ensure I have the right one. It's an annoyance but it's also pretty infrequent. I pick my battles and this one wasn't worth my effort.

 

[Jaynay27]

Thanks for the suggestions and advice

Even with these small issues I am really loving RW.
If I started from scratch now, I would probably do things a bit differently, but there really is no 'wrong' way to input data. What I have in RW will be sufficient and a vast improvement over previous methods of campaign tracking/management.

Once KM book 6 is in and the player edition is available I cant wait to launch the new campaign, with ALL the content literally there at my fingertips.

 

[AEIOU]

I was really pleased with myself on the work I did on RotRL many months ago. And then I turned my attention to a new campaign and abandoned that older work. Now I look back at that stuff and shake my head at how thrown together it seems now and I smile at how much more organized I am now with my new content.

My organization keeps evolving. I've spent the last few weeks reworking data that I'd entered over the last several months. Stat blocks and links to bestiary entries and tags, tags, tags. Tweaking where similar items go so they are consistent. Adding relationships. When next I start a new campaign, I'll definitely approach it much more systematically and effectively from the git-go. And I'll keep finding new things to refine.

@llothos: IMNSHO, the best tutorial available right now is the GenCon presentation on how to organize material for the marketplace. The talk was interesting but what I homed in on was how material was organized in RW in the screenshots. Why did they do it that way? Why separate lines for tags? Why sometimes a place and other times something else? Why are NPC's that way? Why, why, why? I was half-way through my first time when I realized I hadn't heard a word for a few minutes as I was totally focused on picking apart the logic behind how the data was organized. And I learned quite a bit. It's amazing the thought that has gone into each category, each snippet....

 

[Jaynay27]

I was really pleased with myself on the work I did on RotRL many months ago. And then I turned my attention to a new campaign and abandoned that older work. Now I look back at that stuff and shake my head at how thrown together it seems now and I smile at how much more organized I am now with my new content.

Wow - This sounds almost exactly the same as my experience. I started entering RotRL and stalled after book 2. Was kinda waiting for player edition, but at that time it was a bit far off and we re-organised our group etc, so I gave up for a while. Wasn't quite sure how to consistently enter the data for the whole campaign (shoulda probably read the manual and watched a few vids)

Having left RW alone for a few months and now coming back to enter kingmaker - Its like my brain was working out stuff subconsciously and I have flown through entering the content this time around. I could perhaps utilize the features of RW a bit better, but the content/structure is there and useable.

Anyway - Back on topic. I have found that the Alias system is the best way to handle locations for me (for now).

It would seem topic conflicts only flag for the main topic name and Alias linking is only a little more time consuming (in that you have to manually resolve link conflicts).

Currently entering generic names and identifiers (map or room keys) which should help avoid direct conflicts.

So I could have a topic 'House' in 1 adventure located at area 'A' and another 'House' topic in a later adventure at area 'K'.

I would then have 2 distinct topics as:

1. House - Area A
2. House - Area K

In the (unlikely) event of 2 topics of the same name being located in an area with the same 'Key' (location wise), I just add an additional identifier to distinguish the 2 (like adding 'SP' to identify the house in Sandpoint).

Of course the topics themselves are all in the right containers denoting where they are actually located in the game world, so this is all just for the auto linking to work things out.

Glancing at the left hand 'tree' structure is the easiest way to locate the actual entry I am looking for.

Currently I have gone with option of putting the description (from the published adventure) as an alias so there are no spoilers for the players. Shouldn't be too much trouble to re-work some of the earlier input to match the structure I am now using.

Thankyou for the suggestions - It has been a big help