FEATURE: Isometric Map - BETA

[Jagged]

I was very impressed with Bhoritz's efforts at using Maptool for isometric maps, so I thought it would be great to see how far I could go implementing something for 1.4.

I've been thinking about the basic tasks:

• Rules for mapping cursor position onto cell coordinates
• Rules for mapping cell coordinates to cursor position
• Create the IsometricGrid class
• Modify GridFactory to allow access of the IsometricGrid class
• Modify the MapPropertiesDialog class and xml to allow the selection of the new map type
• Modify SightType so that vision areas are ellipses and rectangles rather than circles and squares
• Modify Light so that vision areas are ellipses and rectangles rather than circles and squares
• Modify Zone.TOKEN_Z_ORDER_COMPARATOR to order tokens by isometric depth rather than an arbitrary Z value
• Modify ZonePoint getNearestVertex. Seems like this should inherit for Grid class, not sure why it doesn't. Existing code doesn't look like it would work well for hexes?
• Think about how best to position the different tokens types on the isometric cell

So far I have created the basic IsometricGrid class and updated Map Properties so that you can create an isometric map which allows you to drop tokens onto it and drag them about. In my implementation the pixels per cell value becomes shortest dimension of the isometric "diamond" i.e. the height.





If you want to have a play with what I have done so far, you can pull my "Isometric" branch from my Github repository (https://github.com/Jaggeroth/maptool)

Obviously there is still a lot to do before this would be of much benefit. It might even be necessary to create a new Token Type. Anyway, I am finding this a fun little project for someone that has written in java for years but has never ever touched Swing!

[aliasmask]

Cool. I toyed with making iso maps as well but the things that really prevented me from using is light, fow, vbl, distance and state usage. The light/aura and fow proble is obvious because there is no way to expose ovals. For vbl, if I had a tall token there was no way to hide it if the top part went pass the vbl. Also because I wasn't using symmetrical tokens most of the state format wouldn't work. I could do a custom image one though. I needed my own snap to grid formula using a gridless map and onTokenMove and the distance formula had to be tweaked. Here are a couple of examples of the type of tokens I was trying to use.

Example.jpg (93.14 KiB) Viewed 2167 times

The one on the left looks nicer but the center of token was in the wrong spot. The one on the right worked well but token stacking was an issue as well as the other lighting and vbl issues.

[JamzTheMan]

Cool beans. Good luck, so many things to tackle with that feature.

If you need test graphics, I have a lot os SR graphics from the Shadowun PC game, all their artwork is in png and there is a public share of new modules and artwork om their site.

[Jagged]

Thanks for the encouragement all.

So far I have only done the easy stuff and there is indeed a ton of stuff left to do. I am not sure it will even be possible to have a true isometric maps in Maptool (hence the "Beta" thread title ). My hope is to get enough done that it is at least helpful to those few who are trying to implement isometric games. Plus I can always come here and bug people for help

[Jagged]

Started modifying SightType class to alter vision areas for Isometric Grids. Seems like these areas should be inherited from the Grid class in some way. I will think about that later.

Here's Square vision in square grid and isometric:

whizard3.png (468.55 KiB) Viewed 2125 times

Here's Circle vision in square grid and isometric:

whizard1.png (458.34 KiB) Viewed 2125 times

[JamzTheMan]

oh wow, nice work! I figured that would have (or was) a pain in the donkey...I suppose if sight is done, lighting would be next and similiar?

[aliasmask]

Nice. I'm wondering if a token footprint is not visible to a token if the token image could be suppressed as well? I've seen this is current games where if the gm offsets the token or enlarges it compared to the footprint in the config window that it will be seen by the players through vbl. Fixing this would make iso much more doable. Let me know if you need an example.

[Jagged]

oh wow, nice work! I figured that would have (or was) a pain in the donkey...I suppose if sight is done, lighting would be next and similiar?

Actually it was relatively simple, but I haven't done cones yet, so I will let you know

The Light class has a whole bunch of duplicated code so yeah, once I have finished vision, that should be easy. That there is duplicated code and the fact that I am adding "instanceof" code sections to deal with my grid type, suggests to me that this area needs a good refactoring! One I get this bit working I shall:

• Add Shape methods to base Grid class for CIRCLE, SQUARE and CONE
• Move the original code to the Grid class, so that GridlessGrid, SquareGrid and HexGrid remain unchanged.
• Move my "instanceof" code to my IsometricGrid class
• Change SightType and Light class to call Grid class methods for shapes

[Jagged]

I'm wondering if a token footprint is not visible to a token if the token image could be suppressed as well?

I've been spending a lot of time thinking how best this can be accomplished. I will definitely be restricting all visibility calculations to the footprint. My current thoughts are to have a separate token type for isometric tokens (since they would have different cell bounding rules) and then to have a "transient" layer that isometric tokens could be "promoted" to, if they are visible. That would have the advantage that you could mix isometric tokens from the object layer and the token layer and have the same Z Ordering rules apply to all.

Still in early day thinking though

[wolph42]

looking at this I was wondering whether it would be possible to convert 2d images (e.g. the typical round flat token) to an isometric image within maptool. I guess it would be image rotation and change of angle, but im unfamiar with the tools that java has for image manipulation. It would be great though as you could instantly transform a 2D map to an isometric view, tokens included.

edit: Now that I think about it a bit more for round tokens it should be really simple as 'isometric' in this case means that the height:width ration changes. In case of square token you first need to rotate it 45 degrees. AFAIK both are java commands, so its only a matter of finding the correct parameters.
Even better, you could probly do this conversion real time, so you can also rotate the token on the map.

[Jagged]

That's my plan. Squish circle, top down and square tokens into the isometric "diamond". And hopefully allow them to be rotated appropriately. I think this will require modification of the TokenOverlay class, but I haven't investigated this properly yet

Then have a separate isometric token type that "stands" on the cell with different bounding rules.

[Jagged]

Quick question about CONE in the class SightType:

The code for creating a cone, uses Arc2D.Double to create the cone and then does a transform to rotate it to the "token facing angle" converted to Radians. This seems a little odd when you could just drop the token facing into the arc creation and get the exact same result without the rotation. As far as my testing goes, I can't see any difference, but I thought I would check here, just in case I am missing something.

So is there any reason why it would be preferable to create the cone and rotate it, rather than just create it facing the right direction?

Code: Select all

Area tempvisibleArea = new Area(new Arc2D.Double(-visionRange, -visionRange, visionRange * 2, visionRange * 2, 360 - (arcAngle / 2.0) + (offsetAngle * 1.0), arcAngle, Arc2D.PIE));
// Rotate
tempvisibleArea = tempvisibleArea.createTransformedArea(AffineTransform.getRotateInstance(-Math.toRadians(token.getFacing())));

versus

Code: Select all

Area tempvisibleArea = new Area(new Arc2D.Double(-visionRange, -visionRange, visionRange * 2, visionRange * 2, token.getFacing() - (arcAngle / 2.0) + (offsetAngle * 1.0), arcAngle, Arc2D.PIE));

[JamzTheMan]

Only if it was created once and stores then rotated as needed.... Maybe it waa a limitation of the class at the time?

[Jagged]

I now have cones working, but considering that I used to think I was good a trigonometry, it took me far longer than it should

whizard.jpg (119.8 KiB) Viewed 2063 times

whizard2.jpg (135.11 KiB) Viewed 2063 times

That was a pain in the donkey

[wolph42]

yes you mixed up diagonal and orthogonal. In eucledian space is 4 horizontal/vertical while in isometric space its 4 diagonal so you took the wrong side of the triangle to calculate this. in other words your a factor sqrt(2) off in normalized space (a light of length 1 in the orthogonal view is sqrt(2) in isometric).

I hope this makes sense. let me try one final way. Your current light distance in isometric is x but it should be x/sqrt(2x^2) based on the images your provided.