I think Filters will work best for you. The filter itself is a simple technology in the Contents compile option pane, whereby you can tell the compiler to include or exclude items in the Contents list, based upon some key piece of meta-data, the binder selection, or a search result.
Which is the best piece of meta-data is a question probably best answered by you, as it will depend on how you prefer to work but I think the Collections feature will be best for what you need, unless you are not really using one of Status or Label fields in your project. If you do not track document status, you could co-opt that drop-down and use it as “Players”, with their names listed as potential choices.
The problem with that approach is that you can only have one assignment per document. So this will not work if multiple players have access to the same piece of lore (as I highly suspect is the case). That brings to mind Keywords, which are exceptionally useful for assigning multiple fixed values to documents—yes they cannot be used directly by the compiler filter, but we can get around that with Collections.
So really this comes down to Arbitrary Collections vs. Dynamic Collections. Both are very simple in theory:
-
Arbitrary (or Standard) Collections are entirely maintained by you. You put things in, you take things out, and you control the order in which these things appear. For your purposes most of that doesn’t really matter. All you really need are a bunch of buckets, one for each player. When the player has access to the lore that section represents, you can use
[b]Documents/Add to Collection/[/b] to assign that player to the document.
-
Dynamic Collections are just a project search that has been saved into a tab. To see what I mean, try throwing a keyword with a player name onto a few documents, and then load the
[b]Project/Show Project Keywords[/b] panel. Select the player’s name and click the [b]Search[/b] button. You’ll see a search result list on the left as is customary. Now use the magnifying glass icon menu in the search tool to “Save Search as Collection…”. This will come up as a tab in the binder bar with a little magnifying glass icon beside the name to indicate it is dynamic, and will be populated based on the current status of the project and the criteria established in search. Thus, as you work adding names to documents, this tab will shrink or grow as necessary.
As you can see, these both really accomplish the same product—they merely use a different mechanism for getting data into that product, a list of documents in a player-named bucket—so which you use is entirely up to your preference. Do you find it easier to add a keyword or to add a document to a collection? That’s really all it boils down to.
The best way to handle what you want, I think, is to use exclusion as your principle, rather than inclusion. The reason for this is that inclusion will only use items that specifically have been assigned to a collection. That means that all general documents in your binder that are available to everyone would need to be in each of these individual collection buckets (one way or another). That’s a lot of overhead required on your part, and runs the risk of making mistakes (like writing a new section and forgetting to add everyone to it, so nobody ever sees it). Exclusion on the other hand will remove items from the list if they match the filter, and will leave everything else in by default.
To put it another way, you don’t have to do anything to make a particular section available to all players. Everything is that way by default. However if there is a section that three players should not see, then you would add those keywords or dump that document into those three collections, and now when you compile for that player (selecting their name in the collection list), all documents added to that collection will be removed from the compile list.
So it’s a bit of an inverse way of thinking, but I think ultimately it will be more error-free and efficient to work that way.
Incidentally, I do something very similar to this with the Scrivener and Scapple user manuals. These projects are used to create the PDF file for both the Windows and Mac versions, and as you can imagine there are great quantities of things that should be in one PDF but not the other. I use labels, because in my case there only needs to be one “Windows” or “Mac” assignment. When I compile a Windows PDF, I tell it to exclude all “Mac” labelled items, or vice versa for a Mac PDF. Meanwhile all of those sections of the user manual that do pertain to both platforms are included as well by default—because I’m using exclusion rather than inclusion. Otherwise I would have to meticulously verify that every single section relevant to the Windows version had a “Windows” tag on it somewhere and that is just too much work, with too much liability for forgetting to set things up right when writing new sections.