Fantasy Grounds feature idea - improve connectivity and ease hosting

[IrishBouzouki]

What if Fantasy Grounds allowed the GM / DM / CK / whatever to be one of the clients instead of always being the host?
Then all you would need for a game is one player, or the DM, that had a suitable internet that was capable of hosting the game. And suddenly everyone in rural America, and elsewhere, would be able to be a DM again. Out of the box. No extra software to install or extra service to pay. And no added security risk above the normal usage of Fantasy Grounds itself.
In fact, a group could choose the person with the best bandwidth to host and the load times and connection stability etc would all benefit, this would be a huge benefit I'd think even for the (majority) cases where the majority of Fantasy Grounds users do not have NAT/firewall issues. In fact sometimes normally solid connections seem to cut bandwidth and impact FG games sometimes, so I think this would be a benefit to a wider scope than just the few rural stuckees like me.
And... Fantasy Grounds could still run just like it does now, a client-server system that does not require SmiteWorks to have server hosting etc. This does not require re-imagining the entire FG architecture as a web-server system like some of its competitors. You get the best of both worlds in a sense.
For that matter, probably, unless there were a better way, the DM/GM could retrieve saved game files in a similar way to how the client Manage Characters can retrieve saved character files.

Anyhow, my idea. I think someone, somewhere *must* have presented this case before now. But it hasn't been implemented to date as far as I know(?), otherwise you wouldn't see all the support questions that you do.
Which is a final point to this idea, currently there is a huge (well, okay, large) amount of support time on the part of the developers, and certainly the very supportive community, over the various connection-related issue aspects of Fantasy Grounds. It would seem to my point of view, and I am an Electronics Engineer who develops software sometimes so I understand the pain of even reading this suggestion, that lessening that support burden would almost pay-in-time for the effort to make such a change? I can really only guess on that account but it certainly should have a beneficial impact to some degree.

Anyhow, that is my idea.
Thanks for taking the time. And keep smiting and working.

[Trenloe]

It's an idea that's been floated before. The issue being that the GM still needs to upload lots of data (even if it's just to a single player who then broadcasts it out). It would ease the data broadcast a little (i.e. 1 set of data, not N sets - where N is the number of players). Other than completely redesigning the FG architecture, this would require a specific player to be connected all the time as well as the GM - and we all know players connect/drop at different times. Plus, the player now has to make sure that their port forwarding etc. works correctly. What if that player doesn't play for one week? Then another player has to be temporarily setup to be the data distributor. Also, if the GM just wanted to do a quick character maintenance/education/one-on-one session with a single player, then the distributor would also need to be online - or a different setup used just for that one-on-one session.

It's an interesting idea, but I think would cause much more confusion and issues than it would solve.

The majority of the support cases you mention are not "I have a slow upload speed" (although the odd issue is related to that), but issues with port forwarding. The issue of port forwarding is being addressed in FGU (the Unity release of Fantasy Grounds - still in development).

[IrishBouzouki]

Well, thanks for the consideration and cogent remarks. Will respond to some points and hope that is not annoying, then I will probably just let it be as I will have exhausted my sparse ideas on the topic.


The issue being that the GM still needs to upload lots of data (even if it's just to a single player who then broadcasts it out). It would ease the data broadcast a little (i.e. 1 set of data, not N sets - where N is the number of players).
Yep but essentially the bandwidth load on the GM is no worse and likely much better.


this would require a specific player to be connected all the time as well as the GM - and we all know players connect/drop at different times.
Okay, but really you kind of have to have one player and a DM anyhow. Nothing really says in this idea that it must always be the same host every session. As long as there is a way to transfer files (which, without thinking too deeply about it, in a lot of cases might not even have to be done via FG although security issues might force it to be so in some or all cases - for instance if the files had purchased IP there might be issues I have not really taken the time to consider).
I think players drop due to GM or player connection issues - having the flexibility to make the host the best connection from among the group would seem to me like it would *have* to ease this.


the player now has to make sure that their port forwarding etc. works correctly.
Sure. But if 90% of players (I suspect the percentage is much greater) have no NAT/port issues out of the box, and only one player in a group has to make sure that works properly, it certainly doesn't seem to be any worse than the DM having to be the one doing that, and has the potential in many cases to be much better.


What if that player doesn't play for one week? Then another player has to be temporarily setup to be the data distributor. Also, if the GM just wanted to do a quick character maintenance/education/one-on-one session with a single player, then the distributor would also need to be online - or a different setup used just for that one-on-one session.\
I was thinking the GM client would update the game files locally at the end of the game (so just once per session) just like it would upload them once per session at start. So the GM still has access to the current game-state offline for edits and updates and everything else. Actually you would really need this in some form, it has been my experience most people do not just run a module out of the box with no changes even if you can in cases.


The majority of the support cases you mention are not "I have a slow upload speed" (although the odd issue is related to that), but issues with port forwarding. The issue of port forwarding is being addressed in FGU
Well, realistically, FGU has been a long time coming and there has been a ton of work required to bring it online and probably still is before then. Smiteworks is probably cursed with the nowdays-universal(?) engineering issues of way too much to do and not nearly enough staff or budget. But a lot of seemingly minor cosmetic and feature changes have come over the bridge in the meantime. Some I am sure are needed to support all the great synergies FG has built with game publishers - it boggles to consider all the requirements to handle all that. Maybe it is just not realistic to suggest any change past some indeterminate degree to the current engine, I can relate to how that must be while they are cranking all-out on FGU, and the "work required" side of any proposition is usually the devil in the details, but hopefully the idea at least merits consideration. I'm certainly also glad to hear that the Unity engine product will resolve this though, even if it will likely be quite some time yet.

Thanks.

[Trenloe]

I feel this is just complicating matters - for the reasons I mentioned before (different players having to host when one is unavailable or late) and also moving to what is a three tier architecture. Now you have GM -> Distributor Player -> Other Players, instead of GM -> Players. Plus Player data changes going back through the distributor to the GM. This has to be real time, it can't be cached and then passed back to the GM at the end of the session. The GM always has to be the master for the data, otherwise there is too great a potential for lost data. This type of architecture only really works if there is a central server storing data 24/7 and then everyone connects to the central server - like Roll20 operates.

In the end, this would be a massive change to the FG architecture (either three tier or central server based). And I mean MASSIVE. The GM always has to the the data owner, as well as running OOB messaging from the client side. So the distributor player must proxy all of this messaging and data updates between the players and the GM. To code all of this for a architecture change whilst keeping compatibility with all of the FG content would be a huge undertaking.

I feel the time and complexity of such a change is really not worth the effort for improving a small percentage of complaints that we hear on these forums - i.e. GM slow upload issues, not port forwarding problems. Most of these complaints go away once the GM is educated on how FG works and best practices for keeping uploads to a minimum.

Its an interesting idea and worth discussing. But I just think risk/work versus reward are not anywhere close to making this worthwhile with the current architecture and upcoming FGU functionality.

[Ken L]

It can be done with a p2p architecture, I did a project before way back when, though the bandwidth was never higher than 2MB/s about 30% of time time was spent verifying payloads and syncing with peers. The 'super node' however had very little bandwidth outside of NAT punch through.

[Trenloe]

You can vote for similar idea in the wishlist here: https://fg2app.idea.informer.com/proj/?ia=40890

[Erin Righ]

I am with Trenloe on this one. In my experience, most gamers who are getting into new games and systems, and platforms are younger/less mature and most game masters are older/more mature. This would greatly increase the expense of the player client, which as it stands, only has to be the free demo, where players would have to have a licence in order to host, so the free client either becomes unavailable or they have to create another level of client over the 3 they have now, and that means dollars out of everyone's wallet/purse. It also means that since each of the books for a system are modules, that the player who hosts must possess, and therefore pay for each book used, and each token pack, and each AP, and each,map pack. And in my experience, player's are often not willing to shell out for the basic player's handbook, requiring instead that the GM have multiple copies available, and simply leaning on the older/more mature player (GM) to get everything required. I have even had players who didn't own their own dice and just borrowed them as they were needed. So now you are going to require player's who, for the most part, are younger, and in less good financial position to shell out dozens of dollars, up to even hundreds of dollars, to own these books in order to host. And then the DM has to have the modules as well because he has to be able to access the books between sessions to do prep work, and if the player goes to his Grandparent's for the weekend (because, lets face it, this is a teenager's game that we old codgers just won't let go of), you need someone else to host, and that person would require to have all the stuff purchased, as well, in order to provide the material hosted, so theywould be shelling out dozens to hundreds of dollars, and while I am sure that smiteworks would LOVE it if we all just shat money into their lap, but in reality, the players would just go over to a less expensive platform and Smiteworks would probably have to cease support on FG, and that'd suck!

Moral is; This is a bad idea!

Just the ramblings of a demented irishman

[not_so_there]

Personally I'd like to see a server version I could setup as a dedicated process then connect to as the owner using the client to dm. That way I could leave it up if players wanted to look at something for the current running campaign, or so I can hop on from any other computer with the client and run the campaign without having to adjust any local network config, it be able to run a game from a place where I can't adjust the network config.

[39Sam]

Personally I'd like to see a server version I could setup as a dedicated process then connect to as the owner using the client to dm. That way I could leave it up if players wanted to look at something for the current running campaign, or so I can hop on from any other computer with the client and run the campaign without having to adjust any local network config, it be able to run a game from a place where I can't adjust the network config.

That precisely, that would also allow me to host the server on AWS or GCP between sessions. Thanks for the link Trenloe, I did vote.

[Valyar]

The issue of port forwarding is being addressed in FGU (the Unity release of Fantasy Grounds - still in development).

How the port forwarding issue is being addressed in FGU?

Separate Server and GM client is perfect, as I can set up server at home and connect to it while traveling (50% of my time...) and still game. This and the dynamic lighting are the biggest features I am looking forward to before I permanently move to Fantasy Grounds from Roll20.

[damned]

Hola Valyar no details as yet.
It is likely to still be a GM server machine but there will be some option for a FG server to handle the session match-making to allow users behind unfriendly routers to still setup connections.
I believe they are aiming to retain the current architecture as well as introduce this alternate version.

[shadzar]

some option for a FG server to handle the session match-making

so you are saying something like battlenet? an intermediary between the players that makes sure all the connecting is done from somewhere outside the host tables computer?

[damned]

so you are saying something like battlenet? an intermediary between the players that makes sure all the connecting is done from somewhere outside the host tables computer?

Im saying "no details as yet".
Purely conjecture based on various bits and pieces.
There are several different methods available on the Unity3D game engine so until SmiteWorks announce details its all guess work :)