1.4 Blast From the Past Games Interview

Blast from the Past: Planned Changes for MapTool 1.4 pt1

Blast from the Past: Planned Changes for MapTool 1.4 pt1

This interview was finished in 2011 on the end of MapTool 1.three improvement. It’s a enjoyable article to learn again in any case these years. We’ve completed quite a lot of the 1.4 plans but needed to delay a number of the hopes on account of JavaFX turning into a technical soccer at Oracle. We hope issues have settled down with Oracle giving JavaFX to the Open JDK group.

Different elements of the plan have/will probably be part of the 1.5 collection. MapTool 2.zero is the place we at present plan to implement the new Consumer Interface in Java FX.

The article originally appeared on the Tales of the Savage Troll lavatory.

MapTool is a free, open-source Virtual Desk Prime (VTT) used to connect players of all stripes. MapTool consists of powerful map creation, token administration, mild and sight, and initiative tracking performance in an easy-to-use package deal that a consumer can pack with customizations to speed gameplay.

It’s The Savage Troll’s go to know-how for time-crunched gaming since it removes much of the setup and journey time required for our favorite interest. You simply drop a map onto the display, create a number of tokens to characterize PC and NPCs, begin your MapTool server, and play.

The 1.3 model of MapTool is in Launch Candidate mode which suggests the builders are tidying up a couple of ultimate bits and pieces earlier than all work on 1.three stops. At that point, the developers rip the code aside and do major modifications and upgrades to the prevailing code base while including a slew of latest performance. This leads to the inevitable question relating to what’s altering, what’s staying, and what’s leaving when it comes to MapTool type and performance.

The present venture leads for MapTool ( Frank, Craig, and Bill ) took the time to answer a couple of questions relating to MapTool 1.4. Fortunately for us, that they had rather a lot to say so we broke the interview into two sections. The primary, Planned UI Modifications for MapTool 1.4, is introduced under. The follow-on interview relating to macros and other performance ought to comply with in a single week’s time.

Consumer interface Questions:

What new or changed mapping performance will we discover at 1.4 remaining?
[Frank] We now have a number of plans for 1.4 however our preliminary set of modifications will probably be re-architecting your complete undertaking. Meaning breaking down every function and function into modules, then building the appliance again up once more based mostly on these modules. This preliminary step is more likely to be very time-intensive and could take months to get to the point the place we’ve got a MapTool 1.Four that may even run! Meaning our definition of what goes into 1.4 vs. 1.5 may change over time. And it’s why it’s so necessary to get 1.three as bug-free as attainable since customers is perhaps utilizing the final build for months.

This also signifies that our objectives for 1.Four may change. We might get half approach into this process and determine that adding in depth new options as a part of 1.Four may be too massive a chew to take directly. It may be higher to do the redesign and get it to a fail-safe point and name that 1.4b01, then add just a few primary modifications without in depth rewiring of the entire thing. For instance, perhaps just repair up the dialogs in order that they are extra “wizard-like”, but without making large modifications to the internals.

We’ll know extra as we see how the method plays out.

[Craig] What Frank stated, there’s at this time limit no definitive record of “this will probably be in 1.Four”. There’s all these things we need to get into 1.Four but we might start pushing some of that into 1.5 relying on how issues go.

[Bill]- I hope for higher drawing tools.- I would like to have the ability to click on on a previously drawn texture and then have the ability to draw with that texture, even if I have it in my library or not.- I want to see shadowing for partitions however Maptool would wish to make the most of the video card to try this.- I might additionally wish to see MT broaden a bit on the unbound map code a bit, permitting us to make use of multiple texture information as an alternative of just one – randomly putting them.- Layers! 🙂

Presently, MapTool has Token, Object, Background, and Invisible layers. How will the new layering system work?

[Frank] There are a variety of concepts in this space. We wish user-defined layers. A great configuration would permit the consumer to create a layer named “Lead Partitions” and then define a sight sort referred to as “X-Ray”. Now the consumer might specify that something on the Lead Walls layers would block the imaginative and prescient of sort X-Ray. However it needs to be more common than that — we wish layers to be able to block sight, but in addition block movement. We also need terrain varieties and/or motion modifiers. Perhaps it’s even attainable to outline layer to characterize elevations — somebody at a lower elevation would treat the layer as a sight-blocking layer (since they will’t see over it), but somebody at a better elevation would be capable of see it clearly.

All of those concepts are being mentioned amongst the event group and as we break the appliance into modules (see the previous query) we’ll have the ability to better decide what’s reasonable for implementation in 1.Four.

[Craig] As Frank has stated discussions are nonetheless occurring about layers. Though I see how Imaginative and prescient Blocking interacts with mild and imaginative and prescient more of an attribute of the vision blocker itself fairly than the layer. Also, I feel we’re shifting away from elevation as after approaching it a number of ways we maintain operating into the truth that it makes defining maps too exhausting. The newest concept that has been floated is the GM can define as many objects, tokens, background layers as they like and conceal/show them and get them organized inside their very own category how they like, but all backgrounds will all the time be behind all objects which can all the time be behind all tokens.

[Bill] Layering is at present beneath discussion on the forums. It is rather complicated and we need to ensure that we handle it the best means so that straightforward customers can use Maptool and advanced customers could have the facility they want. In the meanwhile, I feel the three of us are in agreement that we’ll have the choice to pick certain drawables, objects, and different ‘issues’, and send it over to some kind of Map Manager (assume Map Explorer on steroids) to handle them better throughout a recreation.

Will the power to use VBL to objects be in place early within the 1.4 improvement cycle?

[Frank] Unlikely. As I discussed above, 1.4b01 will probably be primarily the same as 1.three Last. It is going to just be broken into modules. I do know I maintain harping on that “module” concept, nevertheless it’s essential for an software the dimensions of MapTool to be organized in a logical method and much of MapTool’s current improvement has been somewhat “natural” — which means it’s been growing with none long-term design objectives. We purpose to vary that in 1.Four through the use of modules to sharply outline performance, then we’ll go back and start adding new features.

[Bill] I’ve heard numerous “VBL on objects” coming from Craig recently, so it feels like he has this within the entrance of his mind.

Any modifications or additions to the drawing instruments or templates planned?

[Frank] Oh yeah…! One difficulty with MT proper now’s that drawables (which suggests all drawings on the map, together with templates) usually are not objects per se; they will’t be selected and moved, for example. We would like them to turn out to be first-class residents: choosing, rotating, resizing, and so forth. This performs into your earlier question about layers: ought to we’ve one layer for all drawables? It’s very possible that the consumer will be capable of outline which layers can include drawables and which may include templates. If a consumer only has certainly one of every, then any attempt so as to add a drawable or template would mechanically use that layer. This enables the consumer to outline the drawing order of every. If the consumer defines a number of layers as with the ability to include drawables, then they would wish to pick one as part of the drawing process. There are consumer interface issues in each instances so we’ll be performing some analysis to determine which methods may work greatest for the consumer group. That is the type of thing that may end in a public construct of MapTool: we’ll need the group’s input on how greatest to deal with this!

[Bill] I like the whole lot Frank stated. It is going to be nice dropping down that spell after which with the ability to move it around the battlefield 🙂

Any new map properties on the horizon?

[Frank] Map properties? Like what? The maps pretty much have every thing they want. The image belongings shall be getting some massive upgrades although.
For instance, proper now each token 100% encapsulates a “unit” on the map (could possibly be a PC, a creature, or a tank relying on the game being performed).

This can change. In 1.Four the token shall be a reference to the unit, but not the precise unit itself. Windows customers can think of “shortcuts”, OS X users can consider “aliases”, and Unix/Linux users can consider “symbolic links”. There shall be a single unit defined inside the campaign and the tokens will reference back to that single unit. So if there are three tokens across three maps that each one confer with the same unit, only one set of properties will apply.

This could considerably simplify the process of managing models on a map.

[Bill] I haven’t actually thought of properties at this point besides that I hope to have rule sets that we will snap in to make Maptool run a sure approach. If you want to play D&D, snap-in that rule set – Savage Worlds, that rule set.

I perceive the Vision code might be rewritten. Will the Mild system functionally change or is it principally underneath the covers modifications to make it more environment friendly?

[Frank] This is Craig’s child, so I’ll let him cowl it in additional element. But my understanding is that the imaginative and prescient code is being rewritten. He’s presently investigating whether or not there are commonplace libraries that can be used by MapTool or whether or not we should always maintain our own code however revise the algorithms to be quicker and more environment friendly.

[Craig] Vision and Mild shall be getting revamped. What we need to do is present a solution to outline several types of vision (e.g. x-ray, see invisible and so forth), and then the GM might define what forms of imaginative and prescient each of their mild sources interact with, in addition to what sort of vision each of the vision blocking objects blocks. That means x-ray vision might see via most walls but regular vision would not have the ability to. The underlying implementation of imaginative and prescient/mild shall be extra efficient but I’m positive individuals will still have the ability to sluggish it down given it is possible for you to to make it do far more.

[Bill] If there’s one factor I want to see probably the most with lighting, it might be for it to appear to be lighting. I’ve found that throughout the years, many users confuse FOW and vision with lighting. I want to make lighting extra apparent. Does that mean wavering 3d glowing or edges which might be pale? That you’ll have to ask Craig and Frank..

[Frank] Heh, I can agree with that confusion! Imaginative and prescient (Off/Day/Night time), Fog (onerous/tender), Mild (mild/aura), and Sight are very complicated to new customers. Heck, they’re confusing to present users! A part of the issue is that we have now so many options! While working on the brand new Individual View and Particular person Fog options it’s turn into clear that if some options have been removed not solely would the code be a lot easier, however it might be easier for us to doc how MapTool works and thus make it simpler to customers to know.

Will the Imaginative and prescient Blocking Layer change in the best way VBL is positioned and edited?

[Frank] That depends upon the results of the earlier question. 🙂

[Craig] Sure. I don’t assume there might be a selected vision blocking layer in 1.4, as an alternative, the “walls” (I’ll name them walls here for lack of a better identify) will probably be drawn on different layers reminiscent of background/token/object layers. So there will probably be no specific imaginative and prescient blocking layer anymore, as an alternative, you’ll draw walls on your layers in order you cover or reveal them you also disguise or reveal the walls related to them, likewise including an object that blocks imaginative and prescient can be potential. To facilitate that I feel we need to change how vision blocking is drawn and modified, in 1.three you draw your VBL and its then nothing greater than a line on the map, you possibly can erase it but you’ll be able to’t move it or edit it in any approach. In 1.Four we’d change this to be able to choose the strains/polygon that you’ve laid down and move it or edit it in some ways.

[Bill] I’m positive there can be much dialogue with this now that I read Craig’s replace 🙂

There are various methods to strategy it for positive – all is dependent upon how we deal with layering.

[Craig] And the discussion has begun ;).

Are there plans to implement a Movement Blocking/Movement Hindering Layer? In that case, how will it work?

[Frank] As described beneath the Layers query, above, “sure”. The movement blocking function might be tough. Let’s say a consumer has a sq. grid on the map. Let’s also say that an MBL has been defined. So the consumer draws some terrain on the MBL and only part of a square grid cell is roofed. How does that affect the token movement? If the terrain is outlined as 2x movement and the grid cell is 50% coated, does that make the movement 1.5x?

I anticipate that any MBL we add can be considerably late in the 1.4 cycle as we could have loads of different particulars to work out earlier than we get to MBL. I might be mistaken though — Craig might discover some simple answer to MBL points whereas working on the vision module.

[Craig] I don’t assume there’s any simple answer that may tackle all the points I can consider with Motion blocking/hindering. I want so as to add more info here once I get a chance 🙂

Perhaps outline a layer with the diploma of movement blocking (1.5x, 2x, .5x and so forth.) after which anything placed on the layer would block movement by that much? My pref for gridded movement can be any part of a square that was crammed induced the complete sq. to be crammed. Gridless affects movement by the part of the motion passing over the (no matter). Sorry for the kibitz. Couldn’t resist.

[Craig] The issue is more with the trail discovering. Once you add variable movement prices it either significantly will increase the quantity of labor that the map maker should do to get path working decently or the quantity of processing time that MapTool needs to spend processing the Map before it can be played on (this processing time would also happen when ever you modify the movement blocking or movement value).

[Bill] I want to see movement hindering. In D&D for instance, it costs double motion to walk by means of sure cells. If MapTool might precisely rely my motion, that might rock.

Will 1.4 help sound and animated GIFs?

[Frank] Sound? Very possible. There’s an present library that we will (in all probability) plug into MT and use. We will require a GUI to be outlined and maintained, and we’ll have to do some safety testing of the library, however I’ve excessive hopes for this.

Animated GIFs? Undoubtedly. There are some points with animated GIFs in Java — the libraries don’t provide direct help. We’ll possible have to create a layer of code that acknowledges animated GIFs as distinct from non-animated GIFs. That layer of code can be chargeable for registering some sort of countdown timer in order that it will possibly cause the subsequent body of an animated GIF to be displayed. And we’ll want a UI that permits the consumer to regulate the velocity of each individual animation in addition to an general velocity for all animations inside MT (so that users with slower machines can select to turn them off solely if they want).

Ideally, we’d have the ability to use animated PNGs as an alternative, since GIFs could also be patent encumbered. But the APNG format is simply a group normal at this point and not an business normal. Meaning it solely works in certain purposes (like Firefox) and doesn’t have widespread help in painting purposes (like PhotoShop or GIMP).

[Bill] I hope to see sound carried out. I did a mock-up of how I would really like it accomplished but I play nose to nose so I’m uncertain how all of it will work when going over the wire. Sound may be very complicated in its own (mixing, channels, results, proximity volume, looping, asset administration, streaming, and so forth) and I am unsure if anyone on the workforce really has the experience or perhaps even has the will to do what I might need Maptool to do on the end of the day.

But like all the rest of you, I might be proud of even easy sound implementation since it will be more than what we’ve got now in 1.3. It won’t be the ambient march of the dragon soundscape, but when we will have just an image on the map that a consumer can click to play one thing, that is higher than nothing.

How about things like object opacity?

[Frank] As you realize, PNGs already have transparency. However I anticipate we’ll have a UI that permits a picture’s general opacity to be adjusted, probably just through the use of a slider. This could have vital performance implications, nevertheless; if the consumer doesn’t have hardware help for any such operation, doing the work in software program will definitely be a efficiency hit. This might be a problem for Netbook customers, for example. So as with the animated GIFs, we’ll need a way for the consumer to show it off utterly by way of the Preferences.

[Bill] Hardware help. That seems to be the key for doing most of the cool things I need to do, including shadows on walls and glowing torches. I assume by the point 1.4 is usable, everybody’s previous laptops could have nice video cards in them that can pull it off 🙂

How will handouts change in 1.4? Will we have now the power to load reference PDFs for the gamers?

[Frank] There are libraries that permit PDFs to be displayed by a Java software. We might want to evaluate them for (a) security and (b) compatibility. Typically these forms of libraries open home windows themselves and 100% management the show of the contents. Meaning we might be unable to regulate any theming of the window and that is perhaps an issue. This is one other area that we’ll be evaluating as we get nearer to having 1.4b01.

[Bill] I feel we will all agree that handouts are a should for 1.4. In my good world, I can think about a meeting room where gamers can look over handouts, take a look at maps, and chat earlier than the game starts. I can even see accessing those self same documents through the recreation.

At present, the macro writers have devised clever ways to do things like teleport from one map to the opposite and use a motion pad to track movement. Will these commonly used features be absorbed into the MapTool code base or will they remain in the realm of macros?

[Frank] Many things will stay within the realm of macros. We would like MapTool to be generic enough to be used with any recreation you may choose to play. So absorbing issues into the MapTool code exposes two issues: changing how they work requires a new construct from us, and customers can’t design their very own implementations of this stuff.

[Craig] Some simple issues like teleport to other map or waypoints are potential since they are often made to work with many techniques, for different things then JavaScript macros and/or plugins can provide performance that is tailor-made to a selected system.

[Bill] I hope to implement warp factors. Place Point A on a map and place Level B elsewhere and the token can warp between those two factors. Perhaps permit the choice to solely change the map view with out shifting the precise token. *shrug*

[Frank] (None of which requires help inside MT beyond what it presently has. But it will be good if the consumer might select a “rule set” and have certain options (read: macros) imported routinely.)
That doesn’t mean that these macros gained’t be pre-packaged with the MT download. In reality, I anticipate that plenty of MapTool will turn out to be “on-demand” in 1.4. I want to have a Preferences dialog through which the consumer chooses which options they need and only these features are loaded and out there. This shall be something that may be chosen at run-time. Campaign information may have an inventory of options that they require as nicely, so if a consumer indicates they want features A, B, and C, and then they load a marketing campaign that also requires D, they’ll get a immediate asking if that function ought to be enabled. If they are saying no, the campaign isn’t loaded. If they are saying yes, then we’ll verify for function dependencies (in any case, function D might require E and F to work properly) after which load the campaign.

These features will probably be downloadable from our website on the fly. So if a campaign says it wants function D and the native MapTool set up has no clue what “D” is, it’s going to examine our site and get the knowledge it wants — including the code for the function itself!

What are the primary holes you see in the current 1.3 GUI?

[Frank] Wow. We don’t have time for this question. ;-)The Start Server dialog needs some major work (there are method too many individuals with network questions on the forum and a redesign would assist with that, plus we would like to be able to save the settings and restore them simply later). The varied file choosers (akin to Save Campaign, Save Token, Load Macro Set, and so forth) aren’t consistent from one space to a different. The MapTool code handles mouse events by itself as an alternative of using the amenities offered by the language run-time and this causes some UI incompatibilities with the platform (Windows, Linux, OSX) relating to drag/drop and the context menus. A number of the things that appear in the dialog bins are hard-coded and cannot be translated (such because the “PC” and “NPC” designations, but in addition token styles and sizes).

[Craig] As well as what Frank mentioned let’s see: the dialogs to arrange imaginative and prescient and lighting, the transmitting of the whole token to shoppers each time you move it, the anti-cheating mechanism for rolling cube must be more strong, the best way the macro buttons on the selection panel are completed (the continual recreation on choice actually kills performance when choosing giant groups).

[Bill] Holes?

Will the GUI change dramatically in 1.4 or is it principally additions to the present format?

[Frank] We’ve got pie-in-the-sky hopes for altering the GUI. My private perception is that modifications like we’ve been speaking about (the dev-team, that’s) are beyond what we should always plan for 1.Four.

In some ways, 1.4 can be better referred to as “2.0” because the inner structure goes to be considerably totally different. Yet “1.Four” is sensible because we don’t anticipate a huge shift in the initial UI. If we referred to as it 2.zero due to the interior modifications, then the model that comes with the GUI modifications must be “3.0” as a result of that might be one other vital shift.

[Craig] I feel the most important GUI change in 1.Four will probably be fixing some dialogs that basically want fixing and probably a revamp of some areas like the Map Explorer. The more dramatic GUI enhancements should wait until at the least 1.5.

[Bill] I feel we will all agree that Maptool is ugly. I feel considered one of our objectives shall be to make it prettier. I do know we have now had loads of nice ideas despatched from our dedicated consumer base and we’re reviewing lots of them. If anyone has ideas or mock-ups of how MT might look nicer, move them along to us. None of us are great artists 🙂

[Frank] Agreed! As Dorpond says, anyone with concepts — or expertise! — is welcome to start out a thread on the forum relating to what they want to see. As we get nearer to 1.4b01 I might be creating 1.Four-specific boards.

Thanks once more to the Gang of three for their enter. Search for the conclusion of the 1.4 interview questions next week.