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.Originally Posted by Hussar
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.
Reply With Quote