RPTools Suite

Dalna · Post by **Dalna** » Thu Dec 07, 2006 6:15 pm

Well for menuing I would make the main framework have a main menu....each subprogram have its own menu that can be multiple layers if needed IE...
(F)ile, (E)dit, (M)apTools, (D)iceTools, (I)nitTools, (H)elp
Then you can use the File for normal uses and each tool can have its Own menu pulldown for its own use (things that are not common to each tool...Most editing and File commands can be used, if need be every tool can have its own save extention but this is all upto you..

Also I don't see why you wouldn't make any basic funtions as part of this main Framework and have all the tools use the same routines so that it is smaller and more compact and easier to keep them intergrated and usable.

Post by **trevor** » Thu Dec 07, 2006 6:23 pm

Dalna wrote: Also I don't see why you wouldn't make any basic funtions as part of this main Framework

Actually that's what the rplib project is for, it's the common code between the tools

I'm thinking more how the code is layed out, for example theres a class AppActions where actions are stored, AppStyle, AppState, that kind of thing. They have static information, and don't share nicely.

It's certainly a possibility to run them in the same program instance, and I've thought of doing just that. But that's going to take some fairly significant refactoring to let them do that. It's something we could look at when we approach a 2.0 release.

Azhrei · Post by **Azhrei** » Thu Dec 07, 2006 9:06 pm

I'm not sure who the quote is from (it might be Bruce Schneier), but it goes something like this:

I don't want interoperability -- I want substitutability.

I agree with that sentiment.

While I think the monolithic all-in-one approach certainly has advantages, I believe that being able to pull out pieces and replace them with something else is very powerful.

Of course, having external modules that talk to each other is more overhead, as trevor has pointed out. But it keeps the bugs contained in a single location and that means less unexpected side effects from code changes.

I'm not willing to make either structure a requirement, though! The design team should do whatever feels good and we'll see how it works out...

brisingre · Post by **brisingre** » Sat Dec 09, 2006 7:46 pm

I know nothing of Java, but I think one easy way to deal with the alt-tabbing issue would be to make the other tools dockable to panes in maptool. These panes would have the same sort of collapsable-lockable thing that the chat window has.

Kershek · Post by **Kershek** » Sun Dec 10, 2006 1:11 am

If you're going to link all the windows together into one alt-tab selection, I recommend using ctrl-tab to switch between them, the same way you would do to switch between open MS Word, Excel, and other Microsoft products.

snikle · Post by **snikle** » Sun Dec 10, 2006 2:29 am

At one time I was behind the all-inclusive app, however having spoken with Trevor and thought a bit more about it on my own, I think now I would rather have a suite (a la OpenOffice or MS Office) with seperate applications that can function together.
This would allow GMs to use the tools they needed to run their games, adding functionality as they saw fit. For example right now I am using MT to track my play by post game, my character sheets are posted on our forum and all rolls are conducted via the forum. So I have no use for a character tool or an init tool, so in this case I would not load them, and simply use MT for the game.
I also fear that character tool will focus too much on d20 products as they currently rule the market, thus those of us that use other systems will either be left with a product that will not function for our games, or something that would require us to switch our rule sets.

Kershek · Post by **Kershek** » Sun Dec 10, 2006 3:56 am

My preference is also that you have separate programs that you can alt-tab between them.

Emryys · Post by **Emryys** » Sun Dec 10, 2006 11:26 am

snikle wrote:I also fear that character tool will focus too much on d20 products as they currently rule the market, thus those of us that use other systems will either be left with a product that will not function for our games, or something that would require us to switch our rule sets.

Not if I can help it!

Since I got the ball rollin'.... CSTool only works for Traveller and Boothill...

snikle · Post by **snikle** » Sun Dec 10, 2006 1:08 pm

LOL Sweet!

Dalna · Post by **Dalna** » Sun Dec 10, 2006 7:39 pm

When I did my thing with menus I meant that it might look intergrated...but it would still be seperate...IE you choose which modules you want loaded...and the menus are edited when you install a new module.

ego093 · Post by **ego093** » Mon Dec 11, 2006 1:21 am

What's the interest amongst RPG tool developers to begin building in interoperability?

Post by **trevor** » Mon Dec 11, 2006 8:00 am

ego093 wrote:What's the interest amongst RPG tool developers to begin building in interoperability?

Very high

It's expected to start building the interoperability support framework during the next major development cycle.

ego093 · Post by **ego093** » Mon Dec 11, 2006 2:48 pm

Just to clarify, what's the interest outside of RPTools developers? It's cool that Daan from RedBlade is connected to what's going on here now since RedBlade is such a wonderful CG tool, but it's obvious that the interoperability discussion is just beginning.

brisingre · Post by **brisingre** » Mon Dec 11, 2006 4:33 pm

I hate tools like Redblade. I find them too limiting. I spend a good bit of my free time making up classes, and I find it really hard to get redblade to support homebrew stuff. It is also slower than just doing it by hand. I think something like Frozen's character sheet tool would be ideal, because this is so easy to customize (it is just images and a text file for where the boxes are) and easy to use for anything you want once you have got your system. If you guys a java version that was even easier to customize (you could customize the sheet with a seperate tool, which would let you import page images and then draw on boxes and set their default values, in relation to other boxes. (you could make the armor class add all of the things that go into it automatically, for instance) (perhaps you could also add radio buttons and checkboxes) and save as a sheet file) and another tool would load these files and let you edit the values and save them as character files, which you could publish to a server along with a campaign. This would be ideal. Sorry about the parentheses.

jay · Post by **jay** » Mon Dec 11, 2006 7:57 pm

The Character tool will probably start out just showing character info. Then we will add scripting support to handle updates to the sheet (for conditions etc.) and to handle user actions (attack, etc.) . If we do end up supporting character generation, it will also be handled by scripting and it will be done last. If character generation does come about, there shouldn't be any reason why you can't just ignore it and create the character sheets by hand if you want.