Fantasy Grounds Unity engine

[L. R. Ballard]

Well said! While it's true that creating original 3D assets form scratch by professional artists can be expensive, that's not the route to go - unless Smiteworks DOES want to try a big-ticket Kickstarter, in which case they could make a limited set of "stock" models and allow players to import their own.

Thanks! Making "stock" models and textures and meshes is the way I'd launch a big-ticket Kickstarter if I were SmiteWorks.

But as you say, the cost and difficulty of making them has come way down and there are plenty of open source tools to do it. And the amount of community-made assets would likely be quite large after a little time.

Exactly. Again, I refer to the example of Nexus mods. The modded Skyrim game I'm building already has 122 active mods, and I've yet to install SKSE 64 and some mods that rely on that utility. Some of the mods make significant changes to the combat mechanics, enemy artificial intelligence, game mechanics, and so forth. Skyrim came out in 2011, but most of the big mods were out by 2014. Todd Howard and Bethesda gave Skyrim owners an opportunity to create, and modders delivered big.

The same holds with FG. Give modders an opportunity, and the talent will show up.

Yes, there may also be royalty-free stuff available already, or perhaps someone would be willing to license their library to Smiteworks for a small per-sale royalty. My suggestion would be to look for a game that had 3D fantasy models which is not being maintained/sold any more and consider purchasing or licensing the IP. Recycle!

I too would love to see some kind of adventure-creation toolkit available for FG, one that wasn't so cumbersome as the current system and was ruleset-agnostic.

Yup. My only suggestion is that SmiteWorks go for state-of-the-art stuff if and when they make their move. Don't do any big-ticket Kickstarters or make any expensive asset purchases unless or until you've ideally got Skyrim or Witcher 3-level stuff within reach.

If my only option in the meantime were to do little to nothing regarding 3D assets, that's what I'd do. Apart from making a creation toolkit and some baseline 3D assets, I'd wait until I had a moment of vision, until I saw the big opportunity right in front of me.

[ColinBuckler]

I know Unity is a long way off and SmiteWorks will not release any details as such which is understandable.

However, one thing that I think that might be of great use to the community that could be released is some technical specs regarding assets. Such technical specs could include standard format (type/size) of images for use with the new functionality of FG - such as tiles used in the FGU demo. This would allow community artists to create new assets for release as soon as FGU is released with all involved creating to the same specification.

For example images could be png with 100x100 for 1 square as standard sized images. I appreciate that some use 50x50, 75x75, 100x100, 200x200 or even 300x300 - it would be good to have some standards for everyone to work to so that all assets can be interchangable.

The same could be said regarding 3d assets. Type/size... etc.

[Full Bleed]

I appreciate that some use 50x50, 75x75, 100x100, 200x200 or even 300x300 - it would be good to have some standards for everyone to work to so that all assets can be interchangable.

It's a good idea for community artists to work well above and beyond any use-case standard. You can reliably downscale work with much better results than you can upscale them.

I'd suggest producing assets at least 300ppi natively for 2d assets. 2-4x that if you want to be fully prepared for 4k gamers.

[LordEntrails]

It's a good question, i.e. what the recommendations on future art assets should be.

With FGU we will no longer have the RAM issues, but we will always have file size and transfer issues (even if not single threaded like now). So we have two things to consider; file size and RAM usage (as controlled through number of image pixels).

RAM usage:
We certainly won't want to be paying the resource costs for a 1500 pixel size square (5ft sq). But I would think we would want to at least double to 100 and maybe as much as 300 pixels. Now lets think about that.

A 4k screen is 3200x1800 pixels. I guess someone could zoom in so far as to only be seeing one square, but that seems... like a use case not to worry about. 300 pixels/square would give a on screen map of 10x6 squares. That would also allow a standard map to be printed at 300 dpi (a fairly standard printed quality recommendations) or displayed on a horizontal monitor as a game surface at 300ppi (full resolution). Higher than 300 pixel squares is going to provide a very diminishing set of returns. So I'm going to suggest 300x300 pixel squares as the max resolution. Thoughts?

File size:
FGU is not going to change the bandwidth anyone actually gets from their ISP. Hopefully it will be more efficient with file transfer though. So this one is imo much harder to come up with. We can also assume a long term growth in ISP provided bandwidth, but that is going to be localized and erratic as to when it will happen (some people won't see changes for 10+ years).

So, with changes to FG architecture alone, is doubling the file size reasonable? How would 2MB transfers to 6 players be? According to Wikipedia, global internet speed average is 5.6 Mbps. Converting that to MBps is 3.9MBps. So, a little over 3 seconds to transfer 12 MB of data once you reach your ISP.

Of course, that's not the only limiting factor, your connection to your ISP is. 802.11b is generally the slowest method, and it (fortunately) also sees a actual speed of 5.5 Mbps.

But, I'm no network guru and worry that I'm missing something in this evaluation. Especially because I've experiences longer transfer times on 1MB file to fewer players with current architecture than that and neither of those calculations take into effect applications.

So, right now if I had to suggest a file size limit, I would say 2MB. But hopefully someone with real knowledge on the topic will jump in with sound reasoning.

[ddavison]

Upload speeds are normally significantly lower than download speeds for most ISP customers. It is not uncommon for the upload speed to be 1/10th or less than the download speed.

[LordEntrails]

Upload speeds are normally significantly lower than download speeds for most ISP customers. It is not uncommon for the upload speed to be 1/10th or less than the download speed.

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?

[LordEntrails]

Or perhaps a better question for Doug, John or Carl; can we assume that file transfers in FGU will be done in the background? i.e. FGU will not become unresponsive during large file transfers?

[dulux-oz]

Also, Mbps doesn't translate exactly to MB file sizes, because each packet of information has overhead attached to it in the form of packet headers, etc. The "rule of thumb" we were taught in "network engineering" class was 10Mbps is the (rough) equivalent of 1MBps of actual file transfer (or even worse).

[LordEntrails]

Also, Mbps doesn't translate exactly to MB file sizes, because each packet of information has overhead attached to it in the form of packet headers, etc. The "rule of thumb" we were taught in "network engineering" class was 10Mbps is the (rough) equivalent of 1MBps of actual file transfer (or even worse).

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!)

[Andraax]

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...)