RPG Tabletop
I hereby declare "RPG Tabletop" to be stable. This means that while it may not have all the bells and whistles I -want- in a tabletop program, or even everything we're used to in OpenRPG, it should do so without breaking.
What it is:
RPG Tabletop specifically keeps track of people's location on a map for the purpose of D&D-style combat. It uses a client-server protocol, and mandates for now that the GM must be the server (you'll need port 4242 open if you're the GM, but can play behind a closed firewall if you're just a player).
The map keeps track of the line segments on the edges of each tile, so you leftclick and drag near a tile line to turn those lines "on", and rightclick and drag to turn them "off". This means that all of us GM's who can't draw straight lines for crap will wind up with perfectly neat dungeon walls anyway.
Miniatures are currently all the same picture with different names over them, although the protocol supports image URLs, and I'm also looking into a slow file transfer system for GMs without webspace (while I have webspace, the convenience factor would be immense).
CURRENTLY, with the limited network vocabulary I've given the program, race conditions might put the multicast at risk of resetting character locations should multiple people be moving minis at once; however I've crash-tested in many ways to make sure that NO LINES OR MINIS WILL DELETE as a result of these race conditions. Later planned additions to the protocol will mean two people can move different minis without interfering with each other's work. The additional network vocabulary might even be folded in by next Wednesday.
What it is not:
We're used to the ability to freeform scribble in ORPG, due to the way in which dungeons are described, that's not yet possible in RPGT. Text labels? Nope. And I've locked out player line drawing as well; only the GM does that for now. I'm trying to code exactly what we need to play a reasonably fun and network-trouble-free D&D game and not one iota more. (more development just means we use ORPG more, and I'm just getting a little fed up with its bugs).
There is no online dicerolling yet, although this is one of those things I plan on building in soon. Math.random() function is an old friend of mine; it shouldn't sell the players short like python is now. The syntax will most likely be:
/dice 2d6+6 yay damage!
## [2d6+6] -> (2+3+6) -> 11 yay damage!
or for say a to-hit roll
/dice d20+8 versus AC
## [1d20+8] -> (12+8) -> 20 versus AC
The omission of the first number will cause the roller to assume 1 die.
After dice is implemented, it's not too bad to go to a regular expression evaluator of the following format:
/math (2d6+12) / 2
## [(2d6+12) / 2] -> (3)(4) -> 9
always rounding down, of course. In the end dice and math could be synonyms except for the flavortext part in the dice command (which I firmly believe should be there for organization purposes).
Also scheduled for change by test time is a swap from the depressing purple color to a delightful green (not the ugly dark green though). The finished (as in, a couple weeks from now) program will have a Map Properties page which will allow the GM to set the mapcolor, gridcolor, cell size, overall map size (in number of cells wide and high), and anything else that comes to mind. For now that mapsize is locked down to 100x100, which should be plenty for what we have in mind... but that generous size does have a downside, which is network response time while drawing.
Right now you can't delete minis either... which will show up in the mini context menu by the time I get this thing shipped out to you for next Wednesday.
Blah. Anyhow, it is what it is. I look forward to crash testing next week.
Edit: mini MOVE network command was just field tested. Two people can now move their own minis without interfering with the other person's.
What it is:
RPG Tabletop specifically keeps track of people's location on a map for the purpose of D&D-style combat. It uses a client-server protocol, and mandates for now that the GM must be the server (you'll need port 4242 open if you're the GM, but can play behind a closed firewall if you're just a player).
The map keeps track of the line segments on the edges of each tile, so you leftclick and drag near a tile line to turn those lines "on", and rightclick and drag to turn them "off". This means that all of us GM's who can't draw straight lines for crap will wind up with perfectly neat dungeon walls anyway.
Miniatures are currently all the same picture with different names over them, although the protocol supports image URLs, and I'm also looking into a slow file transfer system for GMs without webspace (while I have webspace, the convenience factor would be immense).
CURRENTLY, with the limited network vocabulary I've given the program, race conditions might put the multicast at risk of resetting character locations should multiple people be moving minis at once; however I've crash-tested in many ways to make sure that NO LINES OR MINIS WILL DELETE as a result of these race conditions. Later planned additions to the protocol will mean two people can move different minis without interfering with each other's work. The additional network vocabulary might even be folded in by next Wednesday.
What it is not:
We're used to the ability to freeform scribble in ORPG, due to the way in which dungeons are described, that's not yet possible in RPGT. Text labels? Nope. And I've locked out player line drawing as well; only the GM does that for now. I'm trying to code exactly what we need to play a reasonably fun and network-trouble-free D&D game and not one iota more. (more development just means we use ORPG more, and I'm just getting a little fed up with its bugs).
There is no online dicerolling yet, although this is one of those things I plan on building in soon. Math.random() function is an old friend of mine; it shouldn't sell the players short like python is now. The syntax will most likely be:
/dice 2d6+6 yay damage!
## [2d6+6] -> (2+3+6) -> 11 yay damage!
or for say a to-hit roll
/dice d20+8 versus AC
## [1d20+8] -> (12+8) -> 20 versus AC
The omission of the first number will cause the roller to assume 1 die.
After dice is implemented, it's not too bad to go to a regular expression evaluator of the following format:
/math (2d6+12) / 2
## [(2d6+12) / 2] -> (3)(4) -> 9
always rounding down, of course. In the end dice and math could be synonyms except for the flavortext part in the dice command (which I firmly believe should be there for organization purposes).
Also scheduled for change by test time is a swap from the depressing purple color to a delightful green (not the ugly dark green though). The finished (as in, a couple weeks from now) program will have a Map Properties page which will allow the GM to set the mapcolor, gridcolor, cell size, overall map size (in number of cells wide and high), and anything else that comes to mind. For now that mapsize is locked down to 100x100, which should be plenty for what we have in mind... but that generous size does have a downside, which is network response time while drawing.
Right now you can't delete minis either... which will show up in the mini context menu by the time I get this thing shipped out to you for next Wednesday.
Blah. Anyhow, it is what it is. I look forward to crash testing next week.
Edit: mini MOVE network command was just field tested. Two people can now move their own minis without interfering with the other person's.