Kickstarter Clarification Questions

[rob]

Originally Posted by bodrin

Okay let's say PC #1 tells NPC #1,2,5,6,9,10 that x=y
PC #2 tells NPC 1,2,5,6,9,10 that x=z
PC #3 corroborates the PC #1 info with NPC #2,3,4,5,9,10 and refutes the info with NPC 1,6
but PC#4 informs NPC #1,2,3,4,5,6,7,8,9,10 that x=y=z

You would have to link the 3 pieces of (mis) information to each NPC cross referenced with the individual PC's information and maintain an accurate record over multiple information snippets. Confused yep me to. But over multiple campaigns with multiple players his kind of situation does occur!

I'm going to start with your last comment. So these multiple campaigns will all be impacting each other? Most people I'm aware of "instance" their worlds, so that the actions of Party #1 have zero impact on the world for Party #2. Your final sentence here implies that you run things differently, and I need to make sure I'm understanding properly.

The database structure necessary to model the scenario you've outlined here would need to track both who knows what *and* who told what information to whom. That latter component adds a significant level of complication to things, and it's not nearly as common a situation as the former. We've only designed things at this point to handle the former. We could do the latter, but it will take more work and is outside the scope of what we'll be providing in the initial launch and the first few updates after that.

As I mentioned above, we could potentially extend the "who knows what" mechanism to encompass NPCs, but that will not address the separate issue of "who told them what". We can definitely put this on the todo list, but it's not something to expect soon.

[rob]

Originally Posted by AEIOU

Sorry if I'm naive here....

Not naive at all. The solution you've suggested is similar to my first idea for solving this when it was suggested. A less onerous solution for the players would be preferable, though, and I have some ideas on how that might be achieved, but nothing has been seriously thought through yet.

[bodrin]

Originally Posted by rob

I'm going to start with your last comment. So these multiple campaigns will all be impacting each other? Most people I'm aware of "instance" their worlds, so that the actions of Party #1 have zero impact on the world for Party #2. Your final sentence here implies that you run things differently, and I need to make sure I'm understanding properly.

*snip*

As I mentioned above, we could potentially extend the "who knows what" mechanism to encompass NPCs, but that will not address the separate issue of "who told them what". We can definitely put this on the todo list, but it's not something to expect soon.

I participate in two games that run simultaneously each week, group one plays a module and the events played out in that session then impact the group two session. For example group 1 foils a dastardly plot that group 2 has also been investigating, group 2 arrives at the conclusion that the villain has fled before them and piece together another lead that points in the direction of group 1.
Npcs provide the information to both groups and group 1 prepares a trail of false clues. Etc. and so forth!

Similar to a living campaign. At the moment I have numerous players that dip in at different times due to work commitments.

So the impact on information is sporadic at best, if a player doesn't attend then usually the PC is sidelined until the next session this causes a delay with "catch up" and "game time". Being able to link the info to both NPC and PCs in both campaigns would be a handy tool but I understand its a complex process!

[mirtos]

Originally Posted by rob

Lobbying for features is perfectly fine. I just have to make sure I don't commit us to something we can't deliver on until it's been properly investigated. In this case, it's not a question of whether we *can* do it, but how long it will take to do it.

I completely get that.

I just hope its early, because the more I think about it, the more I feel its vital.

However, Im going to be honest, until I saw the kickstarter, I always assumed that you would be able to reveal to individual players/characters. In the past when you talked about "revealing information to players", I just assumed that meant "individual players", otherwise whats the point of having individual player accounts. Am I missing something? Forgetting the multiple campaign issues, I have to imagine a LOT of DMs pass notes, so that way some players are aware of things that other players in the group arent. Its a very common thing in gaming groups, and it requires the DM to know who knows what. If Realms Works is to take the place of DM notes (which i think it is), its pretty necesarry. Just my two cents of course.

[rob]

Originally Posted by mirtos

However, Im going to be honest, until I saw the kickstarter, I always assumed that you would be able to reveal to individual players/characters. In the past when you talked about "revealing information to players", I just assumed that meant "individual players", otherwise whats the point of having individual player accounts. Am I missing something? Forgetting the multiple campaign issues, I have to imagine a LOT of DMs pass notes, so that way some players are aware of things that other players in the group arent. Its a very common thing in gaming groups, and it requires the DM to know who knows what. If Realms Works is to take the place of DM notes (which i think it is), its pretty necesarry. Just my two cents of course.

I wholly agree that it's "pretty necessary". As I mentioned earlier, it's been designed into the underlying architecture already because we see it as important.

With any software project, there are layers. Some layers need to be implemented before others. The same applies to priorities. Some features are going to be more valuable than others. Of course, the question of which features are more valuable will also differ from one user to the next, but we need to look at all users here. The one thing that is an absolute constant is that everything takes time to implement. So it all boils down to reconciling these three factors: (a) what has to happen before something else, (b) how valuable a feature is to how many users, and (c) how long something will take to implement.

We worked through our long list of things we want to add and reconciled it against the above three criteria. The net result was that revealing content to individual players is important, but there are other features that are either more important and/or that have to be in place before it can be added.

That leaves us with two options. We can either release the product in July without that feature or we can wait another few months to release with that feature. There are way too many valuable features to delay the release for something that isn't going to be needed on day one. [You're going to need to actually get your campaign *into* Realm Works first, aren't you? ] So it makes perfect sense to release the product without that feature and get it added relatively soon afterwards.

I hope you can agree with this logic.

[pyremius]

Back again, finally.

My last set of ideas was while half asleep and running late as well, so was definitely not the most thought-out.

It looks like Bodrin came up with a pretty solid example of what I was trying to describe. One group might be based out of a town, developing relationships with specific NPCs, and then take off on a voyage to a deserted island in search of lost treasure. While they're gone, the other group might pass through, pursuing a caravan which robbed them. While tracking down the merchant and his stolen goods, they have plenty of opportunity to change the relationships between factions and major NPCs before heading on their way to a new adventure. The end result for group one is a whole lot of new relationships they're not familiar with (They had been friendly with the Guard captain, and secretly knew his daughter was involved with a mid-rank member of the thieve's guild. Thanks to the fire started by group two, the daughter was in danger and the thieve's guild led the rescue effort, forging an otherwise-unlikely bond between the guild and the guard, and significantly straining relations between the captain and group one, as they hid their knowledge of the relationship).

One advantage of using the reveal knowledge function at the character level (and higher, at the party level to flow downward) is that it provides a single method for entering and sharing pieces of knowledge for all PCs, NPCs, Guilds, Groups, and what-have-yous, rather then requiring multiple processes and the occasional manual duplication.

I'm not particularly worried about integration of my ideas at this point. You've got a great track record already of improving and enhancing your products, so if it is a good idea, it'll show up eventually. Much more important to me is that I get the ideas out as soon as possible. You can't decide to implement what you don't know anyone wants, and you also can't use those ideas to help shape your roadmap - even if you're not trying to implement them now, if you think they're valuable they will shape how you implement other ideas ranked higher, because you can weigh the current design decisions against their impact on your known future goals.

[merlinsghost]

Originally Posted by bodrin

What if the same information was linked to multiple Npcs?
Inputting the info for each individual NPC would become tedious especially if there were a lot that needed to be updated.

Perhaps some mechanism to link one piece of info to multiple Npcs stat blocks and auto populate the relevant field with the correct text. Batch linking perhaps?

I kind of already to this sort of thing, and this is how:

If there is a group (especially one an NPC is affiliated with), I make a topic in the group section for that group with various bits of information.

If there are multiple affiliations, some good, some bad, I make multiple affiliation entries in the NPC entry -- one is for things that the PC's know about, and one that the NPC's don't know about.

I suppose what I'm saying is that this can be resolved by re-thinking organizational structures of your topics.

Remember that for each individual topic section (Affiliations, Notes, etc.), you can have more than one, and then you can control individual if that entry is revealed or not.

There are already headings that kind of support this kind of organization: there is a "Story Told" and then "real truth". And because topics are completely customizable, you can add or subtract variations of that theme. At some point you're going to run into some amount of tedium when entering data/information, which only gets worse the more information you have (copy/paste is nice). This way you're only using the name of the organization when you're inputting data into the NPC's topic instead of having a more complicated process.

Of course I could be misunderstanding what you're asking for, in which case you can ignore me.

[mirtos]

Originally Posted by rob

I wholly agree that it's "pretty necessary". As I mentioned earlier, it's been designed into the underlying architecture already because we see it as important.

With any software project, there are layers. Some layers need to be implemented before others. The same applies to priorities. Some features are going to be more valuable than others. Of course, the question of which features are more valuable will also differ from one user to the next, but we need to look at all users here. The one thing that is an absolute constant is that everything takes time to implement. So it all boils down to reconciling these three factors: (a) what has to happen before something else, (b) how valuable a feature is to how many users, and (c) how long something will take to implement.

We worked through our long list of things we want to add and reconciled it against the above three criteria. The net result was that revealing content to individual players is important, but there are other features that are either more important and/or that have to be in place before it can be added.

That leaves us with two options. We can either release the product in July without that feature or we can wait another few months to release with that feature. There are way too many valuable features to delay the release for something that isn't going to be needed on day one. [You're going to need to actually get your campaign *into* Realm Works first, aren't you? ] So it makes perfect sense to release the product without that feature and get it added relatively soon afterwards.

I hope you can agree with this logic.

I do agree with this logic.

[karpomatic]

Just wanted to drop in and say I'm offically a Pack Member. I contributed to the Kickstarter and cannot wait for July! The video on the kickstarter had me drooling to use it in my current Dragonlance campaign.

[Ladyofdragons]

Originally Posted by rob

Yes, everything is definitely built on top of a high-performance database.

If you have multiple parties adventuring in the same world, such as a GM running two separate campaigns with two sets of players, then you'd definitely need to keep track of which PCs have learned what. However, the way that would be solved is completely different from what you're assuming in Realm Works. You would effectively "instance" the world separately for each group of PCs (similar to the way MMOs do it) and all the details of which group learns what will be tracked within each instance. So you don't have to fiddle with it all the time during play. The exact mechanism for it would be different from MMOs, but the net result would be the same.

Does the "Instancing" concept include a parent/child relationship, where changes to the parent are included in all children? I ask this because like I would bet 90+% of DMs who create their own worlds, my world is always under construction. If I have 2 parties running around in it and I instance the world, I'm still building new things that may be encountered by either party at any point in time, and wouldn't want to have to add that information twice. That would invariably lead to branching, which is not something I want. I have one world, it has one timeline, over the next 20 years it may have several campaigns that run through it, sometimes simultaneously. What one group does may affect the other.

An example: one party in a campaign manages to destroy an entire city in a great fire. Another group playing on another night with a different party in the same world with the same DM might hear of the destruction of the city from a fleeing refugee, or their plans may be thwarted by that change in the campaign world. Seriously, this happened to us.