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
and the "support projects"
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.
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.
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
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"
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.
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.
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
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