Phystus

Today’s entry isn’t specifically about my group’s journey from a physical tabletop, to long hiatus, to a virtual tabletop with Fantasy Grounds. But my last post about tokens raised some points about scaling that I wanted to explore further. This will be a long post, so get something to drink, settle into a comfy chair and let’s get started.

If you frequent the Fantasy Grounds forum, you’ll see people discuss map size from time to time. Usually the discussion centers around the size of the file, i.e. how many kilobytes of storage the map consumes. The consensus seems to be that the file should be less than one megabyte, and preferably less than 500 kilobytes or so. My experience bears out that this is a good idea, though if you have a fast internet connection and remember to pre-load the image you can take some slight liberties with that.

But there are two other connotations to “map size” that also bear some thought. First is the scale: how many pixels to the square? Secondly, how many squares should the map depict? Both of these considerations have an impact on file size, and both have other implications as well. Let’s take a look at each of these considerations in turn.

I’m going to couch my post in terms of a tactical map, as used in D&D. This would have a scale of 1 inch = 5 feet if printed on paper. Some systems may use different scales, or different grids (one 30mm hex = 2 meters, for example), but the same principles will still apply. They will also apply to your campaign world maps, images of important NPC’s, and player handouts. So if you’re not into dungeon delving please try to ignore the D&D bias and read on, because what I have to say should still be useful to you.

File size

First, let’s look at the question of file size. Why should the file have to be small? There’s a couple factors at work there. Unfortunately the explanation gets a bit technical, but I’ll try to keep it fairly simple. No doubt someone with more networking savvy than I would have a better explanation, but hopefully this will make sense to non-IT folks.

First, for most people’s internet service, the upload speed (the speed at which a file can be sent from their computer to another computer on the internet) is only a small fraction of the download speed (the speed at which a file can be sent from another computer on the internet to their computer). For example, my upload speed is around 5.5 MBPS (megabits per second), but my download speed is 55 MBPS, so I can download files at ten times the speed I can upload one. For most users, this is fine, since the traffic is mostly going from the web servers to their computer, and not the other way around. But in the case of FG, the GM’s computer is the web server, so the upload speed becomes important.

Furthermore, when I share a file with my six players, I’m sending the file not once but six times. So you can multiply the file size by the number of players to see how much data you’re sending. In my case if I share a 1 meg file I’m really sending 6 megabytes of data.

So you might think that would mean it would take about 9 seconds to send that file (8 bits per byte times 1 megabyte times 6, divided by 5.5 megabits per second). But that isn’t really how data transmission works. What really happens is that my computer contacts one of the player’s computers, they each establish identities and so forth (a process called handshaking) and then sends one packet of data. It then handshakes with another computer to send the same packet, and so forth. The receiving computer checks the packet it got to determine if it got garbled, and if it did it requests a retransmission, in which case my computer has to send the same packet again. All other things being equal, the more packets I have to send, the more will be garbled, and have to be resent, perhaps more than once, which reinforces the argument for smaller files. All this handshaking eats up some of the bandwidth, and while my computer is waiting for a response from one of the player’s computers it isn’t transmitting anything at all, so more time is lost.

Meanwhile, there are other users of my upload speed as well: my VOIP software has to upload my speech to the other players, and background tasks on my computer may be sending queries to their vendors to see if there are software updates to download. And any other computers, phones, tablets, etc. that are using my internet connection are using some of the bandwidth too. Since my wife is one of my players, and she’s got her own VOIP connection, some of my (err... our) upload speed goes to that as well.

The end result is that the upload speed you experience will only a fraction of the theoretical upload speed of your connection. So a file that might theoretically be sent in 9 seconds might take several minutes in actual practice, and the players will be staring at a blank map until the upload finishes, which of course is wasted gaming time. Small is beautiful when it comes to the file size for your map.

Map Scale

By map scale, I’m referring to how many pixels it takes to make a square on the map. Naturally, the more pixels you use, the more detail you can show, but the larger the file size. And because you’re dealing with an area, if you double the width (in pixels) of a square you quadruple the file size.

Of course, you also gain four times as many pixels with which you can depict the contents of that square. And here we being to delve into questions of preference. Some people seem to strive for nearly photo-realistic maps, where you can see the individual leaves on the trees, and whether the silverware has been properly placed on the banquet table. If that describes you, then more pixels per square is your best bet.

Other people, (myself included) take the view that fine details are more likely to serve as a distraction than an enhancement. A discussion mid-battle about whether a tree is an oak or a maple, they feel, doesn’t improve the battle experience one whit, particularly if the DM had thought of it as an apple tree, or simply didn’t specify or care what species it was.

The other consideration for the pixel size of a square is the pixel size of your tokens. While it’s certainly possible to use a scale different from that of your tokens, if you do so you need to perform a re-scaling when you place the first token. It’s not a huge nuisance to do so, but it’s one more step that stands in the way of starting the battle.

Edit: I just found another way size matters! The blogging software is telling me the post is too long. So I'll split it here. To be continued...