A few Questions on the ultimate license

[GBE300]

Hi All,

I couldn't find a clear answer on here after looking through the forums so I figured I would just ask, sorry if this is a repeated question.

I am looking at buy the ultimate license for myself and to host a game for some friends. Now the game I host I will not be the GM, but rather a player with one of the others connecting being the GM. Will this work ? Can I pass control to another person in the campaign to run the game ? Will they be able to access my content or will they need to buy it themselves ?

Thanks for the help.

Cheers,
GBE300

[Thegroo]

no and yes

No to hosting the game and not being the GM.
Yes to sharing the content. (but just the host can share)

[Trenloe]

Just to clarify what Thegroo said.

Can I pass control to another person in the campaign to run the game ?

No. The GM must be the one hosting the game. If the GM has an ultimate licence this will allow players to connect with a free licence. You can't transfer the ultimate licence to another user. So, either your GM will have to buy or subscribe to the ultimate licence, or everyone will need to purchase or subscribe to a full licence (or higher).

Will they be able to access my content or will they need to buy it themselves ?

Players can only access the content the GM owns (and chooses to share) during the game.

Players can access their own content outside of the game (in manage characters and in their own campaigns if they have at least a full licence).

Hope this helps to answer your questions.

[GBE300]

Cheers guys thanks for the help!

[Jigo]

No. The GM must be the one hosting the game. If the GM has an ultimate licence this will allow players to connect with a free licence. You can't transfer the ultimate licence to another user. So, either your GM will have to buy or subscribe to the ultimate licence, or everyone will need to purchase or subscribe to a full licence (or higher).

Well, that's terribly disappointing. I just spent an embarrassing amount of time trying to find this exact answer. Have the developers expressed any intent on possibly addressing this limitation?

My group would love to begin using the FG system for our sessions, but very few have been willing or able to afford the $40 entry fee. I was willing to drop the $150 on an Ultimate license if I could appoint our GM the permissions of GM while I host the session on my machine.

This simply feels like a very silly reason for SmiteWorks to lose a $150 sale, if this functionality is by design. Hopefully someone has some good news for me!

[Mask_of_winter]

The host act as the server. Every player connects to the host/server. The GM is the host. That's the way it's always been. This ensures only the host/GM needs to have any DLC or homemade modules, maps, items, notes, etc. and can decide what to share and not to share with the players. Otherwise a player host would have to do it or send a stream of data to the GM who would have to redistribute it.

You can purchase the license for your GM though or you can all chip in for a $10/month subscription to try it out.

Now, Smiteworks has been working on the new version of FG using Unity. Whether or not what you're asking will be possible with the new version I don't know but it's a possibility.

[Trenloe]

My group would love to begin using the FG system for our sessions, but very few have been willing or able to afford the $40 entry fee. I was willing to drop the $150 on an Ultimate license if I could appoint our GM the permissions of GM while I host the session on my machine.

The GM must be the server - this is by design and the best approach in a client/server architecture for this type of application.

If you rotate GMs (or want to assign just one GM) then you can go with the $10/month ultimate subscription for that GM, cancelling when one GM stops and starting a new subscription when another begins. FG stores all of it's campaign data on the GMs computer, so it's OK stopping/starting subscriptions - you won't lose any of your previous campaign data. Get some of the group to chip in to help with the monthly subscription.

Or, depending on the size of your group, you could buy through Steam and get 4 Full licences for the price of 3. Depending on how many are in your group this might work out a similar cost to you purchasing an ultimate licence - but each user would be able to GM a game at some point.

The one gotcha with the subscription is that you can't get library data content through a subscription, and the GM must own the library data to share with the players. If you're not playing 5E then this isn't a large buy in, but if you're playing 5E and you want to have all of the library data available then it isn't a small purchase for the GM.

[Jigo]

The GM must be the server - this is by design and the best approach in a client/server architecture for this type of application.

I respectfully disagree with this position, wholeheartedly. The responsibility of acting as GM is simply a choice to be made amongst the players. In terms of programming this effectively into a client/server architecture, this role could merely be implemented as a set of permissions to be assigned to no more than one connected person (host included). This would be no different than assigning admin permissions in any number of other server/client architectures for countless other software games. The hosting player would still be paying for licenses to the utilized content, but the role of GM in the session could remain agnostic to the server/client relationship in this way.

For a less abstract example, imagine I were able to play with my group in person. If I were the only one willing to pay for the player manual, the GM manual, character sheet materials, dice, etc. we could still play a game together with any one of us acting as GM. I would still be the one that takes all of the paid-for game materials home with me at the end of the day. I would simply be responsible for being the one that brings all of the game materials to the next session so we could pick up where we left off. Similarly, limiting the GM role to a set of permissions in software is certainly implementable regardless of which user is hosting the session as a server.

That being said, I completely understand if this was an intentional design choice by the developers in terms of how they choose to license their product. If they have chosen to restrict this option as a part of their business model, that is absolutely within their rights.

All I mean to suggest is that an alternative to such a setup is indeed possible. If there were any sort of plans to change this design choice in the future, it may just make room for some more very happy paying customers

[dulux-oz]

I respectfully disagree with this position, wholeheartedly. The responsibility of acting as GM is simply a choice to be made amongst the players. In terms of programming this effectively into a client/server architecture, this role could merely be implemented as a set of permissions to be assigned to no more than one connected person (host included). This would be no different than assigning admin permissions in any number of other server/client architectures for countless other software games. The hosting player would still be paying for licenses to the utilized content, but the role of GM in the session could remain agnostic to the server/client relationship in this way.

For a less abstract example, imagine I were able to play with my group in person. If I were the only one willing to pay for the player manual, the GM manual, character sheet materials, dice, etc. we could still play a game together with any one of us acting as GM. I would still be the one that takes all of the paid-for game materials home with me at the end of the day. I would simply be responsible for being the one that brings all of the game materials to the next session so we could pick up where we left off. Similarly, limiting the GM role to a set of permissions in software is certainly implementable regardless of which user is hosting the session as a server.

That being said, I completely understand if this was an intentional design choice by the developers in terms of how they choose to license their product. If they have chosen to restrict this option as a part of their business model, that is absolutely within their rights.

All I mean to suggest is that an alternative to such a setup is indeed possible. If there were any sort of plans to change this design choice in the future, it may just make room for some more very happy paying customers

Trouble with your alternative model (as valid as it is) is the amount of extra coding and traffic such a model entails - especially as what you are proposing is not a client/server architecture but a peer/peer architecture. I am not sure which game system you are referring too, but every system that I am aware of (if it is a true client/server architecture) is that none of the players nor gm acts as a server, and the server is located/hosted elsewhere. This is also true of all commercial/business systems I am aware of.

Could FG be rewritten to accommodate your proposed model? Of course, but I, for one, would rather see the time and effort of the SW Devs spent in providing more useful features than working on something that really isn't broken.

Just the $0.02 worth of a network & database architect (among other things)

[Jigo]

[...] what you are proposing is not a client/server architecture but a peer/peer architecture. I am not sure which game system you are referring too, but every system that I am aware of (if it is a true client/server architecture) is that none of the players nor gm acts as a server, and the server is located/hosted elsewhere. This is also true of all commercial/business systems I am aware of.

This actually wouldn't require a P2P setup. For an example of what I was citing concerning other games and an implementation of permissions for designated clients, let's say.... something goldsrc/Source engine based (i.e. Counter-Strike, Team Fortress). The server has an associated password that grants admin permissions for certain commands like changing maps, kicking players, etc. Once a client has provided the correct password for admin privileges, they can then perform admin-limited commands. This is not a P2P environment, but a true client/server setup. There are countless examples like this in network gaming.

How this would translate to FG is not a password solution but simply the ability of the host/server to select a specific client within FG's UI to have GM controls such as hidden GM dice rolls, etc. The client/server architecture would remain, but certain function calls may be restricted to a specified client. No additional network usage besides a few packets to designate the current gm and for each GM-related function call coming from the selected client. All of which are directed to the server alone. Any resulting traffic being sent out to all clients as a result of said GM functions would be identical to the current implementation as well.

While the current implementation isn't functionally broken, I'd say it is restrictive enough to shoo off potential customers. The real question is if that number is high enough to warrant a change :P

I do appreciate the feedback though, as you certainly would seem to have more years of experience than myself in the field . I'm a software engineer myself with a bit of network experience as a hobby.