This is a prototype of what I'm thinking of, as far as battle map goes. This could have an corresponding bump map like {-20, -20; -15, -15; -10, -10; -5, -5} 1) based on your description, it sounds like each tile of the map would have some elevation factor (in your example, -1 in the top left, 0 in the top right, 1 in the lower left, 2 in the lower right). How would you see yourself assigning those? I would be okay with a 2d array, or even a 1d, and specify the numbers of rows and columns. If I finish my Python map-drawer first, I'll share the datastructure I use, in case it can be easily adapted in JS. With the diagram above, I listed it as a pseudo-Matlab, which I think would be okay too. Basically, I'm not afraid of manually entering anything. I'm also open to XML parsing or any other datastructure. 2) Can you give the algorithm you're using for your sizes? Sure thing. A linear scale from 50%-125% from the array Min to Max+60. //With 60 possibly replaced by the Maximum of all tokens' elevation The equation looks something like: Scale = (BmpHeight + elevation) * 75% / (60 + Max - Min) + (125% / 75%) * (60 + Max - Min) / Max 3) Tokens that are now significantly larger than the tile they occupy, you would want their size based on the tile they are centered over, and would expect the tokens to remain centered over their tiles when they are resize and later moved? I hadn't thought of the logistics of this. I think it would be best to calculate the token's location based on its center, and resize it keeping the center in place. 4) when moving a token, you would want that token to be repositioned to be centered over the tile it snapped to before reapplying the algorithm, or the tile closest to the center when it's released? Another thing I hadn't considered. My intuition is to snap center to center... so the tile closest to center when released.