Map Floors

I would like to have maps with different floors. Each floor would have its own background/token/gm layers. You would be able to see the current floor and everything on the floory beyond the current one. This would make navigation much better and would make complex buildings a lot easier to navigate, espacially for players with small screens. An example map where this would be awesome is this map. Especially battles where one half of the characters is in a yard and the other half is on the walls surrounding the yard are hard to play, as you can't easily measure distances if you have both floors of the map at diffrent locations. Each player should be able to change his current floor. Some GM control would be cool though. Like switching the player floors to the fllor selected by the GM on Shift+Left Hold. What do you think? It would make my campaigns alot easier to use.

A current way of doing that is by drawing multiple maps on the same page. As far as seeing through to the next layer, you could add a degree of transparency to a PNG file using image editing software, if you still want to see the map below. As far as other character/creature locations on the first floor though, the character on the floor above wouldn't be able to see the creatures below?

I just use one map with different floors in their own areas. What your suggesting sounds cool, I'm just afraid of the memory requirements.

Why should it use more memory? If you have 10 floor à 20x20 tiles it is the same as one floor à 20x200 tiles, what you would need to place the layers next to each other. Also you don't have to use it, if one of your computers is to weak the GM can simply do it the old way. The problem would be that you would need to have some algorithms to determine if a characters life bar/name should be shown depending on if he is visible or if there is something above him.

Manuel , in rough terms, in Roll20 all images currently (fully or partially) on your screen are processed by your video card. Images not currently on the screen are not processed. So if you have ten 20x20 images on the screen at one time they will all be processed while if you have ten 20x20 images on the map but only four are on your screen then your computer is only processing four of them.  Because of this very large maps or a lot of large map tiles currently on the screen can cause a processor to have fits on some computers. Having this many maps being shown simultaneously would probably cause people's computers to slow to a crawl inside Roll20.  Edit (response to your edit): even on computers that are not 'weak' this can cause problems. I know of some computers that, while they have very good video cards, have issues with large pngs etc. Most computers would probably have an issue with this type of setup. However, I am not a Dev and I do not evaluate suggestions. - Gauss

Mh. Okay, but that doesn't seem right. What is so taxing for the system? It's just showing some images. I mean my systems is able to play this demo with 2000 fishes at 60fps without taxing the cpu much. Okay, I have a high-end system. But d20 is at the end just a composition of a few dozen images that don't move at all (although a very very cool composition^^). And you can't say that big images are a problem. Games use textures 2048x2048. Dozens of them on the screen. And modern browser/javascript library combinations use OpenGL exactly like games. So you should be able to run this. Maybe some of the algorithms are not that efficient?  E.g. I recognized that the fog of war seems not to be one polygon that is a combination of all modifications but is handled as a mass of polygons that overlap each other? Maybe the system could be made a lot more efficient to allow for more than one floor?

Video games aren't an accurate depiction here. Roll 20 is effectively a photo editor, similar to Photoshop or GIMP. A "few dozen" may not seem like that much but it is more then it seems considering how programs like this operate; you have the main layers, then you have sub layers (each containing one image) which are positioned around the page. When you are zoomed in, Big images ARE the problem because you have to load the entire image. If Roll 20 were to add what you want, the best it would likely do is allow more layers and maybe allow the DM/players to adjust transparency and/or permission to view of certain layers. Granted, adding something like this would be a massive addition that many players would love. *cough*HINT TO ROLL20*cough* While some algorithms are not as efficient as they could be, many things (like the fog of war) are coded to be efficient on smaller, weaker computers since most people don't have a gaming computer at their beck and call. In many ways, becoming "more efficent" would reduce flexablity.

And p. said: Video games aren't an accurate depiction here. Roll 20 is effectively a photo editor, similar to Photoshop or GIMP. A "few dozen" may not seem like that much but it is more then it seems considering how programs like this operate; you have the main layers, then you have sub layers (each containing one image) which are positioned around the page. When you are zoomed in, Big images ARE the problem because you have to load the entire image. Roll20 is more like a vector image editor. An empty layer is not represented by an transparent pixel grid that must be rendered. It should make no difference for the rendering speed whether two objects are on the same layer or different ones. In that case roll20 is more like a game. It has to render a lot of images with a given depth and has to be as fast as possible in doing it. It could thus use the common optimizations from game rendering engines. I see that a really big image could give you problems. But roll20 has some special knowledge here. It knows how big (10%-150%) the image can be shown. So if you have a big image that is displayed only as a small part of the scene roll20 uses a scaled down version. I think Roll 20 does that already. In the same way if roll20 knew that it has to show a big image over a large area (possibly larger than a screen) it could help to tile the image (google maps style). This would allow clients to only download/render the parts that are really needed. And p. said: While some algorithms are not as efficient as they could be, many things (like the fog of war) are coded to be efficient on smaller, weaker computers since most people don't have a gaming computer at their beck and call. In many ways, becoming "more efficent" would reduce flexablity. I do not understand what you are trying to say here. The efficiency of an algorithm is given by its speed and memory consumption. If you have a more efficient implementation it is not more efficient on fast computer but worse for older ones. The algorithm would anyways do the exact same thing, so what flexibility is lost if you find a better algorithm?  The discussion is a bit mott though without the opinion of someone who actually knows the code. I personally love the optimize algorithms, so mayby I got a bit carried away from my simple feature suggestion^^

at least 1/2 of the code for Roll 20 is stored in page source, so if you think something can be made more efficient I'm sure they would love to see an email with your suggestion for exactly how to change the code. If someone with more knowledge of the code speaks up, I would, obviously, concede to them.

Manuel said: The efficiency of an algorithm is given by its speed and memory consumption. If you have a more efficient implementation it is not more efficient on fast computer but worse for older ones. The algorithm would anyways do the exact same thing, so what flexibility is lost if you find a better algorithm? Algorithmic efficiency is determined by the algorithm's resource usage , where the resource(s) in question are arbitrarily chosen by the people deciding whether the algorithm is worth utilizing or not. The resources don't necessarily have to be speed and memory. Power consumption is sometimes considered, and transmission size/response time are both important factors for algorithms operating on the web. (Roll20 does chat with its backend server, so there's that consideration, certainly.) I'm sure certain individuals in the world have other criteria, as well. A "more efficient implementation" (not a strictly defined phrase to begin with) is also not necessarily more efficient on all machines. Many algorithms, especially those which operate at low levels, are optimized for specific hardware. An algorithm designed to run more quickly on a vector processor or utilize the capabilities of a parallel processor might , in fact, lose efficiency or possibly even fail on another machine. There are actually quite a lot of implementation factors which -- in high-level computing -- are entirely dependent on the compiler or interpreter... and there are often multiple versions of the compilers/interpreters, whether designed for different operating systems/browsers, different hardware, or simply written by different groups of people. I don't pretend to know exactly how Roll20 is implemented, although I do feel I know more than the average Roll20 user. (I've spoken with Riley about some of it.) However, if Gauss says something might cause a system to chug, I'm inclined to believe him. A friend of mine is working as an adjunct professor at Rice University right now. He's working on figuring out parallelism on crazy parallelized (is that a word?) machines. Your gaming rig has, what? 4 cores? 8? I'm talking about hundreds or thousands of parallel processors. I guarantee that the code he writes to be efficiently paralellized on those kinds of monstrosities will not be efficient on your computer.