MapTool 1.4

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

Moderators: dorpond, trevor, Azhrei

Post Reply
Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

MapTool 1.4

Post by Craig »

MapTool Direction
As most of you probably know Trevor is currently on hiatus enjoying other aspects of life and hopefully enjoying a well deserved break from MapTool coding and recharging of his batteries. What does this mean for MapTool and the plans for 1.4? As Trevor was running out the door screaming "spring break" he turned around and pointed to the two closest people -- which just happened to be Azhrei and my self -- and said "I trust you guys, run with it" -- or "tag, you are it" if you prefer. So for the immediate future Azhrei and I will be taking over the stuff that Trevor was previously doing -- which also includes what Trevor took on board from giliath etc.
So this includes
MapTool
TokenTool
DiceTool??
and the "support projects"
parser
rplib
dicelib
For the above listed tools Azhrei and my self will be performing the architectural design of the above listed tools and in conjunction with Dorpond setting the direction for and the design for 1.4.

Azhrei is in charge of builds for 1.3 -- and maybe 1.4 but we haven't discussed that yet and he might get tired of doing it ;). While there has been a little prep work for 1.4 I am hoping that development for it can begin in earnest by November.

Thankfully Azhrei and I won't have to do all the coding as there are plenty of people willing to contribute, I am not going to name them in this post because 1) I will forget someone, and 2) I don't want to commit someone to something they don't have the time or inclination to do ;).

The following is a short summary of the 1.4 plans
  • Improve mapping functionality
  • Plug up some holes in the 1.3 GUI
  • Create a new "clean" version of the macro system
  • Large scale architecture changes that will lead to more stability, facilitate plug ins and make it a lot easier to move MapTool forward post 1.4
Unfortunately this list is not going address all of the feature requests for 1.4, but resources are limited and 1.3 has really grown in many different directions than Trevor had been thinking about when he started it so it is in need of a fair amount of architectural changes. So it came down to a choice between
  • Adding functionality and deferring architectural post 1.4 -- essentially delay the pain, but the pain will be a lot worse when it comes.
  • Adding minimal functionality and addressing all of the architectural issues.
  • The middle ground where we add quite a bit of functionality, and start addressing the architectural issues removing many and isolating the rest.
We went for the middle ground and I think we have the balance right. Keep reading for a -- slightly -- more detailed list of the planed changes.


Streamlining the build process
Ok this one is probably not exciting to 99.999999999% of all MapTool users, but I am sure it will make Azheri happy, and should hopefully make it easier for those wanting to help test.

Source Control
We will be moving from svn to git. Again something that won't be exciting to most MapTool users, but it does mean more flexibility for how contributions are handled.

Moving MapTool to OSGi
While this is a big change to the architecture of MapTool it offers a lot of benefits. The first is the different components will be less tightly coupled allowing for less chance of "breaking things" when making changes and a lot easier testing, which should all lead to a lot more stable MapTool. The second major benefit is it will allow people to write plugins for MapTool. I believe Jay is really keen to create plugin versions of his programs.

Macro Language Changes
GM's will be able to add macro libraries written in JavaScript -- only the GM, the players will not have access to JavaScript code in the campaign so that the GM can still control the game and this will remove a lot of the confusion over trusted functions. The GM will be able to decide (or let the library defaults decide) which functions the players can call in their macros using the [ ] / { } syntax the way they call user defined functions today. The complicated parts of the old macro syntax -- looping, conditional branching, code blocks -- will not be carried over, simple expressions such as [2d20 + 2 + strMod + bonus] will still work. Please no replies/PMs/etc on what about ruby, what about python, what about prolog/lisp/cobol :) Adding more than one language leads to an exponential effort to create bindings/support/etc.

Dice Expressions
It will be possible to add new dice expressions -- things like 2d10, 3o6 etc -- using JavaScript macros. More than likely all the current rolls in dicelib will be rewritten in JavaScript so that the GM can modify them for their campaign.

Vision and Lighting
Along with moving to OSGi architecture this is the biggest change. The plan is to completely rewrite this part using a much more efficient way of representing and rendering VBL. This will allow for things that are not possible to do with the current way vision is handled as well as faster rendering. We are looking to add GM definable light and vision types, and the ability to define if VBL blocks one type of light/vision and not another (so you could have x ray vision for example). Objects/Tokens will be able to have different types of images depending on what vision type they are "seen with"

Multiple Layers
The map will have multiple layers, these will act a lot like layers in drawing programs allowing the GM to set who sees what layer etc.

Movement Blocking
There will be movement blocking/penalty functionality where the GM can "draw" areas on the map that the player cant move or will require extra cost to move.

A better hand out system
We will be adding support for handouts within a campaign that the GM can store in a "hand out library". The goal is to be able to hold things like PDFs -- viewable but probably not editable. This will mean that the campaign will be able to store objects other than just text or pictures, which will at some stage in the future be useful for sounds etc.


Other bits and pieces
  • A way to export/import campaign settings
  • An update to states and bars to make them more flexible
  • A restructuring of Tokens, so that tokens are just the maps representation of "characters", so you could have a token on different maps that points to the same PC or NPC.
  • Add more unit testing using junit
  • Fix up/add JavaDoc where we can
  • Continue to improve internationalisation
  • Support for card decks/hands etc.
  • Fix the big missing bits in the interface (Light and Vision dialogs anyone?)

Then there are the things that may have been implied or promised for 1.4 over the LOOONG journey that was1.3 that are not likely to be in 1.4. The big ones that I can think of off the top of my head are.

GUI Changes
The big GUI revamp that Trevor was going to do is not going to happen in 1.4. But there will be a lot of clean up of existing problems. When it comes to the eye candy GUI rewrite I will be keeping a close eye on the JavaFX 2.0 API library for Java -- not to be confused with JavaFX script -- which is coming out second half of 2011 to see how we can make use of it. JavaFX 2.0 will contain a HTML 5 renderer so this would solve a lot of the current HTML issues. For anyone interested you can find the JavaFX 2.0 road map here

Headless Sever
Its unlikely that as part of 1.4 road map there will be a headless server mode. Its plausible that the OSGi work that is done for 1.4 that it would be achievable but we not going to commit to it at this point.

So what time frame are we talking about? At the moment that is a little hard to gauge given that no one who will be doing the coding/design knows as much about the MapTool code base as Trevor did and we don't at the moment have much experience with OSGi. These changes are large so there is going to be a lot of development that needs to be done before 1.4 gets to the point where you will be able to run games with it reliably. The idea -- hopefully -- will be to focus on the above tasks and not get caught up with scope creep distracting us, and have a much shorter "stabilization phase" than 1.3. This means even though it will take longer to get a "playable" 1.4 than it took to get a "playable" 1.3 a "release" 1.4 will come around a lot quicker than it did with 1.3. This means some things will take longer to get into MapTool but the majority of things will be in MapTool in a "complete" form earlier than they would be otherwise. There has been some preparation work done for 1.4 already but there is more we need to do before we can start development proper. The next steps for 1.4 are do some more nutting out of the design, streamline the build and then work on OSGi modifications, hopefully by the end of November we can give you a better road map although given that we all have jobs and no one works on MapTool full time the road map is not going to contain really specific time frames.

What does this mean for contributions that are not on the above list? Being an open source project its not likely that everyone who wants to contribute will want to do something on that list, after all everyone will have things they need or great ideas we didn't think of. So I want every one to know contributions are always welcome and appreciated even if they are not on the what we plan for 1.4 list. Saying that though I should state that any contribution will be more likely to be accepted if it doesn't require large modifications to the above plans or for others to delay what they are doing for a long time to complete it, if you have an idea of something you really want to do then contact us or start a thread before you put a lot of work into as its easier to change things before you do a lot of coding than once its done ;)

Cweord
Great Wyrm
Posts: 1343
Joined: Sun Aug 12, 2007 10:49 am
Location: Midsomer Norton, (Near Bath), UK
Contact:

Re: MapTool 1.4

Post by Cweord »

I think you guys have made the right choice, We may not get instant gratification out of it - the the ability to add and improve long term will make things faster in the long run.

Looks like the right guys were in the right place (or wrong place depending on your point of view) as Trevor fled for the hills.
Cweord

This message has been spell checked by Freudcheck - any mistakes are purley a figment of your imagination.
-------
My Tokens Directory
http://gallery.rptools.net/v/contrib/Cw ... er_Tokens/


User avatar
JonathanTheBlack
Dragon
Posts: 544
Joined: Mon Jun 28, 2010 12:12 pm
Location: I'm the worm...

Re: MapTool 1.4

Post by JonathanTheBlack »

The onnly GUI upgrade I would like to see is a way to create seperate chat channels either dynamically for each map or a DM can create one and invite players into it, so I can create a "Lobby" where players and DM's can hang out and put together pickup games. Sorta like an irc channel, but in MapTool.

User avatar
Scubba
Cave Troll
Posts: 90
Joined: Fri Oct 30, 2009 12:47 pm
Location: Oakland, CA

Re: MapTool 1.4

Post by Scubba »

Any plans for how some of these larger paradigm shifts are going to take place?
  • The codebase may be in a "broken" state for a while
  • Some of these projects will be difficult to share between contributors due to complexity or domain-specific knowledge
  • At a certain point patches written against the 1.3 code could be nigh-impossible to merge
Probably time for a branch, and a concurrent code/submission freeze when this really gets underway. Setting expectations is everything, after all.

Maybe also a rallying cry for contributors to the 1.4 effort?

And if we are serious about junit tests (YAY!) can we set up a bugbase? Pretty please?

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 »

I was wondering Will 1.3 frameworks/campaign files still load in 1.4. I know that with The script change all FW code needs to be rewritten but how's that with the other stuff?

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: MapTool 1.4

Post by jfrazierjr »

wolph42 wrote:I was wondering Will 1.3 frameworks/campaign files still load in 1.4. I know that with The script change all FW code needs to be rewritten but how's that with the other stuff?

Yes/No. Depending on how the project is going to be released, this may or may not be the case. What I do know is that at some point fairly early on, all of the loop/branch stuff will be removed and those cannot be done inside the MTScript. However, I have no idea if that will be done before or after b1 is released. Honestly, we have not really talked about that much and this is probably more of the things Craig mentions in the future updates on milestones in his first post.
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
brad
Great Wyrm
Posts: 1233
Joined: Fri Apr 27, 2007 10:27 pm
Location: NY
Contact:

Re: MapTool 1.4

Post by brad »

Thanks for the breakdown. Sounds like a good plan.
View MapTool video tutorials at RPToolsTutorials.net

User avatar
Guy Dude
Giant
Posts: 124
Joined: Thu Apr 09, 2009 4:10 pm

Re: MapTool 1.4

Post by Guy Dude »

Craig wrote:Movement Blocking
There will be movement blocking/penalty functionality where the GM can "draw" areas on the map that the player cant move or will require extra cost to move.
This sounds very useful!

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.4

Post by Azhrei »

Scubba wrote:Any plans for how some of these larger paradigm shifts are going to take place?
  • The codebase may be in a "broken" state for a while
  • Some of these projects will be difficult to share between contributors due to complexity or domain-specific knowledge
  • At a certain point patches written against the 1.3 code could be nigh-impossible to merge
Probably time for a branch, and a concurrent code/submission freeze when this really gets underway. Setting expectations is everything, after all.
My plan is to declare 1.3 a "bug fix only" version within the next few weeks. We are already in a "feature freeze" of sorts although I have about 40-50 things that I would love to have seen included in 1.3 in order to make it a more complete application -- something users can be happy with for 6 months or more while we pound away on 1.4.

Alas, Joe is going to try to fix a few of them, but there's no way all of them will make the cut!
Maybe also a rallying cry for contributors to the 1.4 effort?
We have always been open to accepting patches, even though it might not appear that way. Poor gioppo hasn't seen his drawing-with-VBL patches go in and that's all my fault -- I've been busy with bug fixes and trying to finish up features that had already been started. I was trying to lock down the code so that we could get something really stable for users to test hard...
And if we are serious about junit tests (YAY!) can we set up a bugbase? Pretty please?
We hope that using a DVCS will help with some of the above. For example, Git makes it extremely easy and fast to check out a branch and to have multiple branches at once. This should help me a lot when I'm receiving multiple patches from multiple people -- I can test each one separately from the others and merge them together when I'm happy with them. As things are lately, I haven't had the time to do proper testing so I've just been signing off on them and committing. (That takes us to a call for testing volunteers but jfrazierjr will be doing that separately in a separate thread.)

The bug tracker is another thing... The user whited has been working to clean up the existing bug tracker at SF. Removing stuff that doesn't need to be there and trying to keep things that are useful ideas for 1.4 so we don't lose them forever. :| I will start another thread on the bug tracker tonight or tomorrow night because we need some discussion on that topic.
wolph42 wrote:I was wondering Will 1.3 frameworks/campaign files still load in 1.4. I know that with The script change all FW code needs to be rewritten but how's that with the other stuff?
We really aren't sure, as jfrazierjr said.

There is the possibility that the first few builds of 1.4 (whenever they come out) might be able to load campaigns but I sort of doubt it. Part of the effort going into 1.4 is to restructure the code so that it provides a better foundation for things that will come later. Part of that restructuring will mean that existing data will be reorganized and rearranged, so old files may be unusable.

Once we begin the restructuring work we may find that maintaining upward compatibility is doable. In that case, we'll try it. If it is too painful then we'll be forced to amputate the leg so that the entire body doesn't die...

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: MapTool 1.4

Post by Craig »

wolph42 wrote:I was wondering Will 1.3 frameworks/campaign files still load in 1.4. I know that with The script change all FW code needs to be rewritten but how's that with the other stuff?
So I consulted my magic eight ball to see what its response to this question was and it replied "outlook not so good"

There are two main issues and they are macros and VBL. We really don't want to have to carry around all of the current macro language if we don't have to. I know this is going to upset a few people who have developed frame works, but the consolation is frame works will be a lot easier to build and a lot faster and reusable macro libraries will hopefully become a lot more common place. I strongly suspect that builds with the macro updates will start coming out quite a bit earlier than "hey its ok to use these in your games" builds which will give framework developers time to get great things done before everyone starts moving to 1.4. We will also try give people who want to develop frame works better ways of doing so than the current cut and paste from external editor based methods. And for those of you worried about not being programmers so how much harder is it gong to be for you to write macros, please don't worry, if you can write it in the current MTScript trust me you will find it easier in 1.4 in nearly every instance.

As for VBL the current way that VBL is stored and handled is unfortunately quite limiting so we need to change how VBL is internally represented. For all but the simplest cases its going to be very hard to convert from the old method to the new method programatically and end up with an efficient representation of the VBL.

Those are the two big issues. One possibility is a tool that converts as much as it possibly can from 1.3 to 1.4, although the question there is will everyone already have made the transition to 1.4 by the time we complete the tool so that is something we still need to discuss;) of course if there is anyone who wants to work on such a tool the we will be more than happy to provide help and any information they need.

It's not all doom and gloom though hopefully we can break the cycle of versions being completely incompatible. The macro language in 1.4 will be the macro language going forward, functions might get deprecated but they will still be around for a version or two after they have been so marked. VBL will be simplified and stored in a way that is easy to use no matter which of the many different ways we decide to do vision. And there has been some discussion already about making the XML for campaigns much easier to read which allows for easier to write conversion tools. Also it's not like 1.3 will be removed for download or stop working once 1.4 comes out, so you will be able to complete your campaign in 1.3 and move to 1.4 and there will be plenty of time to make the transition, trust me stable 1.4 builds are not going to sneak up on you and surprise you ;)

Cweord
Great Wyrm
Posts: 1343
Joined: Sun Aug 12, 2007 10:49 am
Location: Midsomer Norton, (Near Bath), UK
Contact:

Re: MapTool 1.4

Post by Cweord »

Will there be any easy way to transfer maps - sans vbl, just the standard layers over.

That way, though we have have to rebuild frameworks and replace VBL any base map work will be there at least
Cweord

This message has been spell checked by Freudcheck - any mistakes are purley a figment of your imagination.
-------
My Tokens Directory
http://gallery.rptools.net/v/contrib/Cw ... er_Tokens/

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: MapTool 1.4

Post by Craig »

Scubba wrote:Any plans for how some of these larger paradigm shifts are going to take place?
  • The codebase may be in a "broken" state for a while
  • Some of these projects will be difficult to share between contributors due to complexity or domain-specific knowledge
  • At a certain point patches written against the 1.3 code could be nigh-impossible to merge
Fairly early on things will diverge from 1.3, most likely first steps are the build then moving to OSGi. The move to OSGi is where we will "break" it all ;) Yes some things will be very hard to share between multiple contibutors, but once OSGi is up and running and we have started decoupling everything then that is a real boon for anyone who wants to contribute, because they will be isolated from cha ges elsewhere. That is not to say there won't be plenty of stuff to do before that for those that want to get their hands dirty.
Scubba wrote: And if we are serious about junit tests (YAY!) can we set up a bugbase? Pretty please?
This is being done :)

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: MapTool 1.4

Post by Craig »

Cweord wrote:Will there be any easy way to transfer maps - sans vbl, just the standard layers over.

That way, though we have have to rebuild frameworks and replace VBL any base map work will be there at least
It possible we can cobble something together given the right amount of string, elastic bands, and duct tape. Although it's more likely to be a tool that turns the map into some thing that can be imported a map at a time into a new campaign in 1.4 instead of 1.4 but as a said before we get to the point where it looks like everyone will have moved over from 1.3 to 1.4 before we will finish then we are unlikely to write anything :) As it will certainly be towards the end of 1.4 development where we would write such a tool.

Azinctus
Giant
Posts: 133
Joined: Tue Nov 18, 2008 10:16 am

Re: MapTool 1.4

Post by Azinctus »

Cweord wrote:Will there be any easy way to transfer maps - sans vbl, just the standard layers over.

That way, though we have have to rebuild frameworks and replace VBL any base map work will be there at least
I'd second that. But if its not possible I won't grumble. I'm in awe of the super cool 1.4 plan and will support it through any discomfort it may cause.

I plan to support and use Map Tool for decades, so it needs to be set up for 1.4, 1.5 and on to 11.7 and beyond.

Post Reply

Return to “Developer Notes”