Fantasy Grounds Unity engine

[Ram Tyr]

In the future residential customers may be fighting off residential data plans from ISPs with data caps... so... controlling / limiting the increase in data for FG does have potential for value. (In a world with caps the software that does the job with the least impact on the cap will have a competitive edge.) By the way, outside of the USA I understand there are plenty of people living with residential data caps.

We might also be looking at a future where more people might be interested in using FG over a mobile network (using the phone as a hotspot)... and where the network could handle the data if FG controls / limits the increase in data required.

Just to be clear, I am not saying that the amount of data should not increase... just pointing out that there are good reasons to consider not just opening up the floodgates to the highest flow that will allow a good user experience in the utopian dream of our future internet connections! Now I don't claim to be a networking guru, so perhaps these things would not matter if we are working within the limitations discussed in the above posts, but just in case... something to keep in mind.

[dulux-oz]

Google told me 10 Mbps was equal to .7MBps, so that's more conservative than your rule And why 5.6Mbps only equalled 3.9MBps.

(Nanny Nanny Boo Boo! Not often I get to be more conservative than Dulux!)

Depends upon the number and size of the individual files - but yeah, 0.7 works just as well (& and I did say "or worse") - and 5.6:3.9 is 10:7, not 10:0.7. You're out by a factor of 10.

(Nanny Nanny Boo Boo! Not often LordE gets his maths wrong! Oh, wait...)

[Frunobulax]

I knew I was missing something! So that would put the theoretical case at about 35 seconds. Long, and probably about the limit of most people's tolerance/acceptance.

Is there something else to be thinking about?

I could be more helpful if I knew more about the internals of FG, when and how it downloads things, what it downloads, how frequently, etc. Most importantly, does it cache files locally? That makes all the difference. If I join a game and I have to wait a long time to download a bunch of big assets, but only the first time, that's one thing - I can live with that. If it has to happen every session, but only at the beginning, that's more annoying but minimally acceptable since I know ahead of time and can plan for it. The worst case scenario is having the whole game slow down intermittently if everyone has to wait constantly while large assets load during the game. So, the best general advice I can give is: cache, cache, cache! Maybe have a setting for cache size, or (in a perfect world) have a user-adjustable, per-adventure adjustable cache size with a reasonable default for people who don't care.

[Frunobulax]

The biggest indicator of file transfer after actual *upstream* bandwidth (as indicated by Doug) is network latency. High network latency can make the upstream bandwidth seem significantly slower than it actually is (because the error check packets take so long to get back to the sender...)

I know this almost certainly won't happen, but just to throw it out there: one solution for this might be, instead of streaming assets peer to peer (GM -> Player) perhaps have some of them (the stuff that comes with a purchased module) be online in a "Smiteworks Cloud" and download to players from there.

I'm sure Smiteworks wants to maintain a cloud or online services like it wants a hole in the head, but there are a lot of way it would be super cool - we could have an automated player matching service, chat rooms, voice servers and hosted game servers (for a small fee), that kind of thing. But really I'm just thinking out loud, I don't expect that to happen.

[Bidmaron]

FG does a crap ton of caching. Say what you want about the single-threadidness of FG but I am astonished at how well the program manages this. There is no where I know of to go read about it though. I have just been around for a dang long time and monitored or been a part of discussions regarding caching.

As for cloud-hosting data that is a whole 'nother level of problem that probably is not Worth the agony to properly and efficiently implement. For local lan-based games like some people play, it wouldn't even make any sense. Also for games where only one person is remote it would actually harm performance. And if you stop to think about it how would FG know whether to cloud share? It would have no way to know that the one remote player is about to be joined by a second unless you had the GM flag at start of session whether he wanted cloud sharing enabled for current game.
There are much more productive uses of FG programming time than trying to cloud share in my opinion....

[Full Bleed]

I hate to use examples from another VTT to discuss this... but there is no way around using actual experience rather than using theoretical experience to discuss something like this.

When running Maptool (64 bit) you don't have all the file size and memory issues that you currently have with FG. When FGU arrives, you won't have those problems either. That alone will be a huge improvement to the user experience. And you will find yourself using assets that conform to your own sensibilities and use-case.

For example, the world map I use in my Maptool Greyhawk campaign is 9500x7000 pixels. It comes in at 66 pixels a hex (my primary limitation is the source file). It's a 9MB jpg file. To put it in perspective: If I size that map down to the current suggested max FG map size (2000x2000) the file size would come it at 1/10th the size and it would be pushing 16 times fewer pixels (i.e. a lot less memory!) I've also removed location icons and city names from the map and turned them into independent images that overlay the map that, when clicked on, bring up notes and information. That means that in addition to the giant base map there are about 150 additional image assets on the map. Of course, the map "looks best" at 100% zoom. The other assets have enough resolution to "look perfect" at up to 150% zoom (since I used higher resolution for them).

Using HD resolution that means that around 34 x 17 hexes are shown at 100% zoom (full screen.) And it alone uses around 1GB of memory.

THAT is the sort of thing you'll be able to do, and will be doing, when FGU is here. So all this hand-wringing about file size and internet speeds will be corner-cases. Most people will have plenty of space, memory, and enough internet speed to handle the significantly larger images they will *want* to use.


Now, I focused on that overland map because it's one of the biggest I currently use and I think it illustrates things pretty clearly. But, in general, I like to use 100-200PPI for my tactical maps and 250-500 dpi images for objects players interact with (like their tokens and other things on the map.) That's 2-4 times what we generally see in FG today.

FGU will not just be an incremental improvement in this area.

[LordEntrails]

...
THAT is the sort of thing you'll be able to do, and will be doing, when FGU is here. So all this hand-wringing about file size and internet speeds will be corner-cases. Most people will have plenty of space, memory, and enough internet speed to handle the significantly larger images they will *want* to use.
....

Able to do and what is recommended for most use cases will never be the same thing. We will be doing those things with FGU. And people push the current suggestion today. But most of them do it knowing they are pushing a technical limit and not a performance limit. With FGU we will probably not have a practical technical limit, but there will always be a performance limit.

There will still be a strong argument for best practices. And best practices are always more for distributed products than personal products. i.e. when someone publishes on the DMsGuild, or purchases a new WotC or other product from the FG Store, what file sizes and resolutions should they expect there?

For instance, if I bought an FGU module should I be ok with it if it takes ten minutes to share the map with all 8 players in my campaign because the map is 15GB in file size and looks awesome if I zoom into a single square/hex? For a one time campaign map sure, for a battle map, for a NPC portrait, for a scene? Don't think so.

You are right that FGU will not be an incremental improvement. It will go from doing what is Possible to what is Practical. Current recommendations are mainly based on what is possible, it will be nice to change that to making recommendations based on what is practical.

[celestian]

For instance, if I bought an FGU module should I be ok with it if it takes ten minutes to share the map with all 8 players in my campaign because the map is 15GB in file size and looks awesome if I zoom into a single square/hex? For a one time campaign map sure, for a battle map, for a NPC portrait, for a scene? Don't think so.

I'm a former Maptools user and I can say that even with 45 meg it never took 10 minutes. 1-2 minutes at most when dealing with a player with a really terrible connection (and one of my players plays via satellite connection). When you're coming from FG where current recommended size is 1meg and 2048x2048 that's a huge improvement.

15GB is a bit ridiculous no matter what tool you're using. Even that 9000x12000 Chult map that was recently released was only 35meg.

[LordEntrails]

I'm a former Maptools user and I can say that even with 45 meg it never took 10 minutes. 1-2 minutes at most when dealing with a player with a really terrible connection (and one of my players plays via satellite connection). When you're coming from FG where current recommended size is 1meg and 2048x2048 that's a huge improvement.

15GB is a bit ridiculous no matter what tool you're using. Even that 9000x12000 Chult map that was recently released was only 35meg.

Don't get me wrong, I am happy huge improvement are coming. Orders of magnitude. But there are still going to be practical limits. Yes 15GB is ridiculously large. 1MB will be ridiculously small. That means their is somewhere in between (or a range) that isn't. Something that will be recommended for most use cases. That's what I think is what should be discussed.

[celestian]

Don't get me wrong, I am happy huge improvement are coming. Orders of magnitude. But there are still going to be practical limits. Yes 15GB is ridiculously large. 1MB will be ridiculously small. That means their is somewhere in between (or a range) that isn't. Something that will be recommended for most use cases. That's what I think is what should be discussed.

Well, without having FGU to test things we can only speculate but if it's like Maptools in this regard then it's purely up to what the players at that table are willing to accept. I think having values now makes sense due to the erratic behavior of the client if you go above a certain size/scale.

Now it could just be a "anything greater than 50 meg is going to take time for clients to download" instead of "1 meg and 2048x2048" or clients will crash.

All of this is just guessing as is since we don't actually have it yet to try. Maybe it will have issues >50 meg because of some other reason...