Multiple gms for a single realm
 

I looked around a bit but I don't see whether this is possible as of yet. Can there be more then one gm for a realm? I am running a game campaign where we switch the gm occasionally. It would be great if more then 1 person could be authorized to be the gm on the realm so they could be entering information, preferable simultaneously.

I think once cloud sharing is available that should be very doable.

Huge warning flag!

Well, okay, maybe not quite that bad, but this is one of those "Whoa, there, do you know what you're asking?" things.

Say you have 2 GMs, at widely separated locations, who are both entering topics, and due to a slight mix-up in their communication, they both enter the same topic, and Sync.

Which topic will exist afterwards? Do the topics merge? Does one get destroyed by the second sync? Does it throw a sync error, and ask which copy to keep? If they merge, what order should the snippets appear in? Does it keep two copies of identical snippets?

These are just a few of the multi-GM syncing questions that LWD need to nail down before multi-GM support becomes viable. The syncing logic needs to be robust, safe, and make sure that info doesn't get lost. This is a big deal.

I expect it to happen, yes, but it might be a while before multi-GM support becomes a reality.

I think it could be greatly simplified by having a simple "check this realm out for editing" mode, where only one can be editing at a time. No edit collisions then.

It's still a significant code effort, but less so than trying to reconcile simultaneous edits.

That only works with live database connections, which this program does not do. Even when you're logged in, you're edits are done locally, then you sync before logging off. How would you check for "editing mode" then?

Or say both people are editing offline, not even logged in. An hour later, one person logs in to sync, then logs off. An hour after that, the second person logs in to sync. Depending on what editing was done, the second person could overwrite what the first person did and could have things in his local copy overwritten that might have wanted to save and didn't realize had been edited in the cloud.

So, yeah, it's not quite all that simple. It would be NICE . . . but not simple.

Actually, it's quite simple.

The whole idea behind "check out for edit" means that no one else would be able to make changes while the realm is checked out.

The default condition for a realm would be "checked in" and unavailable for edit.

When a GM wants to make changes, they check it out.

When the 2nd GM went to grab a copy of the Realm or make changes to their local copy, they would have to check it out, but would not be able to, since it is checked out by the first GM.

When the first GM is done making edits, they sync and check in. Then the 2nd GM would be able to check out the realm, recieving the edits made by the first GM, and then make their own changes until they did their sync and check in.

It's a simple concept, but very limiting (by design).

On the other hand, concurrent work in the DB by multiple users - which is what I think 8bitz is referring to - would be super-mega-awesome, but that most certainly would be complex to implement, and would require constant live connections to The Cloud.

I think eightbitz is raising that if you are offline, there would be no way to check if the realm can be checked out for editing.

Which can be solved by making it impossible to check out a Realm for editing if you're offline, which causes problems of its own...

It's a huge set of design decisions.

That's the way it works.

Is it elegant? Nope.
Is it the best solution? Nope.

But it's effective and relatively easy to implement.

I work for a major engineering software company, and one of our largest products is a database for document and CAD data management. Our software allows you to dynamically open and make edits in a structure or document while connected live, and the software implicitly checks things out and in as you move around making changes. Ideally, that's where I'd like to see Realm Works. Multiple people could be working on the same assembly, just in different parts. No problems.

However, you can also explicitly check out (and download) a document or CAD part, or an entire assembly, taking your time and working off-line. Meanwhile, no one else can check out that data. You can connect and upload your changes occasionally if you like, all the while keeping your checkout, so people can see any progress you're making, but until you check it back in, no one else can perform a checkout.

I would imagine that the cost of buying into that technology would be a bit higher than fifty bucks.

A possible solution is to explicitly type realms as "single GM" or "Shared Realm"

that way single GM realms still have all the offline flexibility of current, but shared realms can use a sharepoint-esque checkout system where the realm is locked to edits by anyone except the person who has checked out the realm.

So you would remove from everyone the ability to work offline (a purposeful design decision implemented by LWD to benefit gamers who don't always have internet access) so that a small subset of users could co-author realms? That doesn't seem "simple" at all.

I agree with zarlor that the upcoming realm sharing ability will probably solve your issue.

Absolutely not!

There is nothing preventing someone from working offline in that description. In fact, it fully supports working offline, exactly as it is now, except for the fact that once you first create the realm, you would also do a "checkout".

Then work offline all you want.


The only way you would be preventing people from working offline is if you want to have multiple GMs working simultaneously. That's when you would need to be constantly connected. Unless you allow checking out of certain parts for offline work, allowing one person to work on the World Almanac, for instance, while another worked on Mechanics, and a third worked on Story boards and Encounters. But that's not horribly elegant either.

Sorry, still having trouble reconciling this:

With this:
Especially considering you mentioned being able to update changes to your realm (the same as "Syncing" unless I'm misunderstanding you) without allowing the realm to be accessed for edit by another device. So I guess if you sync but forget to release write protection, you just don't get to work on the realm again until you get back home.

I must be missing something basic here, because this all seems needlessly complicated for such a small benefit.

Ok, I'll back up a bit and try explaining it differntly.

Right now, there is only 1 GM per Realm.
Initial creation of a Realm and Syncing are the only things which require The Cloud.

The GM can always edit their local copy of the Realm, Syncing when/if they wish.



With something like Realm checkout, the only change a single GM would notice is the addition of a "checkout" box.

The single GM would create a new Realm and it would automatically be checked out to them.
The GM can still always edit their local copy of the Realm, Syncing when/if they wish.
They just simply never check it in. Nothing changes.




However, this setup allows multiple GMs to share editing responsibilities, giving the others a break.
Note: This is not simultaneous edits by concurrent users.

GM1 would create a new Realm, which is automatically checked out to them.
GM1 makes any offline changes they wish.
GM1 Syncs, and checks it back in - retaining their (now read-only) local copy for reference.

GM2 checks out the Realm, recieving an editable local copy of GM1's work.
GM2 makes their changes offline.
GM2 has made good progress but isn't complete with their work yet.
GM2 Syncs with The Cloud, but retains the checkout.

GM1 can Sync with The Cloud, recieving GM2's updates.
GM1's local copy is still read-only, but now contains the updates that GM2 made.

GM2 contines to work offline.

Eventually, GM2 would Sync and Check In, and GM1 could then Check it back out again. Or a 3rd GM...



Without sharing logins, and without requiring constant connection to The Cloud, this is the only way to safely have multiple GMs per Realm. By only allowing one to edit at a time.


It's basic document management checkin/checkout functionality, but treating the entire Realm as a document.

I think we're arguing about something that is still theoretical, and the actual technical implementation isn't up to us anyway...

Sorry, I didn't know we were arguing - I was just trying to explain a suggestion I made.

...and yes, it is all theoretical at this point.


Ultimately, I would like to see the ability for Realm Works to allow "hot" or "live" updates to The Cloud in order to support the way I play, but I know I'm a very small minority, so I don't expect that to happen any time soon, or at all. And even then, I would only want it to be an option. Even I wouldn't want to be required to have a constant connection The Cloud in order to run the software.

You're correct. "Discussing" would be a better word.

Seems to me this is tied to player syncing as well.

To amend the above example...

GM1 would create a new Realm, becoming the Editor which is automatically checked out to them.
GM1 makes any offline changes they wish, including creating Players and GM/Players. (GM/P1 and GM/P2 included as a GM/Players and P3, P4 and P5 as Players .)
GM/P1 Syncs, and checks it back in, - retaining their (now read-only) local copy for reference and becoming a Player and Viewer.

GM/P2 checks out the Realm, becoming the GM and Editor receiving an editable local copy of GM1's work.
GM/P2 makes their changes offline.
GM/P2 has made good progress but isn't complete with their work yet.
GM/P2 Syncs with The Cloud, but retains the checkout.

GM/P1 can Sync with The Cloud, receiving GM/P2's updates.
GM/P1's local copy is still read-only, but now contains the updates that GM/P2 made.

GM/P2 continues to work offline.

Eventually, GM/P2 would Sync and Check In, becoming a Player and Viewer, and GM/P1 could then Check it back out again, becoming the GM and Editor. Or a 3rd GM/P...

Exactly that, ZB.

If you are not the current "Editor GM" your access is exactly the same as a player's would be normally.

That makes much better sense to me, thanks. I still don't see this as being much different than using RW on multiple devices. You still must sync your changes, and I believe there are safeguards in place to keep you from syncing a ream from one device that has been changed on another (although I could be mistaken, and if there aren't there should be).

If you can't share a login, and you don't think the sharability of realms will be enough to successfully collaborate, then I agree that your idea should be possible. :)

Given the nature of this thread, I'm moving it to the Feature Requests forum where it can be more easily found in the weeks and months ahead for other users to up-vote. That will give us a better idea of how important this feature is relative to everything else when we prioritize what gets added.

Ok... So what if you have 2 GM's for the realm... in my case we want to use the product for Champions. Each judge is writing his own NPC's AND Plotlines.. If each did a sync would it not just add the new data to the file in the sync?

No. If they both opened Realm Works at the same time, and were both able to start working on the same realm at the same time, they would each have a separate copy of that realm. If GM Bob syncs his copy, the copy on the server would have all the original data plus the data Bob added. Then, GM George would sync with the server and the server would have all the original data plus anything George added. Everything Bob just did would be gone.

The only way to solve this would be to keep Bob and George from working on the same realm at the same time. Currently this is done by making Bob and George have completely separate realms that they should eventually be able to merge together. Another way would be to put safeguards in place so that George would get a message telling him that Bob already had the realm checked out, and that he'd have to come back later to make any changes. This is inconvenient, but not as inconvenient as having all of your hard work erased because someone else saved over it.

In the future this could be managed by using the shared realms ability.

So just like when you are able to purchase or download a shared realm, and then make local changes, and then resync to include changes from the shared realm when changes are made to it. (All your local changes would remain local to your GM realm.)

The shared realm in your case could be the generic world information.

Your local changes would then be the GM stuff that is specific to your plots (so other GM-players won't be able to see your plot).

Hi guys,

I was quite surprised that multiple authorship was not a feature supported out of the box.

Version control is a well solved problem (have a look at the wikipedia articles for SVN (an implementation of the solutions discussed above) or Git, a distributed VCS that I think should form the model for RealmWorks.

The Wolf Lair guys almost certainly used a VCS in making RealmWorks, so they're probably familiar with the concept.

It isn't especially difficult to implement (cloud sync is arguably a more complex feature), but it might require exporting a non-binary database format (such as the XML used by Hero Lab) which Wolf Lair might not want for non-technical (read, proprietary control) reasons.

As long as this does not mean, that an internet connection is mandatory, I see no harm.

However, if it does require an always online connection, then RW becomes completely useless for me and that would really be a shame.

As has been said in many other threads, this system isn't always online. You only need to be online to sychronise your realm (to the cloud, to other players, to other GMs, etc.).

I know; I just don't want new functionality to mean that this will change.

That is the point I am trying to get through :)

Remember that we are ultimately talking about a database, not a file. VCS works on what it is designed to.. files.

In order to have multiple authors, some form of locking and collision conflict would need to be implemented.. and it *would* need to be accessible to multiple users at all times .. which would mean that, yes, the internet connection would be required for all activity in order to manage "check-in" and "check-out" at whatever level was required.

I would ask that people WAIT and see what the forthcoming Repository and Marketplace enable. If I understand it, you will be able to have some quasi-support for multiple authors (two authors each control a set of topics in their realms; both have shared that data and import each others' content into a single working realm).

There are also implications for purchased content. Two GMs with equal simultaneous access to purchased content would need some way to verify that two licenses to the content had been purchased.

Multiple simultaneous GMs is a BIG can of worms. There are major access contention issues that are NOTHING like version control, as @Silveras pointed out. There are a bunch of other issues beyond that as well, some of which have been touched on by others in this thread. Suffice to say that collaborative development is something we have on the road map, but it's definitely a future objective and certainly not going to be quick and easy. If there's enough demand this feature, we might be able to implement a crude solution first that would be workable for co-GMs, but a good solution will entail a significant amount of work.

Put me down as a +1 but not as something 'soon'. There are many other smaller things I'd like to see before this is tackled.

I would definitely want a way to take an existing realm and add a second GM to it.

Possibly related - would like to have multiple 'reveal' options for either multiple players or groups.

I'm curious what sort of database middleware Lone Wolf is using.

A database should be readily accept multiple simultaneous edits if it is ACID compliant (after all, this forum is an example). It seems odd that you'd need to lock the entire database during edits - per cell locking is straightforward enough to implement.

Can you elaborate more as to why this is a "significant amount of work"?

@FrameProblem... There are two database systems. One is local to the machine, and supports off-line work against the Realm. This is the one that is directly used by the program while working on it. The second is a cloud database used for distribution of changes to "subscribed" machines (a GM's second machine, a player's copy of the software, the future web-based player access, etc.).

As such, there are no "concurrent" updates. A GM can accumulate changes on the local copies for weeks, even years, without syncing them to the cloud (and thus, if using two machines, to each other). Doing this while working on two machines pretty much guarantees that eventually, one set of changes will over-write the other when both are sync'd to the cloud server.. last one there wins.

There was brief talk some time ago about some merging tools to allow GMs to see and select which conflicting updates would be accepted and which rejected. There has not been anything said about that in some time, though, and for now there is no such capability.

So, multiple GMs dramatically increases the possibilities of conflicting updates, and would require that such merging tools be created as part of the necessary support.

(Note; A GM can use two machines safely without the cloud syncing by backing up the Realms db on one and restoring on the other. This restore over-writes all realms, though, not just one.)

As Silveras said, it's more UI work for conflicting changes than anything else. It's no fun when the last person who edits wins. :(

There could be concurrent updates if two GMs were on the web client at the same time, but it's bigger than just the database engine handling changes. If they're both trying to edit the same snippet or one makes major changes to a Topic/Article the other is editing then you have to handle things somehow.

I've done my fair share of SharePoint development, and let me just chime in here.

Multiple GM's sharing the same realm will be UGLY to implement.

Nothing stopping it from happening, just ugly.

An easier solution would be to have your realm created by GM1. Let's call it RotRL, cause you know why.

GM 1 enters EVERYTHING for the first module. Saves the file as RotRL 1.

GM 2 Loads RotRL 1, enters everything for the second module. Saves the file as RotRL 2.

etc...

That will be the easiest solution once sharing is available. Until then....you could share your login. That's probably against the EULA or what have you for RW, but there you go.

it's an ugly situation, and even merging will cause problems (multiple entries for the same individual, location, merchant, etc....).

I don't code for a living, I manage projects and tell people what to code. So, without having a system map or having intimate knowledge into the program, I can't see the best solution. That being said, what you guys want, CAN be done. But for now, it's share login or nothing.

+1 if it can happen. And a hell of a lot of respect if you guys can do it. It's a crazy issue.

Yes, but it seems to me only because the technology used as a base for RW is a relational database concept. A NoSQL document store for saving and a SaaS-API for cloud services could have worked wonders here. Just look at something like Evernote, that funcionality crossed with RW would be immensely powerful . And it is not rocket science nowadays.

I admire the functionality and quality of RW, the effort of the developers, and I like the tool for what it is. But I cannot shake the feeling that a real cloud-based campaign management tool has yet to happen.

Well, for Realm Works they didn't want to do only online anyway. The original intent was to have full client applications for Windows and OS X.

I personally wish it was a bit more disconnected (like how Evernote can create local-only notebooks) but it is what it is.

First my snarky comment: FYI, LinkedIn puts Evernote's staff at 456 people.... Methinks this apples and nuclear bombs comparison is missing a slight dose of reality.

That aside, switching database design around really sounds like a 2.0 goal. Let's get printing/export (and yes, sigh, calendars) implemented alongside a Marketplace and some GUI refinements and a few little things like per-character reveals, tools for external program integration, robust map pins, etc. to finalize things that will fit within the current framework.

@Rob/Liz: Is it too soon to start requesting other v2.0 features? I bet we could come up with a handful more that don't fit nicely in the current package.... :)