NPC Organization Best Practice? Multiple Lists?
 

I watched Ken Shaw's video on organizing Realmworks and liked the way he was using cast lists to contain NPCs for a particular region.

So an organizational question for those of you who've already tried out a few methods.

Case: A given list of NPCs part of an organization (Military Outfit) and some of those NPCs are also part of a ship's crew which may change over time.

How best to represent this?

I started out with a Nested cast list for the crew underneath the Military Organization cast list.

<Band of Brothers>
|
--<Ship of Fools>
|
--Bob
|
--Fred

I know I can also use relationships to do some of this. But I wonder what is easiest to see and manipulate?

Containment is generally intended for fairly-permanent assignment.. geographic things like River A is on Continent B. Transitory things like memberships are recommended to be represented via Relationships (such as "Contains" type for "Organization/Member" pairs or "Residence/Resident" pairs).

So in your example... I would not use Cast Lists for the membership of the military organization or the ship's crew. The cast list might be "Adventure 1 NPCs". The "Band of Brothers" would be a "Group: Military" with each NPC having an "Organization/Member" relationship to it. Likewise, the "Ship of Fools" would be "Ship of Fools Crew" topic of the "Group: Other" type (unless something more specific fit), and again, the relevant Individuals would have an "Organization/Member" relationship to it.

Naturally, recommended practices are just that: recommended, not required.

The virtue to relationships is that there is a specific view that can be used to show the connections by type.

For my own uses, I place Individuals under Cast Lists for the most part, but significant NPCs are located where the PCs can most expect to meet them.. often in their adventure site "rooms".

It's almost always better to use a cast list where an NPC lives rather than grouping the NPC under the organization they're a member of and to use relationships to indicate membership. First an NPC could potentially belong to more than one group but can be contained by only one topic. Relationships have no such constraints.

I know it can seem quite "unnatural" to do things this way but the more you use RW for running games, at least IMO, the more you'll find it helps you find things on the fly.

Best practices really ends up being how you expect to find things.

By the time I read the 'best practices' guide - I already had a good 1400 topics in my realm. What I found was interesting - the first couple of attempts at getting things in were a bit chaotic - but once I found my 'style' it's been consistent - and without having to read the document I was already doing 90% of the 'best practices'.

A big one for me I don't do?

'Cast list' - can't stand them - they ruin my focus, and give me the OCD skin crawl because the NPC's aren't where they belong. I feel like Zeus from 'Clash of the Titans' (the Harry Hamlin version) and the NPC should be where I want them to be....

/shrug - to each their own - if it 'feels' right for you when you go looking things up - then you know it's working.

Putting NPCs where they belong is an oversimplification for a world with any verisimilitude. Take the proprietor of a store who is lucky enough to have a home not attached to the store. Where does he belong? The store? His home? The tavern where he spends every waking hour outside the store to dodge his shrew of a wife? The brothel he frequents for the same reason?

NPCs in a single location yield unrealistic worlds.

Maybe there is a need of new snippet type (or maybe something exists and I am am not aware of it).
TABLE OF RELATIONSHIPS -
A table (as in text not as in database table) that in one column gathers all the relationships of the Topic (sorted by type?) and allows some other columns.
a) probably the notes that go with a relationship
b) maybe a percentage or times for location relationships
c) why someone joined the organisation he belongs to

this info can be kept even when the relationship is no longer active as an historical record.

I know that all this is in the "Transition Pane" (had to look up the name in the manual ;-) but a table with some additional data could be helpful in the various situations described above.

Nothing you said makes any difference in how I place my NPC's.

They don't make sense to be in a blob, because that makes it harder for me to remember at a glance where they 'live'. I'd rather make note of any of that information in the text for those locations - and if I needed to 'wing it' and have the players encounter 'the tavern owner from The Fox Hound' when they are in the woods - I can just expand 'The Fox Hound' instead of having to open the snippet to remember who that was.

I'm horrible with names myself and the visual placement is a help - having them all in one spot is 100% useless to me.

Then again... I did say "find what works best for you" only to be lectured about how I'm wrong. Here is a hint - if you think the NPC's all belong in the mechanics section under a 10 tier topic for each one... if it works for you that's fantastic. Don't get hung up on 'best practices' unless you want to sell your stuff in the marketplace. I do agree having a standard format for 'bought' stuff is needed even if *I* don't like it.

The relationship system certainly could use some improvements. I'm not quite sure what you're aiming for here that isn't already available from the relationship system as it exists now.

I want a better display system - having all the relationships on the Right pane is hard to follow and does not lend itself to adding local data to the relationship

If we can have a snippet under an NPC that looks something like:

Relationships (all are live links) || Relationship type Type || When likely to found here
================================================== =====
Home => found at => Between 23:00 and 06:00 and Weekends
Office => found at => Between 07:00 and 18:00
Pub => found at => Between 18:30 and 22:00

or maybe just a percentage value.

It will make the question of where to place the Topic, less of an issue.

Ok.

I'll add that to my list, I'm holding back all my suggestions for big feature changes till we see the CM. No point in asking for stuff till then.