*** May Super Challenge - Minimalist for Virtual Tabletop - WITH PRIZES!!!

[trevor]

Y'see this is the crux of the problem I think we all don't understand. On the big map image are the bits that don't move and you put the tokens on top which do. Surely, once the map has been sent once, then all the updates are token moves and not full map image resync's. The amount of bandwidth which pertain to the actually changing bits of map ought to be near zero - a few text file updates. Take screen monkey for example which is a pure browser implementation, you would have to resend the HTML page every change to the map but the images for it you would have cached from the last time you looked at them. From the perspective of the MapTool crowd the only time you send a new image is if that image has never been sent before and if an app was extra clever it could low rate background send the images that are likely to come up before you need them so that they are ready when you turn the corner.

I think whats getting a few people a little (unnecessarily if you ask me) hot under the collar is the idea that the 75Kb (or thereabouts) is a general restriction about how things must be in order to use a VTT.

75Kb is an awful lot of data and many old PC games use to use dial up and play multiplayer like Neverwinter Nights for example and these were real time games which is a much harder proposition than what a VTT must provide. I would say quite confidently that it would be possible to run a VTT game on 1Kb bandwidth connection for the map updates.

The 75Kb limit has made for a great challenge this month tho and I have enjoyed the task of getting something technically right as well as artistically. Given that my artistic skills are way behind the guys here I welcome it as a means of leveling the field a bit for me.

Edit --
I disagree entirely.

Perhaps it is worth making the point clear then. I thought that it would just be assumed otherwise.

As the developer of MapTool, I concur with redrobes 100%, he's spot on.

As for the 75k limit, although artificial it brings a great deal of value. Already it's brought up awareness that images have a size. Many times users try to use images that are 10-15megs and wonder why it's really slow to transfer, or takes up so much memory. They didn't realize that the pretty picture they made in photoshop has a proportionate file size, and those files have to be transfered to all clients in one way or another. So I think it's great that people are becoming educated about file sizes, because they _do_ matter in a VT, even if 75k is a bit overkill.

Additionally having the 75k limit, as noted previously, separates the Masters from the Weekend Warriors, as it were

[RPMiller]

Thanks for the info Trevor! Very valuable. Do you have a recommendation for a reasonable larger file size for most VTs?

[trevor]

Thanks for the info Trevor! Very valuable. Do you have a recommendation for a reasonable larger file size for most VTs?

Now that the 75k hard limit has opened the door to the fact that images have size, we can look at when that size is important.

There are really two factors of image size: transfer time and memory usage.

These two factors have a different amount of importance depending on the context in which you expect to use the image, of which there are two extremes: face to face, and everybody over the internet (specifically, not LAN play).

Face to Face
In face to face, either projected or everybody is on the LAN, the transfer time is not important and can be ignored. So a 10meg image file is no problem.

As for memory usage, it relies entirely on the capability of the hosting machine, so you can run as much as you know you can handle.

Over the internet
This is where transfer times come into play. Each client needs to download all the images necessary to see the map. Typically this is a one time hit and the image is then cached locally. The actual transfer time and impact to the VT is dependent on how the files are hosted. At worst case the files are served only by the VT, which means that it has to upstream the image to each client, often concurrently. This can cause long wait times.

Memory is also an issue. You may have configured your system to accept larger memory consumption, but your connected players may not have, and so you may inadvertently overload their memory allocation and crash their program (or at the very least, not show the map/images)

Other considerations
Even if you expect to play f2f all the time, you never know when one of your players will be home with a sick kid, and want to play remotely, so your game type can change on a moments notice, so it's a good idea to take a middle ground on file size, even when you expect f2f only play.

This also goes for content providers who write campaigns, they can't anticipate which type will be used. For quality purposes they might lean on the side of larger, higher quality images, but should still keep in mind the above considerations when choosing an overall image size approach.

Another thing to consider is the target VT. Some VTs handle images differently, in that maps can be composed of smaller pieces, which result in larger maps and smaller image sizes. Some handle large images in memory very well while others don't. If you are making something targeted you can be more selective on the image size.

Also keep in mind that the background map is not the only image that has to be considered. Once the main map is transfered you have to transfer all of the token images, any stamps, and all other images related to your map (this often depends on the style of map and the VT). So if you create a 200x200 pixel per cell map, you will be tempted to create all of you tokens at 200x200 so they look good. And this might be OK, again depending on how many tokens you have, and your type of play (f2f vs remote).

So what file size ?
That's up to you and the style of play you expect. That said, I think that given the availability of broadband, I think a good middle of the road size is probably between 500k and 1meg. That can represent a very large, high quality map, and has fairly good transfer times. Often if you need something bigger than that, you can break your map into different encounter files which can be loaded independently. Some VTs will let you stitch those pieces together, while the ones that don't are still supported.

The important thing
The important thing is to be aware of your total image resource footprint, and tailor it to your situation, or to the situation of your target audience.

[RPMiller]

More really great information! Repped!

[Hussar]

As I said, I'm not too technical in my knowledge of the programs. I just know what works. Having had a number of players with dial-up, the best I can usually expect, using Photobucket to host my images, is about 300 k as a background image. If I get over 500k, I might as well go make a coffee 'cos it's going to take forever to get everyone's maps synched up.

Yes, the base map might only be loaded once, but, it's still sitting there in the cache, taking up memory. Add 10 minis, then start drawing on the map using the pen tools, maybe labelling the map as well, and it can really start to strain older machines.

To be fair, I totally agree with Trevor in that 75 k is REALLY small. But, then again, smaller is always better, so long as it looks good.

[trevor]

Keeping in mind the machine capabilities of your players is definitely an important factor.

Out of curiosity Hussar, which VT do you use ?

One more thing that I forgot to mention, the file size is related to, but not directly tied to the in-memory size. That's another important thing to keep in mind. Depending on several factors you could have a 4000x4000 map and a 1024x1024 map have the same file size, so the tempting thing is to convince yourself that since your 4000x4000 map is as small as a 1024x1024 that it takes the same amount of memory to show. That is not correct.

Regardless of file size, your image has to live completely uncompressed, in memory. That means you multiply the width by the height by 32 (the most common pixel depth, 24bit + 8bit alpha) divide by 8 (to get number of bytes) divide by 1024 (to get the number of kbytes) divide by 1024 (yup, that's twice) and that's the number of megs your image will take in memory, again regardless of file size. This is one other thing to keep in mind when creating maps.

Calc in short:w * h * 32 / 8 / 1024 / 1024 = num of megs an image takes in memory

[Hussar]

I've been using OpenRPG since 1.5. I've been toying with MapTool, but, mostly lethargy and laziness has prevented me from taking the plunge.

Cool, never realized that Trevor. That does explain some of the issues I think we've had in the past though.

[Robbie]

Just a reminder...Get your final entries in!!! Contest closes mid-day today CST.

[torstan]

It's an amazing selection of entries. Good luck everyone!

[rpgmapmaker]

It's an amazing selection of entries. Good luck everyone!

I agree!!!
Man... I loved watching the maps in this month’s challenge develop.

Good luck to all

-Chris