Multiple gms for a single realm

[Rabulias]

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.

[rob]

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.

[weogarth]

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.

[FrameProblem]

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"?

[Silveras]

@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.)

[Parody]

Originally Posted by FrameProblem

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

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.

[Pollution]

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.

[Hyos]

Originally Posted by Pollution

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

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.

[Parody]

Originally Posted by Hyos

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.

[AEIOU]

Just look at something like Evernote, that funcionality crossed with RW would be immensely powerful . And it is not rocket science nowadays.

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....