Using Maptool for isometric gaming

[Bhoritz]

Following a discussion on this board about 3D VTT programs made me think about isometric views (and playing a few Card Hunter games only made me more curious).

So, I made some experiment with an isometric view in Maptool only to find that it was really easy to do. I have made a post about it here.

I am quite unsure if there is any interest for this kind of gaming, but I would be curious to know what you think about it.

[aliasmask]

I've done some stuff with trying an isometric map for DnD and it was a bit more complicated and you loose some lighting features. Also, VBL and FOW becomes an issue, as well as building new tokens and token z-order. I think it would work well with a boardgame style game though.

[Bhoritz]

For token z-order, I used a line of program you suggested in another thread . So the tokens re-arrange themselves when moved.
Fow an vbl were not an issue to me, I use maptool in face to face games and I hide or unhide things manually. I don't think that there is a possible solution to have it made automatically... but I am not very good at programming in maptool (I just use and adapt other peoples programming).

[Lee]

This is really well made, Bhoritz. It looks nice from the get go. Also, this is quite timely, I've been meaning to throw together isometric views to do some testing; you just saved me quite a bit of work.

Do continue working on this, and I'll hook up with you sometime later so you can test what I come up with. Some of the changes I got on the table are:

• Making the tool aware of an isometric token.
• Multiple images for a token. No more need to code elaborate macros just to change the token image. For isometric tokens, only 2 will actually be needed, full front and back shots. Translated perspectives will be done in-program
• Having these 2 in place, the facing mechanism will cycle through the current cardinal+ordinal points which will rotate the token image around the Y-axis.
• Panning the map will "flatten" the token image out the as the view approaches the token; making the image a regular "pog" once overhead. We'll see what can be done with structures if it ever goes that far Maybe you could add that to your to-do list for this project

Keep it up, I guarantee something good will come out of this.

P.S. BTW, it's implied that we'll have the grid and the means to snap to it

[CoveredInFish]

Nice. It really supplements to your (great) drawings.

[Bhoritz]

Thanks for the kind comments.

Lee, I am afraid that what I have done is as far as I can go with macros programming (not really my speciality). The changes you suggest seem very interesting, but definitely out of my league. I hope you'll be able to implement them, it would make isometric gaming a real possibility (instead of using a trick like I do), and maybe, it would be a way to keep Maptool abreast with the 3D VTTs that were spoken about in the thread that started my experiments.
One more way to use Maptool can only be a good thing.

I think I am going to make a kind of "set" to let people experiment isometric gaming (a few maps and associated tokens, enough to play a small scenario) and see if there is an interest.
I am not sure if there is a demand for it, because there doesn't seem to be much peoples gaming in isometric. But maybe then, there are not much peoples playing isometric games because there is not much stuff available...

[Bone White]

(instead of using a trick like I do)

Essentially, all programming is tricks. What you've done is what a program would to to simulate an isometric map from 2d 1:1 perspective map. The same rotation and stretching rules would be applied. The same can be applied to a token itself, skewed x degrees along the vertical side to match the isometric map skew. You could even use tokentool to slap a transparent overlay of a semi-circle before you translate it to simulate the card "stand".

It wouldn't be impossible to skew the grid along with the map, and then you have a functional (if troublesome with regular coordinate functions) isometric handling program.

Lee, I think multiple images for a token would be a great idea, perhaps allowing for a "base" token image, and then optional 8 images for the 8 cardinal points to face. This would work perfectly with a "d-pad" style interface for moving tokens within the programs, but I'm sure you've thought of most of this.

I went a bit over-zealous on this post, I meant just to reassure Bhoritz that his efforts aren't that small in the magnitude of things.

[Lee]

Thanks for the kind comments.

Lee, I am afraid that what I have done is as far as I can go with macros programming (not really my speciality). The changes you suggest seem very interesting, but definitely out of my league...

...I think I am going to make a kind of "set" to let people experiment isometric gaming (a few maps and associated tokens, enough to play a small scenario) and see if there is an interest.

Actually, this is exactly what I want you to do. Leave the technical implementations to me What is needed is material to make sure it gets done right. What you explained on your blog post is what this development needs more of. Reasoning out the visuals, like you did for this sample, especially having a visual display of the math involved, is crucial. If you could work on scaling, and pixel information relevant to grid and token size, it would save me a lot of time, as an artist's PoV is always makes graphical work easier

I am not sure if there is a demand for it, because there doesn't seem to be much peoples gaming in isometric. But maybe then, there are not much peoples playing isometric games because there is not much stuff available...

True, but the real achievement here is not isometric gaming, but the potential for a combined view employing isometrics and 2D, depending on the map perspective. But, even without these, isometrics alone will certainly spur content creators to create.

Lee, I think multiple images for a token would be a great idea, perhaps allowing for a "base" token image, and then optional 8 images for the 8 cardinal points to face. This would work perfectly with a "d-pad" style interface for moving tokens within the programs, but I'm sure you've thought of most of this.

Hehe. We could do that, but how I'm planning to implement multiple images would look something like this, written out in a data map (pseudo JSON object since it's what most are familiar with here):

Image Object Key/Token Unique ID/GUID (for isometric tokens):
{
frontView:assetId;
frontViewFlipped:assetId; <- flipped horizontally
rearView:assetId;
rearViewFlipped:assetId; <- flipped horizontally
}

Normal operations would involve front and rear views and special circumstances (e.g. displaying a switch in handedness) can access the flipped views. The cardinal/ordinal points I mentioned would just be there to snap rotation to, but during rotation, we'll basically manipulate the image like so:

[ ] - starting view (e.g. front), [] - turn start, ,[ turn in progress, | - switch to other (i.e. front or back) image, ] - new image turn start, [] - turn in progres, [ ] - end view (e.g. rear)

In the absence of an actual rear view image, we can just blank out the front view colors to an opaque color and use that instead. So, we'll end up mapping 2 or 4 images, and using, in most cases, just 1 or 2 of these. Structures are a different matter, of course

For completeness sake:
Image Object (for top down):
[assetId1, assetId2...assetN]

Which we all know we can use for disguises, states, moods etc.