How do you handle multiple floors?

[om]

So very much still a newbie to FG and finding my way around. I'm running Alien fwiw and haven't touched D&D so maybe I'd have a better feel for it if I'd played that. But anyway, how do people handle multi-story buildings (or dungeons) when they're making maps?

If I'm playing table top then I just obviously pick a counter up from one piece of paper and put it somewhere else. With FG there are reasons that doesn't work so well. Because I have a building with an exterior that people might walk around I don't want for example three plan views next to each other and a separate outdoor map with just the outline of the building. I can do that but it messes with all the in-built line of site, ambient lighting etc. Or maybe it doesn't and I'm just missing obvious tricks. If I delete a token and place it back I lose token lighting for some reason. But if I drag it around the map I can't actually do that because I hit walls. And if I have the different levels as different maps, does that get messy?

I guess my question is: You're starting from scratch making a home made map of a three story building moderately large, with an outside that gets explored as well. What do you do? Multiple images, place each floor next to each other... Just, where would you more experienced people start?

Thanks in advance! :)

[Jiminimonka]

I usually make one big map with all the floors on it, and let the Line of Sight deal with what players can and can't see.

As GM you can move tokens anywhere you want with CTRL or ALT or SHIFT (I forget which key) so when a player goes up stairs leaving the others downstairs, you can move them to another part of the map. Turning off Party Vision in the Settings will mean the other players cannot see what that player is seeing.

[om]

Oh that's handy. I imagine there are a lot of little tricks like that I haven't discovered, yet. Does it work between different maps? E.g. if I had each floor as a different image? I imagine not.

[Jiminimonka]

Oh that's handy. I imagine there are a lot of little tricks like that I haven't discovered, yet. Does it work between different maps? E.g. if I had each floor as a different image? I imagine not.

You could do that, but you would have to put the player token onto the other map from the Combat Tracker (you can't drag tokens from one map to another without causing issues) and he would then lose all the Line of Sight on the other map (areas previously explored).

[om]

By losing Line of Sight do you mean the ghost images that subtly show where you've explored? Does that reset when dragging onto a new map from the combat tracker and then later dragging back onto the original?

[Griogre]

No it doesn't. Redragging from the combat tracker resets the LOS even on the same map.

[LordEntrails]

One big map with all the levels on it, and each level is surrounded by a wall LOS so LOS does not bleed over between levels.

[om]

One big map with all the levels on it, and each level is surrounded by a wall LOS so LOS does not bleed over between levels.

Ah, so obvious. Put a wall around it so that they're on the image but not part of the map. So obvious! Much simple!

Thanks a lot. And to everyone else who has replied.

[om]

This isn't worth a new thread and is a follow-on question. Are there practical limits to the size of maps? Following the suggestions here I'm going to end up with a very large image - three floors of a large building and then the outdoor areas which have to be large to keep a consistent scale. I was going with PNG but could do anything else. If it supported SVG then I could actually export as that as I'm drawing everything as vector maps, but I'm fairly sure that's not an option?

Also, while I'm at it, anyway to auto import walls in some way? I'm drawing an SVG map of this building and pretty much every line in it is meant to become a wall in FG, barring some doors.

[Trenloe]

Are there practical limits to the size of maps? Following the suggestions here I'm going to end up with a very large image - three floors of a large building and then the outdoor areas which have to be large to keep a consistent scale.
See the guidelines here: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/2037547009/Developer+Guidelines

The guidelines are based off memory and computer performance - you can probably go a bit above this, but the end limit is going to be based on how much LoS, lighting effects, etc. you have on the map and also the lowest spec computer in your group - having a big map with LoS and lighting could kill a lower spec computer - hence the listed guidelines.

[Zacchaeus]

I'd suggest .jpg files to keep the image size reasonable. There's no 'practical limit' really but the bigger the map the bigger the resolution and the bigger the size. The recommended size is 4kx4k resolution and around 2Mb in size. A lot will depend here on your and your players internet connections. The better those are and the smaller the map size, the less time it will take to upload the image to your players.

In addition to the resolution and size considerations there is the fact that a lot of occluders may also affect performance when using the map. Clearly the bigger the map the more occluders.

The advice in this thread I'd suggest is really for a smallish building with a ground floor and maybe one or two other floors like a first floor and a basement. It isn't really a suitable suggestion for say a castle or a manor house with 20 rooms on each floor and multiple floors and a dungeon. For a building of that size then I'd have separate maps altogether for each floor.

[LordEntrails]

There is an extension on the Forge (I don't remember which one) that stores FoW data for maps. So if that is important enough, you could look into that to allow you to remember that between maps if you decide to put them on seperate images.

My biggest concern on large images is not really file size, but number of LOS segments (and number of Combat Tracker tokens). That is really where I see performance issues crop up. Lots of rooms means lots of segments, means lots of calculations, which means slow down.

[MicCheckOneTwo]

There used to be an extension on DM's Guild called Portals Revamped, (it was a Rob2e extension,) which was perfect for this. It allowed the DM to drop hidden portals on the map, which would automatically move the player token from one spot to another when they entered the affected area. So for instance, I would drop one portal at the stairs on the ground floor, and another portal on the stairs for the second floor. When the players "climbed" the stairs, their token would automatically move back and forth across the map to the different floors. You could even make the portals directional, for things like trap doors (so the players couldn't just teleport their token back out of the trap.) But it got pulled from the site (https://www.dmsguild.com/product/323471/Fantasy-Grounds-Portals--REVAMPED) a while back for some reason. Maybe it got moved to the Forge? Not sure... Would be cool to see it officially implemented, (even if it wasn't called portals. Just some sort of automated stairway/trap door functionality) but I guess that would need to go into SW's feature requests.

The big problem I always had with manually dragging tokens around as the DM is that it exposes the entire map's Fog of War when you sweep across it with the token. If I have a spiral staircase in the middle of a maze-like dungeon full of secret rooms and hidden passageways, the player is going to see a lot of the hidden parts of the dungeon as I drag them back and forth to the different floors. What I liked about portals is that it didn't just drag the character around from A to B. Rather, it teleported them directly, so they didn't get any spoilers from revealed Fog of War.

Edit: Found it. It was moved to the Forge. You can find it here (https://forge.fantasygrounds.com/shop/items/123/view).

[Jiminimonka]

If the GM holds whichever key (Alt or Ctrl) when dragging no Fog of War is revealed for that token.

[Zacchaeus]

The big problem I always had with manually dragging tokens around as the DM is that it exposes the entire map's Fog of War when you sweep across it with the token. If I have a spiral staircase in the middle of a maze-like dungeon full of secret rooms and hidden passageways, the player is going to see a lot of the hidden parts of the dungeon as I drag them back and forth to the different floors. What I liked about portals is that it didn't just drag the character around from A to B. Rather, it teleported them directly, so they didn't get any spoilers from revealed Fog of War.

Hold the SHIFT key whilst dragging tokens from one part of the map to the other. This allows the DM to move over occluders and also doesn't reveal the fog of war over the chosen path.

[om]

See the guidelines here: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/2037547009/Developer+Guidelines

The guidelines are based off memory and computer performance - you can probably go a bit above this, but the end limit is going to be based on how much LoS, lighting effects, etc. you have on the map and also the lowest spec computer in your group - having a big map with LoS and lighting could kill a lower spec computer - hence the listed guidelines.

Thanks for that. In this case, I think I have a problem. Potentially a big one. I just pulled up one of my maps that I did and it's around 5000x3500 pixels. Which is more than 4K and I think almost double. Now it probably doesn't need to be that resolution. I'll play with doing it at a lower resolution. Might be able to get it down to half that without affecting the quality as it's just on screen rather than print. But this as I stated is one of my more modest maps and solely indoors therefore on a much smaller scale.

I have a pretty powerful computer and it can handle quite a lot (64GB RAM for a start) but a lot of my players aren't in the same position. I know at least one was joining with a low-ish end Windows tablet. It wouldn't sit well with me to tell any of them that they couldn't play because they couldn't afford to pay the IT toll. I have been paying for an Ultimate licence whilst I found my feet with FG and I figured that the constraint would primarily be the host computer, i.e. mine. But I see now that's a false understanding. I'm not really a host and nobody is - I'm just the one that transmits a large file originally.

As a possible Hail Mary does it make much difference the detail level of the map? My maps tend to be blueprint style floorplans rather than lots of bitmaps. They're huge, but they're sparse. Does that help me at all?

Thanks everyone else for the replies as well.

[Zacchaeus]

I'm not sure that a tablet will run Fantasy Grounds and even if it does FG requires a mouse and keyboard to operate which a tablet lacks. You should certainly do some testing with that player I think.

The 4k suggestion is a suggestion and is guidance given to developers who develop modules for FG. It isn't a hard limit and as Trenloe says above you can exceed that if your and your players systems can cope with it. It's a matter of experiment really to see what you and your players set ups can handle. The size of the file will determine how quickly or otherwise the image uploads to your players; the resolution will possibly affect performance on low end machines if there are a lot of occluders and lights and tokens on the map. The detail isn't important but rather the file size and resolution.

[Trenloe]

I just pulled up one of my maps that I did and it's around 5000x3500 pixels. Which is more than 4K and I think almost double.
4k x 4k is 16 million pixels. 5000x3500 is 17.5 million pixels - so it's pretty much around the recommendation. It's a recommendation and a good yardstick to aim for - so you're in that region. As I mentioned - beyond the yardstick recommended size, the limitations will be your players computers (as yours seems OK, assuming you also have a pretty good processor to go with that 64GB of RAM) - with image size, LoS and dynamic lighting affecting performance.

Detail level won't make a huge difference - it's basically number of pixels plus LoS occluders, dynamic lighting and number of tokens using dynamic lighting/LoS. Check with your players to see how performance is on their end and adjust as needed.

[LordEntrails]

Another aspect to look at in terms of detail is how many pixels per 5 ft square. I generally try to run at 100 (which converts to 20 pixels per foot) and feel this is pretty detailed. But when needed, I drop this to 50 pixels per square and though it is noticeable, it rarely impacts play. Sometimes I even go below that, but it is really noticeable.

[om]

I'm not sure that a tablet will run Fantasy Grounds and even if it does FG requires a mouse and keyboard to operate which a tablet lacks. You should certainly do some testing with that player I think.

Well they said it was a tablet, I haven't seen it. Maybe I misrecalled but it's a Windows device so I think they can manage with touch and on-screen keyboard? Maybe I'm wrong.




The 4k suggestion is a suggestion and is guidance given to developers who develop modules for FG. It isn't a hard limit and as Trenloe says above you can exceed that if your and your players systems can cope with it. It's a matter of experiment really to see what you and your players set ups can handle. The size of the file will determine how quickly or otherwise the image uploads to your players; the resolution will possibly affect performance on low end machines if there are a lot of occluders and lights and tokens on the map. The detail isn't important but rather the file size and resolution.

Thanks. That's good to know. So I've checked and the map I've been using for my current adventure is approx. 3200x5000 pixels. That's as a PNG and is just under 8MB in size. It seems to have worked okay for all of them so far. Those numbers are just for the base image before adding walls or lighting. I'm not sure how those are stored and sent. I think someone mentioned some sort of XML file that I guess includes the base image as a reference?


4k x 4k is 16 million pixels. 5000x3500 is 17.5 million pixels - so it's pretty much around the recommendation. It's a recommendation and a good yardstick to aim for - so you're in that region. As I mentioned - beyond the yardstick recommended size, the limitations will be your players computers (as yours seems OK, assuming you also have a pretty good processor to go with that 64GB of RAM) - with image size, LoS and dynamic lighting affecting performance.

I read it as 4K resolution as in like a 4K monitor, so 4096x2160 pixels. Re-checking the link I see that I did indeed misread it - my fault. It says "<16M pixels" as well so that is indeed 4K x 4K, not "4K". Darn marketing people and their daft terms. *shakes fist*. So by a weird coincidence (there's no such thing), my current 3200x5000 is exactly 16,000,000 pixels. So I'm feeling a little better about it now - thanks. And the planned map I mentioned is as you say just a little over.

It would still be awesome if the software allowed some sort of "hosting" approach where I could serve their screens to them. But, I imagine that would be something pretty fundamental. Streaming does seem to be the way technology is going though and I can see why. So would be awesome if that became a thing one day.

And yes, I have a processor to match the RAM. 12 core 1st gen Threadripper. Ideally I'll upgrade even that at some point when I can justify it. ��



Detail level won't make a huge difference - it's basically number of pixels plus LoS occluders, dynamic lighting and number of tokens using dynamic lighting/LoS. Check with your players to see how performance is on their end and adjust as needed.

Well, it should make a difference to the file size that gets transferred, no? A 16M pixel jpeg image that was all black should compress super small and mine is largely black with blue print lines on it. But I guess perhaps it makes no difference to performance limits outside the speed of transfer?


Another aspect to look at in terms of detail is how many pixels per 5 ft square. I generally try to run at 100 (which converts to 20 pixels per foot) and feel this is pretty detailed. But when needed, I drop this to 50 pixels per square and though it is noticeable, it rarely impacts play. Sometimes I even go below that, but it is really noticeable.

Well the 5000x3500 map I have upcoming is approximately 60 pixels per 5' having just checked and converted from metric. So I'm at your low-end. But then it's probably worth re-emphasizing that I'm running Alien RPG here, not D&D and my maps are basically floor plans. So 50 pixels is going to look the same as 100 when it's black space. To give you a feel here is a tiny snippet of my map.

55597

So that's why I wondered if I could get away with more. Don't get me wrong - I'd love to have everything beautifully drawn with actual floor tiles but it's hard to find something that gives the right feel for Alien. Alien is srs biznes! :)

So it sounds like one of my big issues is going to be the number of walls, door and lights - which is going to be big.

Which actually reminds me of something else - is there a way I can queue up the turning on or off a very large number of lights at once? E.g. a "they cut the power" event?

[Trenloe]

Well, it should make a difference to the file size that gets transferred, no? A 16M pixel jpeg image that was all black should compress super small and mine is largely black with blue print lines on it. But I guess perhaps it makes no difference to performance limits outside the speed of transfer?
Correct. File size only impacts sharing time from the GM to the player. Once it's shared, the number of pixels affects memory use and performance.

[Griogre]

To follow up on all the prior comments to make things easier on players with low spec machines you need to reduce the data their computers need to process. As mentioned the best two way to do that on images is to:

1) Reduce the number of pixels in a square. I routinely use 25 pixel squares. Given how plain you maps are you could easily do smaller than 60. FYI a 100x100 square has 10,000 pixels, 50 x 50 square 2,500 pixels, 25 x 25 = 625 pixels. That's the pixels per square on the map. As most of your map pixels in the sample bit of map are black with no detail you should be able to do this with little QoL effect.

2) Reduce the bit depth of the image. Most art programs and artist make print quality maps with 32 bit color. That is 32 bits per pixel. On a simple black and green map like your sample you can easily go to down to 8 bit color. That would save you 24 bits per pixel or 3 bytes a pixel. While not as dramatic as pixels per square that still would make the 8 bit (256 color) map about 1/4 the size of the 32 bit (millions and millions) color map.

Also, I'm a huge fan of Dungeondraft as a fast and easy to use map builder. There is a script that will do FGU's LOS for you. As you can tell from the name the default assets are geared towards fantasy games, but there are asset packs both free and paid. Here is a link to a video where the artist is building a sci-fi rooms with a free art pack he made for Dungeondraft: https://www.youtube.com/watch?v=byGqEBY0a_g

Dungeondraft is not free, but to me it was 20 bucks well spent - and as a bonus it has a very nice license including commercial use.

Edit meant to add a link to Dungeondraft: https://dungeondraft.net/

[Trenloe]

2) Reduce the bit depth of the image. Most art programs and artist make print quality maps with 32 bit color. That is 32 bits per pixel. On a simple black and green map like your sample you can easily go to down to 8 bit color. That would save you 24 bits per pixel or 3 bytes a pixel. While not as dramatic as pixels per square that still would make the 8 bit (256 color) map about 1/4 the size of the 32 bit (millions and millions) color map.
This only affects the size of the image. While it's a good recommendation to further reduce image size and therefore help with sharing time to the players, this won't have an impact on the memory use or performance once the image has been shared with the players. FGU has its own internal representation of the image once it's been opened, and the original image file format no longer has any impact.

[Griogre]

Generally my understanding was the memory structure of FG in RAM was bitmaps for images. If that is true then the size in memory is affected by the color depth. While Unity might do color compression in RAM it's generally an expensive operation to compress and decompress RAM when you can just hold the uncompressed image.

[LordEntrails]

So it sounds like one of my big issues is going to be the number of walls, door and lights - which is going to be big.
Yes, BUT your walls are mostly going to be big long straight lines (i.e. very few segments), and instead of putting a line on the edge of each wall, try only putting on in the middle of each thick wall. And for curved walls, keep the segments rough, 2 meters or so if you can tolerate it.


Which actually reminds me of something else - is there a way I can queue up the turning on or off a very large number of lights at once? E.g. a "they cut the power" event?
Yes. Put them on layers. You can then turn on and off all the whole layer at one time. Consider using global lighting rather than individual lights where you can. You can turn that all off at once too.

Be aware with lights, if they overlap and you are using a color other than white, you may not get the desired effect. For instance, if you have a 100% opaque light with an RGB values of 200,200,50, then in the overlap region, the corresponding light is 255,255, 100 (it's really 400,400,100, but RGB values get clipped to 255), and your yellow lights now looks more white where they overlap. To "fix" this, reduce your alpha values for the lights or the RGB values (i.e. try 125,125,50 etc).

[om]

To follow up on all the prior comments to make things easier on players with low spec machines you need to reduce the data their computers need to process. As mentioned the best two way to do that on images is to:

1) Reduce the number of pixels in a square. I routinely use 25 pixel squares. Given how plain you maps are you could easily do smaller than 60. FYI a 100x100 square has 10,000 pixels, 50 x 50 square 2,500 pixels, 25 x 25 = 625 pixels. That's the pixels per square on the map. As most of your map pixels in the sample bit of map are black with no detail you should be able to do this with little QoL effect.

2) Reduce the bit depth of the image. Most art programs and artist make print quality maps with 32 bit color. That is 32 bits per pixel. On a simple black and green map like your sample you can easily go to down to 8 bit color. That would save you 24 bits per pixel or 3 bytes a pixel. While not as dramatic as pixels per square that still would make the 8 bit (256 color) map about 1/4 the size of the 32 bit (millions and millions) color map.

Also, I'm a huge fan of Dungeondraft as a fast and easy to use map builder. There is a script that will do FGU's LOS for you. As you can tell from the name the default assets are geared towards fantasy games, but there are asset packs both free and paid. Here is a link to a video where the artist is building a sci-fi rooms with a free art pack he made for Dungeondraft: https://www.youtube.com/watch?v=byGqEBY0a_g

Dungeondraft is not free, but to me it was 20 bucks well spent - and as a bonus it has a very nice license including commercial use.

Edit meant to add a link to Dungeondraft: https://dungeondraft.net/

I'd cheerfully spend the $20 for it if it helps and saves me time. The thing that has held me back from using off the shelf map / tile packs is that none of them have the feel of the Alien / gritty sci-fi atmosphere I want. They tend to be more Buck Rogers style sci-fi. That said, this one looks better than most, I'll give the video a proper watch when I have time. Thank you very much.


Generally my understanding was the memory structure of FG in RAM was bitmaps for images. If that is true then the size in memory is affected by the color depth. While Unity might do color compression in RAM it's generally an expensive operation to compress and decompress RAM when you can just hold the uncompressed image.

Well it's minimal cost to me to export the image in a lower colour depth and I'd have never thought of it before, so no reason not to try. Your logic does seem sound but there will be tokens on the map and these are not simple monochrome but normal full-colour tokens. So it may be that everything needs to be converted to the same colour depth when the final display image is composited? I don't know enough about such matters but occurs to me as a possible issue with the suggestion.


Yes, BUT your walls are mostly going to be big long straight lines (i.e. very few segments), and instead of putting a line on the edge of each wall, try only putting on in the middle of each thick wall. And for curved walls, keep the segments rough, 2 meters or so if you can tolerate it.

I already do this but for other reasons. I unfortunately learned the hard way having created a nice building map with thin lines I then started adding LOS walls only to find that basically the wall is always invisible from one side. The play essentially just walks up against a dark edge with no visible block because the LOS wall is effectively on one side or the other of the actual drawn line. So my new map has much thicker walls with the line going down the centre. Curved walls are a bit of a pain.



Yes. Put them on layers. You can then turn on and off all the whole layer at one time. Consider using global lighting rather than individual lights where you can. You can turn that all off at once too.[quote]

Thanks - great suggestion. I will have ambient lighting but it's only for the outdoor areas (and areas near windows). So your layers suggestion is what I'll do.

[QUOTE=LordEntrails;672454]
Be aware with lights, if they overlap and you are using a color other than white, you may not get the desired effect. For instance, if you have a 100% opaque light with an RGB values of 200,200,50, then in the overlap region, the corresponding light is 255,255, 100 (it's really 400,400,100, but RGB values get clipped to 255), and your yellow lights now looks more white where they overlap. To "fix" this, reduce your alpha values for the lights or the RGB values (i.e. try 125,125,50 etc).

Okay, so this is another thing I noticed with my map. I've done them on a purely black background. You can see that in the sample I posted further up if you want to. What I found with the lighting is that it sort of didn't show things in a way. I'd had in my mind that there would be some sort of glow around the light or the token that had the light. But what I actually found was that the lighting more works like removing blackness over the area where light is. Which works if what is under it is colourful but with a black background just remains... black. I can see the logic behind it but if I want a pool of light I think what I need to do is have something other than a black background. Perhaps a very dark green. Does that make sense?

A killer feature for FG would be if it could use SVG images. Those could be massively smaller than PNGs and JPEGs.