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.

[dulux-oz]

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.

You missed my point - true, the model you propose is a true client/server, but in this case the server is not run by any of the players; its run by the game company - the one that springs to mind is battle.net for playing such games as Starcraft - its the game company's servers that provide the permissions system, not the players (ie client) machines.

Any other architecture becomes peer-peer by definition - even if one of the peers is operating in a "master" mode.

Could SW and FG do this - of course, but it would require a substantial rewrite - the move to Unity may implement this, but I, personally, don't consider it a worthwhile investment (considering the other functions more in need).


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

That's a matter or opinion, and one I believe is addressed quite nicely by the subscription licensing model which is available - true, it requires more "input" from the user, but we, as software engineers, have a tendency to "over-engineer" our solutions way past the point of diminishing returns - often, subconsciously, in an effort to show the world how clever we are. One of the biggest hurdles I've faced when mentoring coders on projects is to remind them to give the client what the client wants, not what we think is "cool".

[Jigo]

You missed my point - true, the model you propose is a true client/server, but in this case the server is not run by any of the players; its run by the game company

Are you saying that FG is currently a P2P setup as-is? Or simply the setup I'm suggesting? Because the former would be contrary to what I was told earlier in the thread.

[dulux-oz]

Are you saying that FG is currently a P2P setup as-is? Or simply the setup I'm suggesting? Because the former would be contrary to what I was told earlier in the thread.

What I'm saying is that FG currently operates in a true client/server architecture with the GM/host being the server. There's a lot of server-side processes that go on when we select "Load Campaign" or "Create New Campaign" that don't get loaded or run when we select "Join Game". These processes are intimately related to the functionality of running FG as the GM, and can't (I believe) easily be split/separated into component parts (not necessarily how I or the current Devs would have done things, but that's how FG has been since v1 back in the days before Smite Works brought the product).

This is one of the reasons that the GM/host has to set up their firewall to allow incoming connections - and I don't think there's another application on the market (game, vtt or otherwise) that operates in this manner - baring Enterprise software upon which you never (or shouldn't, at least) run a client process on the server component.

There are both pros and cons in operating like this (client/server with the GM client functions integrated into the server components), and I'm not going to get into that here - we'll leave it for another time and place, when the non-IT-geeks don't have to be bored reading about design theory, etc :)

To do what you suggest means that there would be these processes needed to be run on all the machines, if only initially, and the packets would be required to flow between all the machines, again, if only initially - a peer-to-peer network (eg a Bit-Torrent Network)

=OR=

There is set up somewhere a central repository/server that all the clients connect to and the "GM" is then determined from this central server, with all of the running expenses such a architecture would require - a client/server network (eg a network game network like Battle.net/Starcraft).

<rant>
As an aside, one of the issues I have with the gaming industry is that they used some terms in incorrect and/or misleading ways - for example, I was playing Gauntlet on Steam last night and I was "hosting" my friends, in that I was the one who determined the game set-up, etc. BUT I wasn't operating as a host in the true (IT/Computer Science/Architecture) sense of the word; that was being done by the Steam Server(s) - the reason I DIDN'T have to open up my firewall to accept incoming sessions - all I had was outgoing sessions to the Steam Server in a typical client/server communication pattern, as did my friends with their PCs and the Steam Server.

Thus this "inappropriate" use of terminology can lead to confusion, misunderstandings and, in some cases, errors in thinking - one that we are all susceptible too. :)
</rant>

The idea behind your suggestion I like (sorry if I lead you to assume otherwise), I'm just not sure if its worth the effort - especially now that we have the subscription options.

Cheers

[Hastur]

sorry for the interruption of Tech-talk I am not able to understand.

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.
I am the GM in my groups, online and offline, and if one of my players would take all my roleplaying-books away from me inbetween the sessions I not only would kill him for that ;-) but I would not be able to be the GM anymore. So apart from all technical possibilities and licensing law, the ultimate license takes account of how the most rpg-groups work. Want to support your GM? Make him a gift! No reprogramming needed for that. Please never again talk about taking away the toys from a GM ;-) Greetings

[Jigo]

@Hastur
That example was my analogy to real life. If I went to my local game shop and bought all the materials to allow my friends and I to play, I'd still be the one taking that stuff home at the end of the day. Them playing with me wouldn't deprive me of anything I paid for. That's all I was getting at. No one is trying to take your books, haha ;)

@dulux-oz
No worries, I enjoy a thorough discussion. Just wanted to be sure my understanding of the current state of the game was correct before elaborating a bit. Also, I feel your pain when it comes to improper usage of the term 'host' like you described. Drives me up the wall.

I just can't help thinking there may have been a misunderstanding in what I'm suggesting. I don't believe a P2P approach would be necessary at any point in what I'm picturing.

Let's have an example group of Adam, Becky, Chad, and Dana. In this example, Adam will be the acting host/server and owns an Ultimate license.
In the current state of FG:
-Adam only communicates with SmiteWorks (company servers) to verify his licences for FG itself, and any rulesets he may own.
-Becky, Chad, and Dana all connect to Adam via free clients, and only to Adam (as they have no licenses of their own). They share in whatever content Adam owns and can play at no cost
-All campaign, character, gamestate, etc. data is stored on Adam's hardware.
-While Adam is acting as a true server in this situation, he also is simultaneously running a client in which he is forced to act as GM.

Now, assuming that all of the above is correct (and if not, I apologize for having a faulty foundation :P) let's take another look at my idea:
Adam wishes to allow Becky to act as DM.
-The first 3 statements all remain unchanged.
-While Adam is acting as a true server in this situation, he also is simultaneously running a client in which he is not forced to act as GM, but now has an option to designate a GM.
-The player designated as GM is selected by Adam, stored by Adam's server, and Adam's server tells Becky's client that she is now set as GM (the few packets mentioned in my other post).
-Becky's client UI now shows the GM options once only showed via Adam's Client.
-Conversely, Adam's client UI no longer shows GM options, but the ability to designate a GM remains at all times due to him supplying the acting server.
-Becky's client sends GM function calls directly and exclusively to Adam's server (the only other additional traffic added by this implementation), which then performs said function and sends the result out to all 4 players (when appropriate, and as it currently does without any of my suggestions).
-When the game ends: all campaign, character, gamestate, etc. data remains stored on Adam's hardware as per usual.
-Adam must continue to act as server in the future to resume the existing data for their campaign for another sitting.

To summarize, the only changes I'm suggesting are that the server would store who is currently acting as GM, and communicate with that player directly for any and all GM functions. Also, a way for host/server player to choose the GM at any given time.

SmiteWorks would not need to run any sort of game server for us and the players would not be required to act as a P2P network to facilitate this. The server-specific processes related to GM functionality will remain on the server (Adam's machine in my example) but a set player (Becky) would be granted permission to execute/trigger these functions from their client via direct communication with the server.

I can certainly agree this may be easier said than done depending on the exact implementation of the current client/server architecture. I'd like to believe my idea is only a slight extension of the existing interfaces to the current client and server backend processes, but in reality, who knows? Without some explanation or confirmation from the devs themselves, the best we have is speculation.

In the spirit of "giving the client what the client wants", keep in mind that I am a potential client whose needs are not being met. If it were not for this restriction in the current product, I certainly would have made a purchase today. This is more than just a "nice to have" or "cool" feature. This was a dealbreaker for me.

[dulux-oz]

I can certainly agree this may be easier said than done depending on the exact implementation of the current client/server architecture. I'd like to believe my idea is only a slight extension of the existing interfaces to the current client and server backend processes, but in reality, who knows? Without some explanation or confirmation from the devs themselves, the best we have is speculation.

Yes, I agree with all you've said (& which I haven't included above), but as I said in an earlier post, the GM & server functionality is tied up together in the code, so can't easily be split. Also, for a client to run a server process (especially the way the system is set up) requires the process to be on the machine its running on, or in other words, the machine running the server process needs to be a server, so Becky can't run a server process on Adam's machine, only on Becky's - and hence my original point about the resulting architecture now being p2p.

An interesting discussion, but one I think has run its course - at least in this thread where we've started to bore the "normals" :p

Cheers

[Nylanfs]

BTW, I believe you can gift the ultimate license through steam

[Griogre]

Yeah you can. Let me go through the options. If you guys are trying things then just try one of the monthly subscriptions. Monthly submissions are good for trying things out.

If you want to buy and your group is 4 or less get the buy 4 pay for 3 deal on steam. Its cheaper than the ultimate and everyone can DM. The ultimate license means basically that only the the one with the ultimate will DM. If this is true that's good, but if its not true then the cost for the next DM is the price of an ultimate license. If someone does just want to run a one shot then he could just get a monthly license while running.

Ok the FG license is just for the FG VTT, with FG you can play 5E without getting anything else, but the player's will have to fill out the character sheet manually and the DM will have to prep the adventure by inputting the monsters, NPCs and maps. It honestly is not much work to fill out a character sheet, assuming you have a copy of the PH or the D&D Basic Rules pdf. One the best things about 5E is you can play it with just the basic rules. However for the DM its a lot more data input.

On to the D&D licenced stuff. If cash is short, you have multiple DMs in a group, or you are just trying things out the Basic Pack is a very good deal at $3 with 4 basic PC builds and 150ish monsters. The only downside if that everything in the Basic Pack is in the Complete Monsters and Complete Characters so if you know you are going to get these its a waste, but for someone short on cash a 3 buck buy in is great. If the DM just wants to run a License module (ie Phandelver, HotDQ) he doesn't even need the basic rules, he just needs the module since the monsters, NPCs, maps and story will already be input in the module.

Should some player want to get some automation through a class pack then he can gift the DM the pack on Steam. We all know the guy who only plays one class and the individual class packs are great for him. For races though that guy will either need the basic rules pack to get the races in the basic rules or the player customization pack to get all the PH races and feats. Note: I think Steam won't let you gift a pack to anyone who doesn't own a normal or ultimate FG license and the monthly licenses don't count? If that is important you should e-mail tech support on this.

[Bazil Remblai]

This thread cleared up my confusion, thank you guys for posting it! My only two cents would be to please reword your selling point on Steam....

"Host games for Players, GMs and FG Demo players together."

I will be getting the Upgrade either way, but it is a bit deceptive in the wording. Perhaps "Host games for Players and FG Demo players together."

[LordEntrails]

Note that I haven't checked the license agreement to see if this is somehow in violation, but isn't their an easier solution to all of this?

Run FG host on a "extra" computer, then whoever is the GM simply runs a remote desktop session. It requires an extra computer, but then any of the players can be the GM that week. In fact, if you left the (psuedo)server running all the time, then the upcoming GM could remote in, develop their material prior to the game session, and then at the time of the session, remote in again and everyone else just connect as usual (even the owner of the "server").

And if you didn't have an extra computer, and you had one with enough capabilities, you could run a virtual machine on it as your psuedo-server.

[Trenloe]

Note that I haven't checked the license agreement to see if this is somehow in violation, but isn't their an easier solution to all of this?

Run FG host on a "extra" computer, then whoever is the GM simply runs a remote desktop session. It requires an extra computer, but then any of the players can be the GM that week. In fact, if you left the (psuedo)server running all the time, then the upcoming GM could remote in, develop their material prior to the game session, and then at the time of the session, remote in again and everyone else just connect as usual (even the owner of the "server").

And if you didn't have an extra computer, and you had one with enough capabilities, you could run a virtual machine on it as your psuedo-server.
This does violate the user licence - any FG licence is a single user licence, which is not transferable/usable by other users.