MapTool 1.4

Progress reports and musings from the developers on the current gaming tools.

Moderators: dorpond, trevor, Azhrei

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.4

Post by Lee »

@Jamz Will do :) As for features, I am interested in any cloud-based locations that are accessed through HTTP GET, POST etc. I believe you, and one other forum user mentioned having one each. Also, sometime down this year, let's talk about VBL.
KaylaKaze wrote: As for your posts, I'm not sure what to search for. You have over 800 posts so sifting through that would be a pain. :-P

So, since you've presumably been neck deep in the MT code recently and I haven't touched it much since 2007 or so (sadly, it hasn't really changed much since then), what are your thoughts on the difficulty of some of the features I threw out, primarily SQLite3 DB access (like an "executeQuery(db filename, query string)" command) and IRC based "Community" tab? I also had a couple of others I just recently thought of that are seemingly just minor things: loading macro code/HTML from a file (like an "include" to a macro), and making it so you don't select a token if you click on a transparent section of its image?
Here's the most recent, and relevant post about my work. I didn't bother adding it to my sig since something more detailed is coming soon.

I'll be uploading a short demo video soon featuring the SQL features I wrote. The feature's been done for a while now, but we're busy on a lot of stuff these days that it keeps getting relegated to the backburner. It's not on SQLite, however, but on H2, which has several advantages over SQLite that I liked. SQLite is in the mix, however, but used internally, and not accessible to users. IRC is in, that's all I can say for now. It's something we plan to discuss with the community interested in our project to round out the user experience. We don't want to implement all features that won't be used anyway; with that being said, it's functionally finished, but not the final user experience.

Regarding #include-like stuff, indirectly we help by providing several (safe) methods to access the file system, as part of providing alternate methods of managing data beyond the token system. I don't see the added value of creating a system that actually behaves like #include or Java's import, when a proper plug-in system is the target of forks and RPTools. onCampaignLoad should work for most cases, coupled with the new features.

Edit: To what purpose is the click-through transparency for? Not with the current system, and likely not with Swing; whether snapped-to-grid or unsnapped, the bounds are set with regard to each token image. It's just "easier" (I'm just imagining it in my head) with JavaFX. In order to accomplish what I think you want, an image object would need to be aware of either it's transparent or visible areas, and have mouse/touches pass through it if its transparent. Each image would need to be encased in a Node to have this nifty feature, which would be sub-optimal as compared to replicating one image over the Canvas.

KaylaKaze
Cave Troll
Posts: 57
Joined: Mon Jun 18, 2007 1:08 pm
Contact:

Re: MapTool 1.4

Post by KaylaKaze »

Lee wrote: Edit: To what purpose is the click-through transparency for? Not with the current system, and likely not with Swing; whether snapped-to-grid or unsnapped, the bounds are set with regard to each token image. It's just "easier" (I'm just imagining it in my head) with JavaFX. In order to accomplish what I think you want, an image object would need to be aware of either it's transparent or visible areas, and have mouse/touches pass through it if its transparent. Each image would need to be encased in a Node to have this nifty feature, which would be sub-optimal as compared to replicating one image over the Canvas.
Well, in our current D&D game, for example, we use top down view tokens. With weapons and whatnot, this often leads to the tokens hanging outside their block. Usually, it's just something like a weapon, so the token ends up being a lot of empty transparent place as the system makes a boundary box around the whole thing, which then makes it difficult to click on tokens next to it. I wrote system in JS while doing some experimentation a while back where I could overlay images (using an img tag) and click on ones below that you could see through the transparent section of the top layer by quickly copying the image to a canvas, getting the color value of the pixel that was clicked, checking the alpha on that pixel, and then, if it was transparent, make that layer not receive click notifications (and with some browsers, had to hide it) then resend the click event at that location (when I had to hide, I'd reshow immediately after the click event was sent and it'd be visually imperceptible).

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.4

Post by Lee »

Ah, it is as I surmised. I won't close the door on the idea; I do have to say that there are factors within the current system that is dependent on the bounding box surrounding the image. Of course, you could say that it is a special context, only checked when clicking/touching the image, but I'll reserve looking at it until the new mapping system is visited. As much as possible, we would like to implement optimal practices like the replication I mentioned. Once that is in, there should be leeway to put in more expensive processes.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: MapTool 1.4

Post by JamzTheMan »

KaylaKaze wrote:
Lee wrote: Edit: To what purpose is the click-through transparency for? Not with the current system, and likely not with Swing; whether snapped-to-grid or unsnapped, the bounds are set with regard to each token image. It's just "easier" (I'm just imagining it in my head) with JavaFX. In order to accomplish what I think you want, an image object would need to be aware of either it's transparent or visible areas, and have mouse/touches pass through it if its transparent. Each image would need to be encased in a Node to have this nifty feature, which would be sub-optimal as compared to replicating one image over the Canvas.
Well, in our current D&D game, for example, we use top down view tokens. With weapons and whatnot, this often leads to the tokens hanging outside their block. Usually, it's just something like a weapon, so the token ends up being a lot of empty transparent place as the system makes a boundary box around the whole thing, which then makes it difficult to click on tokens next to it. I wrote system in JS while doing some experimentation a while back where I could overlay images (using an img tag) and click on ones below that you could see through the transparent section of the top layer by quickly copying the image to a canvas, getting the color value of the pixel that was clicked, checking the alpha on that pixel, and then, if it was transparent, make that layer not receive click notifications (and with some browsers, had to hide it) then resend the click event at that location (when I had to hide, I'd reshow immediately after the click event was sent and it'd be visually imperceptible).
FYI, I personally would instead change the code for bounding boxes. So if you edit a token to zoom it out, ie via the lower right hand token image next to handout, make it so the binding box stays conformed to the actual size of the token regardless, unless set to freesize vs the size of the image.

Just seems it should act this way in a grid restricted game.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: MapTool 1.4

Post by Full Bleed »

Lee wrote:Ah, it is as I surmised. I won't close the door on the idea; I do have to say that there are factors within the current system that is dependent on the bounding box surrounding the image. Of course, you could say that it is a special context, only checked when clicking/touching the image, but I'll reserve looking at it until the new mapping system is visited. As much as possible, we would like to implement optimal practices like the replication I mentioned. Once that is in, there should be leeway to put in more expensive processes.
Take a look at Battlegrounds RPG. With it you select an image by clicking on a visible pixel within the image, so there is no real "bounding box" to create the sort of issues that MT has. I followed the early development of BGRPG and MT (ultimately settling on using MT for my games) and I think token selection is still one of the areas that BGRPG has a distinct advantage.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.4

Post by Lee »

@Jamz, FB, KaylaKaze
Thanks for the input. We're building this from the ground up, and everyone's aware that there're a lot of considerations. Sometime in the next 3 days, we'll have both the database demo, and a (simple) POC video for what we've been tinkering with, with regard to the map system.

Since it's at the latter end of our project plans/stretch goals, we haven't gone all in, but we've done a lot of research and practical reviews on possible technnologies. The POC uses one such avenue, but we won't go into the particulars, since we might end up using another. Ultimately, we'll be doing it the way we are comfortable with. I am aware of the last discussion that was had regarding what vision approach should be used.

Anyway, the POC displays a finite map as opposed to MT's current system of a boundless one. I'll be opening a thread discussing that soon, but I just didn't find much in the way of anyone implementing a practical use for an infinite map, apart from that cool zoom-in demo (I think we all saw that). I think a finite map that can be re-sized on the fly is more practical. In hindsight, it might have helped with performance problems associated with the vision system.

Just to reiterate how we want to execute development, the first phase of is tied very closely to how everyone knows MT; apart from making stuff easier to use, anyone familiar with MT won't have to learn a lot of new stuff. That's our nod to the current user base. Subsequent phases will be different, as everything might change under the hood, apart from macro script handling. It's very plastic right now.

User avatar
aliasmask
RPTools Team
Posts: 9023
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: MapTool 1.4

Post by aliasmask »

I'm all for a finite map since it really isn't practical to build an infinite map memory-wise. Snap to grid get funky when X gets in to the millions with movement. The only think I would like to see is a center graphics feature in case I'm drawing an area map that's too close to the boundary. Then again, maybe the map area is so huge that won't be an issue. Generally speaking, I try to start the start area of a map at 0,0 so when switching to map for first time the intended area can be seen without zooming out and back again.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: MapTool 1.4

Post by wolph42 »

aliasmask wrote:I'm all for a finite map since it really isn't practical to build an infinite map memory-wise. Snap to grid get funky when X gets in to the millions with movement. The only think I would like to see is a center graphics feature in case I'm drawing an area map that's too close to the boundary. Then again, maybe the map area is so huge that won't be an issue. Generally speaking, I try to start the start area of a map at 0,0 so when switching to map for first time the intended area can be seen without zooming out and back again.
also something I learned over the years...to start at 0,0.

@Lee: you say its would still be possible to change the boundary later on. In terms of memory and speed, lets say that someone wants to create the 'zoom movie' again, would the demand remain (roughly) the same in the current and your new system? (or would yours still be more efficient?).

I ask because one of my earlier projects was compiling all available map material into one map in maptool for Warhammer. That was a succes, but it means that you have 'global' scale and you are able to soom in upto 'token' scale (e.g. several building in a city.) In all its pretty cool, although the maps are demanding in resources making it a bit slow.

I have the campaign file available if you're interested.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.4

Post by Lee »

@A.M. I'll take note of that. We'll definitely cross that bridge as the most important aspect is presenting a comfortable design experience, where no detail is too small.

@wolph Even if we just use the same rendering techniques as what we have now (i.e. scale, clip, fill), things will definitely be faster as the process will go through hardware instead of old Java2D. There are really a lot of approaches to making a map system. We're tinkering with several right now. The demo will feature familiar approaches found in 1.3. What to expect are:
  • Fog - I'm quite happy with this experiment. Stepping away from the 1.3 code, and doing it here, helped me correct my path computation for unsnapped fog clearing. I'll submit a patch for 1.3 when I have the time.
  • Lighting effects
  • The new token image model
  • Animation API
  • Isometric map potential
  • Panning, zooming/scaling
It's a POC, so set your expectations to the minimum :lol: We didn't do snapping-to-grid, and VBL, as we have different ideas on getting these done, both of which would need time to code.

Edit: I'll ask for that map when the time comes :)

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: MapTool 1.4

Post by JamzTheMan »

Sounds like cool stuff! I'm exitited to see where you went with the lighting effects. I started recently looking into some websites that touched on 2D lighting and looked for an easy way to add a fade affect. It turned out to be a little much to take on for now with the current system.

I wasn't really concerned with Isometric view UNTIL 2 months ago when I downloaded Shadowrun Returns. FYI. if you download this game for the PC, ALL there artwork is in png form in a series of folders under artwork. Some really nice stuff in there! And of course, since the game has it's own editor, there are other map/art packs from the community. If we got just an isometric grid, that would rock.

As for VBL, I'm thinking Ray Tracing really does seem to be the way to go. I came across this blog and even the Javascript version of the code seems to work better than MT. If properly coded, MT should be able to hand a lot more VBL and light sources than it currently does, and in real time.

http://www.redblobgames.com/articles/visibility/
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

Virenerus
Cave Troll
Posts: 36
Joined: Fri Jan 17, 2014 9:13 pm

Re: MapTool 1.4

Post by Virenerus »

Very cool article. You are right, mt should have a faster vision engine. And I also like the idea to use the shadowrun returns images. The game looked really good.
Would love to see these implemented somewhen^^

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.4

Post by Lee »

@Jamz For great assets, I suggest Blood Brothers and Blood Battalion from Mobage, moreso for the latter, though they halted development as it didn't profit as much as the former. But the art is topnotch, and I've been meaning to collect the cached images, but I'm just too busy these days :lol:

Don't expect too much for the demo :lol:, it's more or less a play on what's possible on the tech we chose to make the demo. We're still in process of reviewing tech and accumulating agnostic code. That part of the project is at the latter stages of our plans.

With regard to lighting, the demo just shows ambient lighting, and light diffusion from a source, none of the particles/pixels from the light source interact directly with portions of the fog. We ran the ambient light on a threaded system we plan to use to simulate time; this same system will be the basis for customizable clocks and calendars in campaigns.

The demo is on a map generated using an isometric tile, with an isometric actor. Unfortunately, the actor is not fully 3D, so it rotates like a paper mini/doll. We're pretty proud of something we dabbled on for a day :lol: I won't spoil the rest of the "surprise". I'll upload it sometime later; I just have to make sure the video comes out nice.

Good article, BTW, ray tracing was the preference of username, IIRC. We're testing everything, actually. The likeliest outcome is an amalgamation of techniques based on what our team deems as a right combination of performance and aesthetics.

We're more concerned with coming up with the right model for maps. VBL and lighting come later since a well defined base makes writing the interplay between map objects and the vision-related systems, a lot easier.

User avatar
Bhoritz
Giant
Posts: 130
Joined: Wed Jul 21, 2010 10:31 am
Contact:

Re: MapTool 1.4

Post by Bhoritz »

@Lee: I would like to add a point for being able to reach through transparent pixels.
My use of Maptool is certainly a little unusual, but what I am now developing for isometric use of Maptool would certainly benefit from the capacity to be able to select through transparency.
As you can see here, the figures I am making have a lot of transparent areas and bits sticking out:

Image

The problem would be the semi transparent pixels (the shadow), which shouldn't be selectable (I think).

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.4

Post by Lee »

@Bhoritz When put like that, it now is very clear. It shouldn't be hard to do, though there are several ways to do this. We'll work out what's best. Thanks for the input, and that iso art really looks nice!

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: MapTool 1.4

Post by Full Bleed »

Lee wrote:@Bhoritz When put like that, it now is very clear. It shouldn't be hard to do, though there are several ways to do this. We'll work out what's best. Thanks for the input, and that iso art really looks nice!
I've been pushing for non-selectable transparent pixels for many year in MT... and with isometric, it is darn near a necessity.

So if you do pull this off, I will be very happy. :)
Last edited by Full Bleed on Thu Aug 07, 2014 1:49 pm, edited 1 time in total.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

Post Reply

Return to “Developer Notes”