1.4 Blast From the Past Games Interview

Blast from the Past: Planned Changes for MapTool 1.4 pt2

Blast from the Past: Planned Changes for MapTool 1.4 pt1

This is part two of a 2011 interview completed at the finish of MapTool 1.3 improvement. It’s a fun article to learn once more in any case these years. We’ve completed quite a lot of the 1.four plans but had to delay a few of the hopes resulting from 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 a part of the 1.5 collection. MapTool 2.0 is the place we at present plan to implement the brand new Consumer Interface in Java FX.

The article initially appeared on the Tales of the Savage Troll lavatory. You possibly can learn Half 1 here.


This is the second half of the MapTool 1.4 interview with Frank, Craig, and Invoice the challenge leaders for MapTool.

In part one, we mentioned the consumer interface modifications planned for 1.4. In this portion, we give attention to Macros, underlying architecture modifications, JavaScript, third-party software integration, and MapTool plug-ins.

Macro Questions:

How will the new macro system be totally different? (if it isn’t too much hassle might you give us some previous/ugly code and describe what the brand new js version would appear to be?)

[Frank] I’ll let Craig handle this. Remember that JS macros will only be out there to the GM. Users will nonetheless have entry to cube rolling stuff, and the power to call features that the GM has “exported” or “made public”. However all JS stuff is the realm of the GM. The objective is to take away the complexity from the customers as a lot as potential.

I’m of two minds on this. I agree with the precept, but I do know that within the games I play I’m typically the one tweaking or modifying the macros! As a participant I wouldn’t have the ability to do that during a recreation session if it was limited to the GM only. So I’ll foyer for some way to offer that access to the gamers…

[Craig] I feel one of many classes discovered from 1.3 macros is the whole Trusted vs Non Trusted factor shouldn’t be properly understood, and it’s really arduous for a lot of people to return to phrases with, not to point out get proper throughout coding of the macro features. Having a clear dividing line of only GMs can create JavaScript macros solves this drawback, it’s also actually the only approach to make sure that the GM can retain management of the game. If we have been to allow gamers to run their very own JavaScript code then there’s actually no strategy to cease them from doing issues they should not be doing with out getting into a state of affairs that’s much more complicated than the 1.3 Trusted/Non Trusted technique.

What would the JavaScript code appear to be? That’s exhausting to say in the mean time, but for gamers, they might simply use [] or to name them. For instance: [dnd42.attack()].

[] / will in all probability be restricted to simple arithmetic and calling features, so that you wont get all these brackets like in 1.three.

I perceive the previous frameworks will break fairly early in the 1.4 improvement process. For the framework builders, the place are they going to spend most of their time within the rewrite?

[Frank] Learning the brand new JS interfaces! The JS macros will present an enormous profit by being a structured, consistent language. MT will export plenty of features that the JS macro writers will have the ability to invoke to query the standing of tokens, maps, campaigns, buttons, and so forth. Just finding out what those features are and enjoying with them will take some time. I anticipate that there might be Eight-16 hours of such “play time” wanted for somebody who’s proficient with MTscript to develop into equally proficient with the JS language interface.
After that? Who is aware of? I would like the power for JS programmers to throw a custom-written dialog field up on the display and let the consumer interact with it.

Kind of like how the MTscript enter() perform works but with the JSdeveloper with the ability to add any HTML element they need and with any format scheme they want. This is totally potential given our current plans, but there’s some dialogue about whether or not this can be a good concept or not. 🙂 As that is really Craig’s child, I’m going to defer to his judgment on this regard.

[Craig] There shall be slightly bit of pain with regards to re-doing your 1.three body work for 1.four, however there will even be a whole lot of benefit. I might anticipate that a lot more reusable libraries can be produced making it easier to load somebody else’s inventory library for example somewhat than having to position your personal. JavaScript can also be quite a bit much less fiddly than MTScript so there ought to be an enormous benefit there. Additionally the API will probably be more constant than the one that was type of thrown together from totally different elements in 1.3. Plugins also needs to be capable of present an API for JavaScript macros to call so if anyone does need to write their own “does the whole lot stock” plug-in they will provide ways for macros to interact with it.

I also think about there might be loads of builds before 1.4 is ready for enjoying your weekly recreation giving people who need to develop macro libraries or frameworks loads of time study the new macro system and construct what they need earlier than shifting over to 1.four.

Craig’s mentioned greater than as soon as he’d wish to see a windowing system to help character sheets together with JavaScript features to remove/scale back the need for the HTML frame features. Will this occur in 1.four?

[Craig] I feel the character sheets idea that has been thrown round will appear in some type — probably very totally different from the present concept — as one of many first plug-ins for 1.four.

What sort of new tools shall be obtainable to the framework builders?

[Craig] From a creating code perspective, we have to make it simpler to write down your code in your favorite editor and load it into MapTool, in addition to get it out and edit it. From a “what new things can I do with it” perspective, I don’t assume the boundaries for what we’ll permit have been outlined yet, but given plugins can permit JavaScript macros to work together with them there can be a variety of issues it is possible for you to to do in 1.four which you could’t do in 1.3.

Will the token properties have assignable knowledge varieties (numeric, character, JSON) and attributes (fastened size, arrays/lists, and so forth.)

[Frank] I don’t see “fastened varieties” as essential. In a method they are, but JS itself doesn’t have fastened varieties so grafting that onto the language can be troublesome. Extra doubtless is that properties may have an “input mask” that can be specified. This masks would outline what the sector can appear to be. So fields meant to be numeric might have a mask that has one thing like “#,##zero” to indicate that a numeric worth with commas inserted in the fitting locations in the correct format. There are quite a few points with this. For instance, when retrieved from JS the commas have to be removed for use in math formulas, but need to be there for display purposes — how can we determine which is which? Whatever method we use it needs to be straightforward to know and the defaults have to make sense.

At present tokens serve as knowledge and code stores for the frameworks. You’re pressured into an odd place of getting tabular knowledge as token properties and saving code on a token. What improvements can we anticipate in 1.4 relating to inner knowledge and code stores for MapTool? (let me know if that is unclear)

[Frank] There gained’t be any code shops on tokens in any respect. At the least, that’s my understanding of Craig’s vision. All code is ONLY in JS and subsequently is underneath the management of the GM. And the JS code will probably be in its own storage space and never a part of any specific token.

[Craig] JavaScript code will all be managed inside the marketing campaign and never hooked up to any token in any respect. Library tokens are type of a hack that was wanted to make code straightforward to move around in 1.3 without having to make a number of modifications.

What about knowledge tables?

[Craig] Unsure about this in the intervening time, we now have to provide you with a better approach of storing knowledge if macros are going to be manipulating extra complicated knowledge buildings but we don’t know the how or the place yet. I know there have been a variety of requests for a database in MapTool, however this opens a can of worms, can we replicate the database knowledge between all shoppers, or does only the shopper that masses the campaign have access. However that signifies that no knowledge is native and all the things all the time needs to be fetched throughout the network when it’s used. There’s also the question of where would a database be stored — inside or outdoors of the marketing campaign file.

[Frank] There might, in fact, be a plug-in written by a consumer that gives database access. In fact, they might be answerable for the database code, the features used by JS to entry it, and so on. This lets the dev-team work on MT whereas someone else works on the plug-in.

Will macros, properties, and knowledge be exportable for straightforward distribution as canned settings and not using a prerequisite map or tokens?

[Frank] I’m unsure on this one. I envision a GUI that permits individuals to place check-boxes subsequent to individual gadgets after which click on “Export” and have a single file containing these pieces. Import would work similarly. (Actually, this code is already in 1.3 but the menu options are disabled because it isn’t hooked into the remainder of the code but.)

We anticipate that framework builders will produce bundles which might be similar to the Art Packs that MT already has. Framework developers will submit their framework on the forum and have other individuals attempt it out. When it’s ready, we’ll upload it to RPTools.internet and it will develop into obtainable to everyone utilizing MapTool. The bundle could be named “D&D3.5/PF” or “GURPS” in order that the GM can select one shortly and easily.

Identical to the Art Packs, the GM will be capable of enter a URL as an alternative so that the framework doesn’t have to return from the RPTools website (this enables for straightforward private distribution, for testing purposes for example).

Other Questions:

MapTool is shifting to an OSGi implementation. Are you able to explain this in layman’s phrases what this is and the way this benefits the top consumer?

[Frank] OSGi is a system of modularizing an software by breaking it down into elements. These elements can then be enabled or disabled on the fly. Elements might be saved regionally or accessed by way of a URL.

The most important advantage to the consumer can be for plugins. In a previous question I postulated a campaign that required features A, B, C, and D. Using OSGi will permit us (the builders) to easily say “enable function D” and the OSGi library will find a website online that has that function, download it, install it, after which allow it for MapTool use. So probably the most visible function to the consumer will probably be transparent updates of performance and options.

I plan to have an OSGi bundle answerable for frameworks, for instance. When the consumer starts MapTool the bundle manager will verify to see if a more moderen framework is accessible and supply the option of downloading it.

[Craig] There are two huge advantages that OSGi may have for players. The extra apparent is it’ll permit them to put in plugins that others write that may supply further functionality. The second is it should lead to increased stability. Since OSGi permits us to outline clear boundaries between the totally different elements of the code, so changing one part of the code is quite a bit less more likely to break one thing else.

[Bill] Once more, not my space of expertise. Ozzgee? What in the heck is an Ozzgee? 🙂

Presently, MapTool uses the “hey everybody, get in and check” technique of QA. Will there be any automated testing attainable beneath the new structure?

[Frank] There are some automated testing tools in place already (using jUnit). However not sufficient. So yes, we anticipate to incorporate extra automated testing. Having stated that, automated testing of a GUI is fraught with problems and it’s probably that MT will never have 100% automated testing.

Any interfaces planned for non-RPTools merchandise? Are there any modifications coming that may make it simpler to interface with third celebration tools?

[Frank] The OSGi bundle supervisor should help with this. We plan to have a “plug-in structure” out there that may make it simpler for third events to work together with MapTool internally. I anticipate tasks like PCGen would be the most interested in this, and I anticipate we’ll be collaborating with them to make it possible for we offer no matter providers they need to make this work.

There are RPTools discussion board customers who have written some superb issues. Using the plug-in strategy would considerably help with what they are doing. For instance, there’s a “dungeon builder” app written as a spreadsheet. It dumps out letters to characterize the contents of grid cells and then a MapTool macro reads these letters and builds a map. With a plug-in, the method can be significantly quicker and could possibly be more automated.

We’re going to be watching Oracle intently to determine if/when the JavaFX extension turns into extra usable. IMO the last word plug-in can be written in JFX. JFX can build dialog packing containers and populate them with knowledge learn from MapTool and/or knowledge learn from local disk information (if safety will permit it). The JFX plug-ins are true Java code so they may run on the velocity of Java, not the velocity of a totally interpreted language like MTscript or JS.

I understand a part of the OSGi rewrite will make it simpler to create plug-ins for MapTool. What sort of plug-ins do you anticipate?

[Craig] To start out with I feel we’ll see issues like a recreation system particular initiative panel, inventory/spell/talent managers. I couldn’t even begin to guess in any respect the forms of plugins that folks might create although.

[Bill] I hope to ultimately see all types of user-created plug-ins obtainable for Maptool, floating everywhere in the net. Rock on! 🙂

[Frank] I want to see plug-ins for game-specific stuff. The line of sight for D&D. Charsheet tools maybe. Terrain modifiers or movement controls. Maybe even a simple database (something like hSQL or SQLite). Since plug-ins might be extending MapTool itself, they might do virtually something.

Will the plug-ins permit for dramatic modifications in the best way MapTool knowledge is displayed like web-displayed maps, cellular system implementations, or interaction with different purposes?

[Frank] Probably. But I see them as extra of a game-control function than a presentation function.

I already have a plan to put a server (an OSGi bundle) on port 80 so that a browser might hook up with MT and see an image of the present map. However maybe plugins will provide one thing comparable. It’s a plug-in so who knows what individuals will do with it?! I definitely wouldn’t have foreseen what a number of the scriptwriters have executed in 1.three!

What elements of 1.four are most enjoyable to you as a developer?

[Frank] I’m actually wanting forward to the reorganization of the code. It ought to open up a whole lot of prospects with making MapTool more dynamic (like the plug-ins, for instance) and that, in flip, allows for options to be added independently of different features so we should always have the ability to add them quicker and extra reliably.

[Craig] Taking a look at how a lot there’s to be achieved I am experiencing extra trepidation than excitement in the intervening time 🙂

[Bill] I’m not a developer but I’m excited probably the most about Maptool having recent eyes. I actually can’t wait to see what Frank and Craig can provide you with on the end of the day.

What elements of 1.four are most enjoyable to you as a gamer/GM?

[Frank] Heh-heh. All of it! 🙂 JavaScript, easier-to-use dialogs, customizing with JavaFX, user-defined layers, … Yep, “all the things”!

[Craig] Extra versatile mapping/imaginative and prescient/lighting, movable spell templates, in addition to a better macro system.

[Bill] Making MapTool easier to use for my pals who need to use MapTool like I do but haven’t any clue how I do it.
Thanks once more for taking day trip to answer these questions for MapTool Month on TheSavageTroll.

[Bill] Thanks too, pal!