Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account
This post has been closed. You can still view previous posts, but you can't post any new replies.

Map Developer looking for VTT support

1375812731

Edited 1375817712
We're in the process of creating a high quality map pack with almost 60 general-purpose battlemaps. We've had dozens of people asking desperately for VTT / Digital only versions (we print high quality paper battle maps, with UV coating or lamination). While I'll certainly provide anyone buying the maps with .pdf versions, what I'd really like is someone who's already an expert on VTT to work on porting all of these maps over, and creating a "perfect" VTT ready map pack. This means pre-making a series of correctly sized grids, creating fog of war tokens, night/day versions, or whatever the community would think is ideal. In exchange, I can offer a lot. Specifically, 100+ amazing maps free of charge, direct input into what maps we create next, and promotional copies of our upcoming products, or just pay you as a straight commission. I want to offer a VTT version, and I want it to be far better than "just" a plain digital copy. I think the community itself is the best place to look for skilled VTT users, and also to ask what all the helpful features would be. Please respond if you're interested, OR if you have suggestions of things you would like the ultimate VTT pack to include. To give you an understanding, here is a link to some of our current maps in an imgur album :&nbsp; <a href="http://imgur.com/a/ZLpyc" rel="nofollow">http://imgur.com/a/ZLpyc</a>
To be honest, most people prefer gridless maps for use with virtual tabletops.
Here's what I would want... Gridless At a minimum of 105 pixels per "inch" (that way when we resize it down to 70 pixels per inch... it still looks good if we zoom in to 150%) By "inch" I mean what would be considered a 1" square on the printed map. So if you made a map that was 20 squares by 20 squares, there would be at least 105 pixels per inch. Roll20 uses 70px per square... so 105 pixels would be 150% of that and would still look good when zoomed in.
1375817267

Edited 1375817994
Now, help me understand how these elements "exist" on a computer. Wouldn't each of these grids be seperate files, on top of the map file, and you load / don't load whatever you want? Shouldn't we create a large series of grids? The GM certainly would want a grid less version, to create his own grid, but most of the grids he "would" create should also be provided in addition? I can also export it at multiple sizes, so they don't need to resize it themselves at all, but they can import the correct version. We should provide all these things I'm thinking, anything that would make it easier.
1375818270
Gauss
Forum Champion
Joshua W. , here are some of the aspects to Roll20's grid system.&nbsp; 1) Optional use The Roll20 grid can be turned on and off. 2) Snap to Grid The Roll20 grid is used to control placement of elements such as tokens. When you place a token it snaps to grid.&nbsp;you can also ignore the snap to grid function by holding down the ALT key when moving a token or other image.&nbsp; 3) Alignment Roll20 has an align to grid function which changes the map size to fit the grid. However, some maps have uneven grids which makes that more difficult. For ease of use some people prefer a map that is already set to 70px by 70px per grid square (the size of Roll20's grid). Then all they have to do is set the dimensions of the map in Roll20 to the native dimensions of the image. 4) User preferences Some users would like a gridless map in order to not have to worry about aligning the map to grid. Others want gridless because they do not use a grid at all. Still others want a gridded map and the Roll20 grid overlay but need them to line up.&nbsp; If you would like more information, feel free to ask. We can also make an appt and I can show you how Roll20's grid works.&nbsp; - Gauss
1375892515
Kevin B.
Marketplace Creator
Josh, if you need further help figuring this out, I may be able to devote some time in working out any details you're curious about. Send me a message and we'll work out some details. I'm quite verse with Photoshop and can help with resolution and help explain what you would need to do to move this forward or even assist in helping move forward.&nbsp;
Something I'd like to see are "empty" maps with tokens of "things" provided, so I can populate the rooms with the chests, beds, tables, benches, barrels, etc. myself. To be clear, what I mean by "empty" map is give me the dungeon walls and rooms, but let me decide where to place the stairs, etc.&nbsp; If it's an outside map with a river, let me decide where to place the bridge (or perhaps I don't want a bridge at all).&nbsp; Have different styles of bridges would be cool, because maybe the characters need to construct their own bridge, a rope bridge or a log bridge would be cool, etc.
1376044686

Edited 1376044761
Joshua W. said: Now, help me understand how these elements "exist" on a computer. Wouldn't each of these grids be seperate files, on top of the map file, and you load / don't load whatever you want? Shouldn't we create a large series of grids? The GM certainly would want a grid less version, to create his own grid, but most of the grids he "would" create should also be provided in addition? I can also export it at multiple sizes, so they don't need to resize it themselves at all, but they can import the correct version. We should provide all these things I'm thinking, anything that would make it easier. Roll20 and other vtt's like MapTool all have their own grid options that they can overlay on top of an image. So no grids are needed at all. In fact, they just get in the way and limit the use of the map to that scale. As for the exporting of the maps into multiple sizes, also not needed. Images can easily be resized inside of vtt's to fit the GM's need. The reason I specifically asked for 105 pixels per square is because of how Roll20 works. MapTool users would probably prefer at a minimum of 200 pixels per square since it has a much larger range of zoom. In Roll20, the maximum built-in zoom is 150%... so when a 10 square by 10 square map with 105 pixels per square (1050 pixels high/wide) is shrunk down to 700 px h/w, it will still look as good at 150% zoom as it does at 100% zoom.
If you really want to serve the VTT community, think of the product as less of a map and more like a package of assets . Remove the drawn-on grid, but keep some other "bolted-down" things like doors, windows, and fountains aligned to the grid and with reasonable* dimensions. That being said, lining up a grid isn't the end of the world. Roll20's guys even automated the process, so do whatever you want, that's not why I'm commenting. Everything that isn't a part of the floor or walls shouldn't be on the map - it should be its own token object.&nbsp;Remember that unlike a battle-mat, the best VTT maps sprawl for a while and are revealed over time with honest-to-god fog of war.&nbsp;Explode your maps so it's easy for a GM to draw his vision blocking layers, literally the most&nbsp;tedious&nbsp;part of being a VTT GM. (Psst, roll20 guys... it'd be sweet if I could upload an SVG of my map with a layer for VBLs.) Export your maps and objects as PNGs, not JPEGs, to preserve transparency. Export them in native resolution for the VTT you're catering to. That's 70ppi** for Roll20 and 50ppi for MapTool. Remember, file size matters because VTTs are networks. Many small images will render much faster than one massive one. Some campaigns are one massive map away from a disruptive internet timeout. Might as well throw in some high-res stuff, because 70ppi is pretty sad for assets. I disagree with HoneyBadger, above. Having assets at 105ppi will make them look nice, but when a half dozen people are accessing all the assets and are rendering all at once it'll choke network connections. Having them in there is nice, but not as default. Admittedly more of a MapTool problem than a Roll20 problem, since MT users have to host their own games and pretend to be servers. Then again, my group's maps are a bit less "beautiful work of art" and a bit more&nbsp; Gygax-ian pit of nightmares , so we can get away with laughably low ppi settings. I guess it comes down to philosophy. Most VTTs can't handle filetypes with layers baked in, so PDFs by themselves are a big no-no. That being said, a well-organized PDF means technically inclined GMs can roll their own flavors of your maps, which is cool. Tree trunks, not canopies. Transparent canopies. Thing I've actually said, while searching for a decent forest floor map: "Why is the canopy on the map?! My player can't see the tops of the trees, so why can I? My next dungeon map is just going to be a roof." To be honest, you probably want to get a web developer to do this. What I'm suggesting is very, very, very similar to the process of taking a graphic designer's mock-up and making it actually work internet-ready. If the layers and groups and collections and folders inside your Photoshop document (or whatever) are well-organized, meticulously labeled, and super professional, you might even be able to automate the process . If not... Copy of Group 2&gt; Group 2 &gt; Group 1 &gt; Copy of Copy of Layer 1 Layer 7 Copy of ...it'll be a hellish nightmare that I wouldn't wish on my worst enemy. tl;dr Use Smart Objects for everything. *I don't think I've ever encountered a five foot wide door in my entire life, let alone entire buildings filled with them, but, hey, this is D&amp;D. **I'm saying pixels per inch but in reality it's pixels per unit.
1376156329

Edited 1376156437
Gauss
Forum Champion
Dom B., &nbsp;your comments are accurate but for Roll20 use here are a couple of clarifications.&nbsp; Roll20 maps should not be PNGs unless absolutely necessary (such as must have transparencies). PNG maps may cause significant video processor lag on some systems. However, as you stated, a number of smaller images being put together to compose one large map will help with that since only images that are on your screen will be rendered. Note: this means that at the borders of 2 or more images they will all be rendered so there may be some pausing at a border or 4way intersection of resource intensive images.&nbsp; Roll20 uploads all of the assets to the user when they load the map so there should not be a problem with choking network connections. &nbsp;But, as you said, this is a Maptool problem rather than a Roll20 problem.&nbsp; - Gauss
MapTool doesn't have a native resolution/pixels per unit. It is whatever you want to set it at. That's one feature of MapTool that I like over Roll20.