Concept for a map and token extension which doesn't break old stuff

[Tryll]

One way to extend Fantasy Grounds would be to offer a network API which exposes access to the combat tracker. Perhaps even restrict this to a webkit window opened within, or by, FG. Then we could develop HTML5 mapping systems, token systems and more, and allow them to be displayed in that window(s).

I'm quite sure that with some minimal information from the combat tracker, we (Smiteworks, and/or the community) could tie in a mapping system similar to Roll20.com's (as we would only need to deal with maps and tokens.) That could all be open-source and upgraded or improved by any of us. Token stamps. Halos. Effects. Stat bars.

Doing something like that would give FG much more potential... while keeping its own mastery at rulesets, character sheets, chat window, virtual dice, and the combat tracker all left neatly in place.

Seems to me, that Gamemasters would then have the choice of which mapping system to use (original or HTML5), and the whole thing could be (virtually) transparent to older rulesets.

[Tryll]

One of the reasons why I think this type of extension is possible is that currently Maps ("Images"), and Tokens, are apparently pretty loosely connected to the rest of the rules system. Tokens are not connected to character sheets in any important way. Maps are really just images and some data... data which is really only relevant to the map.

[phantomwhale]

Interesting idea, but I'm not sure it's as decoupled as that.

Tokens and the combat tracker are fairly strongly linked (e.g. the active token on a combat tracker is highlighted on the map, and targeted tokens on the map are highlighted on the combat tracker).

Also, all these effects and stat bars would need to be tightly coupled with the character sheet data and updates to that.

So not sure if would be as simple as that; but take your point about wanting a better map / token system. I know there could be more work done on the SavageWorlds map, although given the "lightweight" nature of SavageWorlds enemies it doesn't seem as highly in demand as for a stats heavy combat system like 4E (going by the wishlist, that is).

That said, if developers are keen to help, I would be very happy accepting patches to the SW ruleset. As for "all rulesets", I'd have to defer to moon_wizard on that (although I see adding that into FG core has been discussed in another thread). I'm not convinced abstracting the mapping system outside of the core program would be as simple, without exporting the whole API ?

[Tryll]

Tokens and the combat tracker are fairly strongly linked (e.g. the active token on a combat tracker is highlighted on the map, and targeted tokens on the map are highlighted on the combat tracker).

Perfect, include that variable data in a JSON stream. I don't see how it would break anything.

Basically, my picture of it would be that the only connection required would be between the map and the tracker. As long as stats were reflected in the tracker, they could be graphically represented in the map... in one way or another. Now, bear in mind, I don't think this system would have to displace the current one, it could potentially ride alongside.

[Tryll]

For (limited) example...

Data from Tracker...
{token:{targets:{},stat1:{},stat2:{},etc:{}}, more tokens...}

Then, at the map side, you say
Aura 1 = token[1].stat2
glow 2 = token[2].health

Or however. So the connection, and information could be used across rulesets.

Wouldn't be much of a trick after that to automate the setup, I think.

[phantomwhale]

I wonder, given it needs to be ruleset agnostic, and given the different parts of data it might wish to use, if this map tool wouldn't essentially require access to the whole campaign database and associated updates (given 80%+ of a campaign database is character details, combat tracker details and NPC stats, this isn't too far fetched).

Not sure what this might mean from a security perspective (you did mention only opening a window on the machine - but it's all local, so someone could get hold of this JSON steam) and also from a network traffic point of view (e.g. there is no "server" in an FGII game) - I guess you'd ideally want to send out this JSON stream from the client to the window (as GM upload bandwidth is normally at a premium).

It's certainly an interesting idea - I've not had much experience with the other mapping tools on the market (my needs are fairly light) but I don't think anyone would hesitate to agree there could be much richer functionality on the FGII map tool.

[Tryll]

Perhaps the serving demands on the GM machine would be vastly lightened due to offloading map information. The map image could be pulled from the cloud even.

[Tryll]

These points do make me think though... I guess the GM's system would be what would coordinate with the tracker... the resulting map and its data is what would be displayed at the client end. Therefore, only the GM's system would actually be talking to itself via the tracker communication, and it would then forward that result to the clients... and then back up in reverse.

If maps could be stored as URLs, then the clients could load them from dropbox or wherever. It would cut down on the GM needing to serve huge binary chunks. Data transfer would be more similar to chat data.

Just a concept.

[Moon Wizard]

This is actually related to another topic that we have talked about on the forums, which is to create clients for mobile/tablet platforms. In that scenario, the mobile/tablet platform would not be able to use the built-in ruleset files, due to screen size issues; so they would primarily only be using the database communication, and implementing their own interface.

Essentially, you are looking at the same thing, but with a browser-based client instead of a mobile-based client.

If this is something you are interested in building, you can send us a note at:
[email protected]
We're not sure how mobile/web clients would work overall, since there are some items to figure out. However, we are open to exploring the options with someone interested in working with us on the technology.

Cheers,
JPG