View RSS Feed


Sidebar: Mapping Scale - Size does matter! (Part 1 of 2)

Rate this Entry
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...

Submit "Sidebar: Mapping Scale - Size does matter! (Part 1 of 2)" to Digg Submit "Sidebar: Mapping Scale - Size does matter! (Part 1 of 2)" to del.icio.us Submit "Sidebar: Mapping Scale - Size does matter! (Part 1 of 2)" to Google Submit "Sidebar: Mapping Scale - Size does matter! (Part 1 of 2)" to Facebook Submit "Sidebar: Mapping Scale - Size does matter! (Part 1 of 2)" to Twitter

Tags: mapping, tokens


  1. Minty23185Fresh's Avatar
    I really enjoy your blogs, they're well written, concise and informative. I typically come away from them with ideas for improving my DM skills and the experiences of my players.

    Your explanation today of upload speeds was wonderful. I'd never considered that I was the bottleneck in how long it takes my players to receive an image or map. I host "canned" campaigns so I have little control over file size (I think?).

    I usually ask one of my players to "host" the VOIP (make the call to everyone). It seems to help a little. I usually have my VOIP connection over my iPhone instead of the PC, it allows me dettachment from my PC but still remain in-game, to get another drink or whatever. But I force internet data instead of cellular data, so I'm not saving on upload there!

    I too have run into the 10,000 character blog post size limit, a bit annoying to say the least. I find the new "I am not a bot" scanner particularly troublesome.

    Keep the blogs coming.
  2. Phystus's Avatar
    Thanks for the kind words, Minty!

    I have one of my players host the VOIP too, but anything I say (or my wife says, since she's on the same internet connection) uses upload bandwidth. I hadn't considered running it on my phone. I'm not sure how much data that would consume, I have a pretty sparse data plan so I'm not sure if that would be a problem or not.

    I think you're kind of stuck with image sizes in canned campaigns. I guess in theory you might be able to unzip them, manipulate the images and re-zip them, but it would be a pain in the butt. I don't know how possible that is with the WOTC stuff either, I think there's some sort of copy protection on those.
  3. Phystus's Avatar
    You probably already know about preloading maps, but just in case other folks aren't aware of the option I feel like I should mention it. Rather than waiting until you're ready to show the map to your players to share it, you can preload the map as soon as everyone is signed in for the session. This causes FG to upload the map to everyone in the background, but doesn't open the map window in the player sessions. Once the map is preloaded to everyone it opens almost instantly when you share it. It makes using big maps a lot less painful as long as you remember to do it.
  4. Minty23185Fresh's Avatar
    "Preloading" - Ha, ironic, I thought about asking while I read your blog then forgot to ask. Thanks for the tour down mind-reading lane! So it really occurs in background? I thought it occurred post-logon, but pre-session, thereby delaying the session until all pre-loads loaded up. But background, that's nice - I'll have to give it a go! Now if I can just borrow your mind reading spell - my players always head in the exact opposite direction that I have prepared myself for!! I'm sure to preload the wrong maps.
  5. Phystus's Avatar
    Sorry, my mind-reading spell has a range of "Personal".

    But that's another good argument for a big map - whichever way the party goes, they're on the same map!
Dungeons & Dragons 2024 Core Rulebooks Pre-Order

Log in

Log in