• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

Multiple gms for a single realm

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.
 
Vargr said:
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.
Click to expand...

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.).
 
Farling said:
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.).
Click to expand...

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.)
 
FrameProblem said:
Can you elaborate more as to why this is a "significant amount of work"?
Click to expand...
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.
 
Pollution said:
Multiple GM's sharing the same realm will be UGLY to implement.
Click to expand...

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.
 
Hyos said:
But I cannot shake the feeling that a real cloud-based campaign management tool has yet to happen.
Click to expand...
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.
 
Just look at something like Evernote, that funcionality crossed with RW would be immensely powerful . And it is not rocket science nowadays.
Click to expand...
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.... :)
 
You must log in or register to reply here.
Back
Top