Isometric and 3d combat

[Arcueid]

Hi, so i was curious if somone might have thought up a good way to visually show flight using the isometric view?

The idea i had was having a "shadow" token sit on the board showing the X/Z axis it sits on, while the character itself sat diagonally directly up from it making the distance between the 2 the Y axis.

It seemed like a neat idea except it has the major failing that everything "south" of the token would be able to treat it as if it was in the air and could draw a line from themselves to it to measure distance.

Anything north of it, especially if it was near the "true" token would get a weird effect where they would seem as if they were on the same plane as them.

Also if anyone had an idea how to actually more directly tie the token to its "shadow" would be helpful as well because obviously during the time someone could easily change their main token's position without updating the "shadow" location.

Just seeing if anyone might have a good solution for this because it seems like it could solve the age old problem of 2d games trying to have 3d elements. But every time i think i have a good solution i find some problems.

Right now i just use a macro that sets a number on the token and we pretend that's the Y axis of up and down, but it obviously can get into a confusing cluster sometimes when someone is under them or attempting to do some sort of melee option because the visualization can get weird for it.

[Jagged]

I have put quite an amount of thought into this actually, but my solution would be in the java layer rather than in Maptool. Which probably isn't very helpful to you

My idea was to add an "elevation" attribute to tokens, which would be used to shift the token image vertically while all vision rules would still be calculated on the footprint. However I decided not to add it to the initial isometric release as the functionality is still so new and fairly untested.

[aliasmask]

If you were to move the position of the token to represent height then you run in to vbl and line of site problems. You could move the image in the config panel up and use a state to represent the shadow, but there is no auto way of doing that. It also doesn't prevent stacking of images.

[Jagged]

If you were to move the position of the token to represent height then you run in to vbl and line of site problems. You could move the image in the config panel up and use a state to represent the shadow, but there is no auto way of doing that. It also doesn't prevent stacking of images.

Exactly, which is why I was thinking of doing it through Java as part of the isometric stuff.

[Arcueid]

On my campaign i have a series of macros for 3d fighting currently. I also added a custom value to tokens for elevation. So thats what we use currently. But no matter how much we use it players eventually run into a moment where they get massively confused.

I'm almost personally tempted to look into the code around it to see if its possible without having to click on a macro each time, to basically have a link between 2 tokens.

In theory the illusion could be better assisted having the system "draw" a line as if using the movement/measuring tool between the two if hovered over.

I think my campaign would be forever stuck with using my distance macro for making the math easier against flying opponents on ranged attacks. Though what would be really neat is if i could find a way to hotkey this so one does a CTRL+drag or some other combo while moving it and any upwards movement as part of that movement would register as an elevation increase.

In theory a simpler idea would be to make a macro and somehow have that macro using some sort of character/token attribute save off a "ground" token to register as tied to it, and then using a couple other macros to have one align the two and another to increase/decrease the elevation (though the ground token would effectively become your token for movement, and the macro would just put the other token a distance above matching the elevation attribute value.

It would require a lot of macros and be kind of messy (and i'm not a huge fan of the macro system on the tool so the thought of scripting out another set of macros doesn't seem very fun).

[wolph42]

couple of remarks.

First off: usually the 'elevation' is denoted by the Z axis not the Y axis (unless I misunderstood you). Same in MT x/y is the coords and Z is the zoom level (yeah for confusion later on). Perhaps something already to think of and maybe talk about X/Y/E (elevation).

So far the semantics.

As making clear that a token 'floats', shadow is one step, but if you're talking battles that means you need a visible tether to the ground as well. And I would suggest different tethers (as option):
- casting shadow (which would be the simplest one)
- (transparent?) base with pole:

first image I could find

Optionally you can give this 'base with pole' different colors. Trick with this thing is thus that it has an adjustable length!
If you really want to go the distance, then you give the 'pole' grid markers, which e.g. in case of a black pole would be white lines along the pole.
- as mentioned earlier though, stuff like VBL might really get screwy this way, so it does require quite some thought.

Finally distance. Figuring out the distance between two token is a really easy to do. Best way IMO is a macro which you call in the 'stat sheet'. You select token A and then hover over token B, in token B's stat sheet you call a 'distance calculation' macro. I have one in my warhammer campaign that works like that.
Function you need is: Wiki: getDistance() and you can easily apply so Pythagoras to factor in the height difference, but since we're talking java anyway, I would sooner suggest that 'getDistance' gets an optional parameter that also takes height difference (E-axis) into account.

edit:

this is exactly what I envisioned

That image also shows *why* the poles are so important. Just shadows is great for RPG, but e.g. in this case with the dogfight game (Wings of War: Famous Aces) they're vital!

even better with transparent placeholders

edit2: I love that game btw (Wings of war) I might consider converting it to MT when this is implemented.

[aliasmask]

So, what part are you having difficulty with. The visualization or the distance mapping? Also, what game system are you using? I've updated the PF framework to include elevation in the distance formula as well as creature size. I also have an elevation tool that allows you to set the various elevation types. The distance it shown by selecting a token and mousing over another token which shows the distance between them. I guess the only sticking point is if a player is moving calculating the distance they can travel before reaching their flight distance. In PF it's not too hard. It just a matter of counting diagonals while ascending. I thought about writing a movement tracker so players can know their distance traveled while moving. What I would do it is have a pop-up with a directional pad. Then for flight I would have an up/down and up/down 45 degree buttons. The up/down would simply change the elevation. The up/down 45 would change the movement mode so when the directional pad was used then it would also increase or decrease the elevation depending on the setting. That's how I would do it.

[Jagged]

Using the Current Isometric Functions in 1.4

You could possibly do something with Figure Type Tokens and Image Tables.

If you could simplify the Elevation so that you only have a few levels of height you could conceivably so something. Say you decide to have 4 levels of elevation: Grounded, Low, Medium and High. You could then create an "Image Table" for each character that can fly. The table values need to match the values for facing (-180 to +180) so you could use -180 to -90 from Grounded, -89 to 0 for Low, 1 to 90 for Medium and 91 to 180 for High. Then for the images, you have a normal image for Grounded (naturally) but for each of the others, you make the image progressively taller and include the shadow. I think I would also be inclined to add some other graphical indication of height. Perhaps a stand or some kind of 3D bounding box.

You could then use character facing to represent character elevation.

[wolph42]

Using the Current Isometric Functions in 1.4

You could possibly do something with Figure Type Tokens and Image Tables.

If you could simplify the Elevation so that you only have a few levels of height you could conceivably so something. Say you decide to have 4 levels of elevation: Grounded, Low, Medium and High. You could then create an "Image Table" for each character that can fly. The table values need to match the values for facing (-180 to +180) so you could use -180 to -90 from Grounded, -89 to 0 for Low, 1 to 90 for Medium and 91 to 180 for High. Then for the images, you have a normal image for Grounded (naturally) but for each of the others, you make the image progressively taller and include the shadow. I think I would also be inclined to add some other graphical indication of height. Perhaps a stand or some kind of 3D bounding box.

You could then use character facing to represent character elevation.

I'm wondering whether you've seen my last post (here above). Assuming you have:
IF you're gonna throw in elevation in isometric THEN I'm really of the opinion that you should do it immediately thorough as well. Meaning indeed creating an E axis and a E grid system along which tokens can be placed and their poles marking the grid section (similar as in the picture in my earlier post). By keeping things optional you can use the shadow option as mentioned for RPG and the more advanced pole/grid system option for tactical games like he one I mentioned earlier.
If you're going for the 4-level option you mention, you get exactly the same issue that MT has now for a loooooong time with sizes (and from the looks of it, that will remain so for quite some time in the future as well). Instead of immediately choosing an agnostic system, they chose to use the D&D options, narrowing versatility of the system immensely. IRC that size system was chosen initially from convenience with the intention to do it better later on. The end result is is that its very hard to remove as its hard coded all over the place. So don't make the same mistake the Dev made then.

[RPTroll]

IF you're gonna throw in elevation in isometric THEN I'm really of the opinion that you should do it immediately thorough as well. Meaning indeed creating an E axis and a E grid system along which tokens can be placed and their poles marking the grid section (similar as in the picture in my earlier post). By keeping things optional you can use the shadow option as mentioned for RPG and the more advanced pole/grid system option for tactical games like he one I mentioned earlier.
If you're going for the 4-level option you mention, you get exactly the same issue that MT has now for a loooooong time with sizes (and from the looks of it, that will remain so for quite some time in the future as well). Instead of immediately choosing an agnostic system, they chose to use the D&D options, narrowing versatility of the system immensely. IRC that size system was chosen initially from convenience with the intention to do it better later on. The end result is is that its very hard to remove as its hard coded all over the place. So don't make the same mistake the Dev made then.

+1

[Jagged]

I'm wondering whether you've seen my last post (here above).

The post above is a suggestion for how to do it using current functionality, not a suggestion for how to build the a full system.

[wolph42]

I'm wondering whether you've seen my last post (here above).

The post above is a suggestion for how to do it using current functionality, not a suggestion for how to build the a full system.

correct, I was mainly talking about elevation, but my last post would make little sense if you did not read the one before that and since you didn't go into my post at all I was "wondering whether you've seen my last post...". Hence the remark.