MapTool: Refined

[Lee]

On the question of selling points, I'm not sure if someone stated it but paraphrasing what I said on first post, feature matching or providing alternate features that exist in competing products can lead to the by-line of maptool having relatively everything that the others have and a lot more that they don't. Also, apart from the initial development costs, the end product is in the RPTools spirit of something that will always be free and open. As others have said it, nothing beats the price of free and the benefits of freedom.

[Azhrei]

Wow, good stuff, Lee. Thanks for taking the time to respond. I know how Real Life can get.

I hadn't really thought about an Amazon cloud-hosted service for MT. I'd love to have such a thing be free, but I don't think anyone using it would mind contributing a few pennies to fund their own use of that service. So if it cost RPTools $1.00 to run the MT server for 6 hours, then the charge to the person using it would be $1. I don't know what the S3 cloud costs look like, but I expect they would be rather minimal for MT actually (much of the cpu MT consumes is for rendering the GUI; everything else is network stuff and acting as a clearing house for passing data to clients). Maybe one user needs to provide a Paypal or similar account and can specify a cost limit (don't exceed $XX). Then when the limit is reached, the service is disconnected (probably with lots of warnings beforehand!) and the campaign file saved somewhere in the cloud. Otherwise, if the limit is not reached then the account is simply charged when the MT session ends.

Implementing an alternate HTMLFactory and instantiating JavaFX objects is a great way to begin the "testing" of using JFX in MT. It would do a few things right away: provide better HTML and CSS compatibility with current standards, allow some functionality not currently available (animation, non-rectangular windows), and spruce up the visuals quite a bit (addition of gradients for instance). There might be some work required to make the new shoes fit perfectly (I'm thinking of property events being generated and received) but overall it's a good first step.

Another piece that could be moved to JFX would be the chat window. It's relatively self-contained so it shouldn't be too much work.

All good ideas.

[Full Bleed]

Since I've painted a target on Roll20, I was thinking of starting on the same modest(?) amount they did for their work (was it $2k or $3k?). This will be used over a period of 3-5 months to attain the primary goals stated. Yes, I definitely earn a lot more in my day job, but again, this allows me the free time I need to do what I plan to do.

As previously mentioned, Roll20 had an initial goal of 5k. It ended at 40k.

I think a 2-3k target for MT 1.4 would be a fairly modest and reasonable goal. My previous concerns were more about what would happen if 10-20k were raised. I'm more eloquent in my advocacy for a "Combined Funding" approach earlier in the thread. I believe it fosters the best chance to over-perform and establishes an expectation for how funds could be used for future development and offers a path to pressing for additional short-term phases while we're waiting. In a nutshell, I would be more inclined to contribute to both a short term and long term plan over putting my eggs into just one basket. If we're not leveraging that duality, I think we're only appealing to a part of the whole.

[Ephestion]

Sourceforge is good place for getting people into the Development of code. Also having a serious plan works too. Adding and fixing stuff at your feet doesn't get get you to the far horizon very quickly.

MapTools is a niche product but if it shows signs of progress more people will join. It needs to attract people otherwise it just slows down. I have seen it with several retro programs I was with.

As far as I am concerned, we don't need anymore features. What we need is sorting out the mess that the program represents. I went to the looking for a game in the game listing thread, he started talking about modifying some XML before joining because he had some custom rules that didn't use frameworks. He lost me there and I came here instead

Seriously, my recommends would be
1. Sourceforge listing
2. Dropping into some large Java project sites and name dropping this project
3. Start building up a player base and community

Without players and a community the program won't go anywhere. You will be suprised how many people will mod and make custom things for popular games. Once they are no longer popular they move onto something else. Popularity and signs of Life give much more productivity to a project.

4. Sort all the Tools into a better GUI system. See my posts in the MapTool Requests section. This will get your player base and keep your developers.
5. Ease of Use for the Player is of highest priority. They don't want to level up characters manually upto level 100 or so, edit files and jump through hoops to join a game.
6. Start with Pixel Art forums and as time allows 3D artists to develop Tiles or Images to draw maps.

There are many more things this program needs. I am somewhat surprised at the number of nonsensical things people have voted/paid for in the wall of Requests. Having a handful of guys pay for stuff and making the game die in the end is not the same as planning ahead and developing a game that will surprise even them. User input and game designing should never be reduced to paying for features. It is more important to develop something with a long term perspective that will appeal to many people in the general public and casual users, not just the niche obsessed.

[Full Bleed]

As far as I am concerned, we don't need anymore features.

Then, frankly, Maptool: Refined/1.4 isn't for you.

[Xaelvaen]

Its a fine line with which you flirt, truthfully. The weight of features versus freedom is truly what MT's design hinges upon. While there are many things that would be wonderful to have innate into the system (movement counting without ridiculous lines of code, in example), I wouldn't remotely trade the lack of a UI and the freedom of MT for it. The reason I use MT is because it has no UI. Its the very reason I don't use other sites/programs. When I want 'GUI', I make an html character sheet and players can perform any actions literally from clicking on that.

Your true issue is how much of that freedom do these features destroy? If that line is crossed, you draw in one crowd but shun another. If its not pushed far enough, it retains its 'unfriendly exterior' that scares off people with very little programming skill. (Hell, I was one of these people a couple of years ago. It took me a bit of time and effort to get the hang of it. However, I wouldn't have traded any of that for a nice 'point and click' version.)

So, bring on the new features - just remember what MT means to a lot of people; we make our own 'rules'.

[Lindharin]

Lee, you may already be familiar with the financial side of Kickstarter, but if not you might want to look at the first half of this page: http://www.blackgate.com/2013/06/13/art ... e-all-get/.

I've got no first-hand information about this, never having run a Kickstarter campaign, but according to that blog post, in addition to the fairly well-publicized 10% overhead for Kickstarter itself, you'll also be taxed 30% of the gross. I'm not sure if the 30% figure is because the blogger happens to be in that tax bracket and the Kickstarter gross just counts as "income" for the year, or if it falls into some investment category. Anyway, it is something you might want to research before setting your goal.

[Lee]

Thanks guys for the new input so far. I'm too sapped right now to put together finer points, so I'll leave that for tomorrow or the day after. See you all then

[Lee]

Wow, good stuff, Lee. Thanks for taking the time to respond. I know how Real Life can get.

I hadn't really thought about an Amazon cloud-hosted service for MT. I'd love to have such a thing be free, but I don't think anyone using it would mind contributing a few pennies to fund their own use of that service. So if it cost RPTools $1.00 to run the MT server for 6 hours, then the charge to the person using it would be $1. I don't know what the S3 cloud costs look like, but I expect they would be rather minimal for MT actually (much of the cpu MT consumes is for rendering the GUI; everything else is network stuff and acting as a clearing house for passing data to clients). Maybe one user needs to provide a Paypal or similar account and can specify a cost limit (don't exceed $XX). Then when the limit is reached, the service is disconnected (probably with lots of warnings beforehand!) and the campaign file saved somewhere in the cloud. Otherwise, if the limit is not reached then the account is simply charged when the MT session ends.

Implementing an alternate HTMLFactory and instantiating JavaFX objects is a great way to begin the "testing" of using JFX in MT. It would do a few things right away: provide better HTML and CSS compatibility with current standards, allow some functionality not currently available (animation, non-rectangular windows), and spruce up the visuals quite a bit (addition of gradients for instance). There might be some work required to make the new shoes fit perfectly (I'm thinking of property events being generated and received) but overall it's a good first step.

Another piece that could be moved to JFX would be the chat window. It's relatively self-contained so it shouldn't be too much work.

All good ideas.

Thank you, Azhrei.

I'll look into the Amazon offering as well as Google's (I'm an unabashed Google fan), and see what can be done. As for the JavaFX provisions, I plan to provide something simple and let users drive the customization of things such as the property events you mentioned. Lastly, I have gone over the chat window code quite extensively for another piece of work, so I'll earmark that as well.

I'm more eloquent in my advocacy for a "Combined Funding" approach earlier in the thread. I believe it fosters the best chance to over-perform and establishes an expectation for how funds could be used for future development and offers a path to pressing for additional short-term phases while we're waiting. In a nutshell, I would be more inclined to contribute to both a short term and long term plan over putting my eggs into just one basket. If we're not leveraging that duality, I think we're only appealing to a part of the whole.

I've read that post and think it makes a really good point. The "problem" I see with it is, currently, the work I've done so far and am planning to do for 1.4 is (atm) divorced from RPTools; all for very good reasons, some of which have been mentioned by others on this thread. If the funding drive were to be inclusive of the 2.0 road map, then it would corral RPTools into a development culture alien to what drives it today, and make it liable to the expectations set for the crowd-funded project. Apart from stating that all bug fixes will be contributed back to the official source, and all new features will then exist as the new official 1.4 line, I don't know how it can be worded to reflect that this is a fork but at the same time, will include development for 2.0, without making RPTools accountable and/or changing its volunteerism-based culture. In a nutshell, yes, I do want to appeal to the broadest base, but I also want to protect RPTools from any "fallout".[/quote]

Sourceforge is good place for getting people into the Development of code. Also having a serious plan works too. Adding and fixing stuff at your feet doesn't get get you to the far horizon very quickly.

MapTool's code has already been hosted there for the longest time. Developers and contributors who come to the MT community eventually find themselves accessing this repository and working from there. A lot of contributions have been made over the years, and the only reason it tapered down was because of the needed feature freeze to focus on developing the next-generation MapTool.

MapTools is a niche product but if it shows signs of progress more people will join. It needs to attract people otherwise it just slows down. I have seen it with several retro programs I was with.

If, by niche, you mean the VTT consuming public, then I agree that MT is a niche product. If you mean that MT only satisfies a niche within the VTT community, then I disagree. As far as I can tell, usage statistics were never big here, but I'm absolutely sure that there's a quiet multitude that regularly uses this product. With that being said, MT is mainstream, and not niche. The only dynamic slowing it down is the entry of competing products such as Roll20, which provide an easier entry point (at the sacrifice of power and flexibility). I personally plan to counteract this. I say personally because this current initiative uses a somewhat alien approach as opposed to what the great community spirit RPTools has fostered over the years.

As far as I am concerned, we don't need anymore features. What we need is sorting out the mess that the program represents. I went to the looking for a game in the game listing thread, he started talking about modifying some XML before joining because he had some custom rules that didn't use frameworks. He lost me there and I came here instead

One can never have too many features But, as what JFJ mentioned earlier, with a plethora of features, there needs to be a method of managing them (e.g. plugin architecture); barring that, MT devs have already mentioned a number of times in the past of customizing "perspectives" that load in context to who is using them, like a GM view that displays all tools, or a player view that only exposes the map and macros developed for their use. With these being said, you've been ninja'd when it comes to the mess sorting.

2. Dropping into some large Java project sites and name dropping this project

To what end? 1.3 development is reaching the end of its life cycle and 2.0 has just come out of its conceptualization phase. So, aspiring contributors will either have to fork 1.3 (as I did), or will have to wait for 2.0 to come out of the gates. On both cases, the core/head developers still need to lay the code foundation that act as rules to keep development sane. Till then, driving awareness will be premature.

3. Start building up a player base and community

The player base and community already exists as the VTT community as a whole, and that's not counting the ones exclusively for MapTool. I counter that it is not building we need, but consolidation and organization. Once that's achieved, expansion is the next point of order (i.e. non VTT users).

Without players and a community the program won't go anywhere. You will be suprised how many people will mod and make custom things for popular games. Once they are no longer popular they move onto something else. Popularity and signs of Life give much more productivity to a project.

Ah, but I've already seen it in the framework coders, art work creators, and module designers that have given their input to the MapTool community over the years. Yes, things can be made a lot easier, but the question is: for whom? Again, like what Bone White mentioned on an earlier post, a primary goal of this initiative is to make things easier for creators, after which, their creations will do the rest of the driving.

4. Sort all the Tools into a better GUI system. See my posts in the MapTool Requests section. This will get your player base and keep your developers.

Thanks. I have already read that post and will take good ideas I gleaned from it into consideration. I have made some points on that thread myself, if you care to go over them. I have to mention that there are plenty of ways to skin a cat, and no single method being the best on every given situation. Phase 1 of this project will not likely support your paradigm of how things should be, but it does try to be more intuitive and provide a more seamless experience when using the tool.

5. Ease of Use for the Player is of highest priority. They don't want to level up characters manually upto level 100 or so, edit files and jump through hoops to join a game.

Some things need not be mentioned, as I did mention ease of use repeatedly on this thread Like I commented on your feature request thread, your way requires a massive amount of work on the underlying engine to accomplish; work with only a handful of developers can undertake. I find that you were dismissive of the RPTools approach, but you should evaluate it anew: MT was designed to be a generic tool useful for most if not all gaming applications. It's an open-sourced project so anyone can come in and customize it how they like if they know how. If such a person were allowed to commit his changes to the main source, then there would be ripple effects. For example, if someone prior committed a change that was specifically for D&D, would his work be skewed by the new addition to the code? Would changes to the code affect the ultimate MT goal of being a generic tool? To avoid these problems, the architecture abstracts needing to change the source and instead, provides building tools within the tool itself (i.e. maptool script, token system etc.)

It is more important to develop something with a long term perspective that will appeal to many people in the general public and casual users, not just the niche obsessed.

Ah, but that's essentially why 2.0 has taken so long to start, it's long-term perspective. I'm not sure who you're referring to with "niche obsessed" but that appellation will find no one here that matches.

Its a fine line with which you flirt, truthfully. The weight of features versus freedom is truly what MT's design hinges upon. While there are many things that would be wonderful to have innate into the system (movement counting without ridiculous lines of code, in example), I wouldn't remotely trade the lack of a UI and the freedom of MT for it. The reason I use MT is because it has no UI. Its the very reason I don't use other sites/programs. When I want 'GUI', I make an html character sheet and players can perform any actions literally from clicking on that.

I agree that there should be no trade-off, only enhancements to what makes the tool great. For instances of features such as the movement counting you've described, I'd figure it in as an event return that a scripter can not only optionally use but redefine as well.

Your true issue is how much of that freedom do these features destroy? If that line is crossed, you draw in one crowd but shun another. If its not pushed far enough, it retains its 'unfriendly exterior' that scares off people with very little programming skill. (Hell, I was one of these people a couple of years ago. It took me a bit of time and effort to get the hang of it. However, I wouldn't have traded any of that for a nice 'point and click' version.)

I foresee no problem on this part. This only arises when someone enforces a design view that excludes what others thinks as best e.g. "I think you're wrong with using X, it should be Y and I'll be writing it as so".

So, bring on the new features - just remember what MT means to a lot of people; we make our own 'rules'.

But of course Agreed.

Lee, you may already be familiar with the financial side of Kickstarter, but if not you might want to look at the first half of this page: http://www.blackgate.com/2013/06/13/art ... e-all-get/.

I've got no first-hand information about this, never having run a Kickstarter campaign, but according to that blog post, in addition to the fairly well-publicized 10% overhead for Kickstarter itself, you'll also be taxed 30% of the gross. I'm not sure if the 30% figure is because the blogger happens to be in that tax bracket and the Kickstarter gross just counts as "income" for the year, or if it falls into some investment category. Anyway, it is something you might want to research before setting your goal.

Thanks, Lindharin. I have come across this earlier on. I didn't bring it up as I wanted to gauge community response and make clear what my needs would be. Once the answers are tangible, then I think the need to expound on how to get to the that bottom line can then be addressed i.e. gross sans deductions = net.

[Lee]

Apologies to everyone regarding the vids. I'm still recovering from a nasty throat infection I got from doing some fresh water swimming with the gang and I'm in no condition to do voice-overs. I'll probably just run the vids and type in what I want to say; a "type-over" if there ever was such a thing

[yorick]

I for one am very interested in an iterative approach. Ease-of-use is high on my wish list, as is simplifying the Vision / FoW choices when starting a server. I never could figure individual FoW out, because it left players with a dark screen when they clicked off their toon. Maybe that interacted badly with something else. No idea.

Making those kind of things easier to use, and avoiding situations where a player sees a blank screen, would be great. Some of that will have to require working with people like Wolph, to see what he'd need in his BoT.

If you start on this and have a place where we can kick in some money, do let me know. I'd rather do that than pay $10/month to roll20, for less functionality.

[Lee]

@yorick I've quietly been doing this in the background. Several individuals in the community have supplied their input, whereas others have politely declined. Putting things together has been a thoughtful process where I had to balance my job with wanting to push this out as soon as possible. As I've mentioned before, it will get done, and I'm confident that people will be pleased at the road map.