RFC: Wargamers, what do you need from MapTool?

[Azhrei]

So basically, you need a way to a) give the player a choice to participate or not (possibly in "secret") then b) some way to indicate what order the players are going in for that stage and finally c) a way to track what stage(s) each player has participated in for that given turn.

Wow, that's involved!

I'm not sure how useful it would be to implement some type of "generic stage" turn-based system. I think while the concept might exist in more than one game, the actual implementation is going to be so different as to make any features that MapTool provides insufficient. So I'm thinking that the macro system will be needed for something like this.

So in summary, there are a couple of things you need to consider here:
- the blips are basically a card deck with a value on each. This value needs to be hidden to all but the controlling player until such time as it's revealed.
- there is a fixed pool of models available as well that the blips draw from.
- the two pools need to be able to be drawn from and returned to.
- the value of the blips needs to be fixed prior to game play, so that neither player can alter then during play.
- the value of the blips needs to be available only to one player, until such time as it is revealed to the other players.

This sounds like the "card deck" idea that's been floated before would work here. Not sure if the card deck will be able to handle the "two pools" with a single set of cards between them, though.

Thanks for your insight!

[UntoldGlory]

There's a lot to dig through here, but I'll add my 2 bits.

Agreeing with the team definition idea. But there's a bit more to it. My friends and I are trying to use Maptools to play Star Fleet battles (as I've mentioned in a different post), but we need the ability to make units invisible to other players (or teams) while still being able to see what's going on around the cloaked vessel.

So basically, 3 checkboxes: Owner visible, team visible and all visible.

[Hawke]

UntoldGlory - I'm running into an issue with visible tokens, too. A game I've built and currently MTing has a spy unit that is used to move around and look in territories. Right now there isn't an easy way to do this... but there definitely should be!

[kristof65]

So basically, you need a way to a) give the player a choice to participate or not (possibly in "secret") then b) some way to indicate what order the players are going in for that stage and finally c) a way to track what stage(s) each player has participated in for that given turn.

Wow, that's involved!

I'm not sure how useful it would be to implement some type of "generic stage" turn-based system. I think while the concept might exist in more than one game, the actual implementation is going to be so different as to make any features that MapTool provides insufficient. So I'm thinking that the macro system will be needed for something like this.

As is typical with many games, it's more complicated to explain than it is to actually play. It's ok if you rely on Macro programming to do it, however, make sure that any needed (if any) macro commands to support something like this are added.

So in summary, there are a couple of things you need to consider here:
- the blips are basically a card deck with a value on each. This value needs to be hidden to all but the controlling player until such time as it's revealed.
- there is a fixed pool of models available as well that the blips draw from.
- the two pools need to be able to be drawn from and returned to.
- the value of the blips needs to be fixed prior to game play, so that neither player can alter then during play.
- the value of the blips needs to be available only to one player, until such time as it is revealed to the other players.

This sounds like the "card deck" idea that's been floated before would work here. Not sure if the card deck will be able to handle the "two pools" with a single set of cards between them, though.

It's not a single set of cards with two pools. Technically, it would be two different 'decks' each with their own pool, it's just that they are interelated. As long as MT can handle multiple card decks, the interrelation can probably be done with Macro programming. However, you bring up a valid point - some games have a hand, a draw pile and a discard pile. In many games, you can go through the discard pile and/or reshuffle it back into the draw pile.

Multiple "card deck" support is definitely needed. In addition to Space Hulk being able to use it for the Blips and Genestealer models, lots of other games use multiple decks.

Also needed is for a deck of cards feature to be usable not only as cards, but as draw piles for tokens/tiles.

Thanks for your insight!

Not a problem - just wish I could get my friends Jay and Joe to contribute to this thread - I have about 1/10th the experience with board and mini games those guys do.

[KaylaKaze]

A lot of these are good ideas, but most of them seem to be about automation, not table top replacement. Sure, targeting is fine, but what's wrong with typing "attacking x, y, and z". Oh! That's right, you want it to be able to auto-resolve combat given your attack macros. That's not table top replacement, that's automation. Table top replacement should be first and foremost of goals. The only 2 I see of REAL importance are both quite easy to integrate (I know because I did it fairly easily in an old version of the source code). These are A) announcing when a player is measuring with the ruler, and B) announcing when a player moves a unit (possibly announcing when a player has lifted/dropped a unit so they can't cheat and use it as a measuring tape). This would suck to have on full time, so they should be in the campaign options.

[Hawke]

I agree that there are two types of things that we can discuss...

1) Built-in "as is" functionality - things like permissions, cards, visibility issues, visual UI change, etc.

2) Scriptable functionality - things that you can create with scripting to provide things like game specific automation.

I think there's some overlap and gray area, but I think there are definitely some system-agnostic UI stuff and features that would be extremely helpful to everyone outside the need to develop complex scripting. Attacks and applying damage etc. fall more under the scriptable functionality.

[Haman]

Thanks for this thread! Lots of promising things in the works and its really exciting to look forward to possibly seeing some of them.

For me, I use Map Tools primarily to resolve combat in a modified version of Mekton, within our role-playing campaign. Combat is fairly tactical, and is usually mecha-based, though sometimes we're in personal combat situations. Map Tools can cover most of what we need to do already, its just that my macro programming skills are currently behind the curve. Working on and off at an attempt of a framework and I'm improving my skills thanks to the forum members here, but its a long ways off, so forgive any oversights I may have.

There are a couple things mentioned already I thought I'd highlight and comment on, as well as another that maybe could warrant a look. I dont mention movement limitations here because I see Rumble working on it already and assume its something that has promise on a someday inclusion to Map Tools, but yes, that's something I'd love to see as well (thanks Rumble!).

Elevation

Ideally, you could assign elevation to terrain areas. Either per box/hex or assigning height to drawn areas for free movement games. The latter would naturally be more difficult. Then any token on an elevation area would automatically be at that elevation.

Elevation has been a struggle to represent in Map Tools to the point where I tend to try and not use it. My current best solution has been to place an elevation marker on each hex on the Object layer. Its just a transparent gif named as a number. One can then switch to the Object layer and rollover the line between two tokens and see the numbers popup to determine both elevation difference and line of sight.

If I recall, we both had to be GMs to do that, but I may be mistaken. That was one downside, but the main ones were the incredible amount of time it took to set that up, as well as how tedious it is in actual use. Really only did that once as a result.

Its exactly what Jector was getting at though. I'd love to see that implemented. To extend it, it would be great if line of site could somehow be included, although I'm really not sure that's possible or how it would be done. Its easy in a situation like where there is a 2-level positive difference or more in between two targets - they cant see each other because there is effectively a hill in between them - but there are much more complicated scenarios and I havent any idea if there is a way for sighting to be calculated. Being able to assign elevation to cells would be a great step, and useful in and of itself just to know who is on what elevation. A way to see the elevation of a given hex on rollover (as opposed to actual LOS calculation) would be a helpful addition.

Phases

- the ability to set and control turns. This was previously mentioned. Don't forget turn phase tracking - IE, Supremecy has several phases, but each player can only participate in three of those phases.

In play, I also need something where I can track phases as well as customize order.

Basically, we play by turns and initiatives are only rolled at the start of each turn. Thing is, the winner can decide if they wish to take initiative and go first, or, take the tactical advantage and instead go last. I've had to fudge this. I'm not sure if the initiative panel can be edited to do it, but its not yet something I have honed my meager skills on. I cant use Initiative Tool because at the moment I am on Mac OSX 10.4.11 and cant update Java quite that far. My problem of course if Initiative Tool can already do it.

Once we're in a turn, the turns are then broken into phases. Tokens have a specific number of actions they can take, and each phase they can use one. I have an action counter that tracks actions used on the character sheet and can be reset. There are some ways a token can use two actions in a phase. Basically, phases run in the initiative order between each token until they run out of actions. A lone token on the board might then have two more actions left while everyone else is out. It would just take those two actions and then there would be no more phases and a new turn would start with a new initiative roll.

Possibly Map Tools can already do all this, but for now, I track it on paper.

Firing Arcs
There is this thread as regards firing arcs.

Basically, each token has firing arcs as well as defensive values depending on which arc an incoming shot is coming in from. It would be nice to not have to use arrays and offsets to try and solve that.

Initially, setting aside shots coming into a token, I was simply trying to have each weapon's arc and range pull valid targets out of that pie-shaped piece. Craig solved it rather nicely here, although for whatever reason it intermittently fails for me, so I havent tested yet if I can then assign only a certain range to it somehow.

Ideally, looking for a good way to have a weapon, set its firing arc, say "Forward", and then its range, and valid targets would be pulled only from that. To be able to be used for any system, I suppose one would need to be able to define what "Forward" is in that system - 120 degrees front, 180 degrees front, etc. Offset arrays can do that, but they are cumbersome. Maybe its the only way.

For incoming shots from a given target, it would be nice to be able to know what arc it comes in on, since there are different defensive values involved, a parry can only happen on the shield-equipped side, etc.

[KaylaKaze]

I just thought of something else: more control over piece size. Set it up the same way you can do lighting and vision range in the Campaign Properties and make sure it can do decimals. If I set up my board as 100 pixels is 1 cell, I want to be able to make my units 1.18 cells square (30 mm), 1.57 cells square (40 mm), and 1.97 cells square (50 mm).Currently, to do this I have to set a unit to free size and make sure the graphic is the right size.

Also, this should be an easy one: Make sure when selecting a unit, it judges based on whether or not that pixel is transparent. As it is, if you're using odd shaped units, to make them rotate right, you need to make the graphic square, but for non -square units, that leaves a alot of open space around the actual art that ends up being recognized as part of the unit, so if that space is overlapping another one, even though it doesn't appear that it is, I can't select the unit under that space.

[Azhrei]

[...] more control over piece size. [...] Currently, to do this I have to set a unit to free size and make sure the graphic is the right size.

Actually, after setting an image to freesize you can drag the little box in the bottom right corner of the image to resize it however you want. Be sure to read the text in the statusbar at the bottom of the window for hints on how to use it.

Make sure when selecting a unit, it judges based on whether or not that pixel is transparent.

I'm not sure how practical this is. The current technique requires the user to double-click on a stack of images in order to select one of them. In truth, a single click should probably bring up that same panel. Trying to select one image underneath another by basing the selection on transparent pixels would be excruciatingly difficult using certain devices or displays (I'm thinking touchpads and/or tablets or with very low-resolution displays).

As it is, if you're using odd shaped units, to make them rotate right, you need to make the graphic square [...]

Yes, this is a known issue. Correcting it is rather complicated if we try to automate it, so the most recent proposal is to let the user assign the center to the image somehow. There's a separate thread somewhere for this issue...

[KaylaKaze]

Actually, after setting an image to freesize you can drag the little box in the bottom right corner of the image to resize it however you want. Be sure to read the text in the statusbar at the bottom of the window for hints on how to use it.

Well, for non-tokens, yeah. I'm talking about actual tokens. In WM, for example (what I work on) You need 3 different unit sizes (as mentioned). I suppose it's not really a big deal making sure your image is the right number of pixels and just setting it to "Native Size/Free Size" though. And after giving it more thought, I think this is probably the best solution for such a situation. (But I should point out the statusbar doesn't give any specific hints on image resizing).

Yes, this is a known issue. Correcting it is rather complicated if we try to automate it, so the most recent proposal is to let the user assign the center to the image somehow. There's a separate thread somewhere for this issue...

I understand the issue and don't have a problem with the units being square, which goes to the point of the transparency. If I have a square model, but, for gameplay reasons, it has to be on a round base, I have two choices: either put the unit fully contained in the base (as I do now) or have the graphic sit on top of the base (as I'd like to do if I can get permission to use the Vassal WM mod graphic files). The thing is, the actual WM models have parts that over hang the edges of the base, and any decent graphical representation does too. Making such a unit square, with the circle base in the middle is fine, except that token then has a lot of transparent space around it that's still considered part of the token.



Here, you have the Lancer (with the spear) fighting a Deathjack and 2 Mechaniks (the blue ones without graphics) repairing the Lancer. You can't really tell by looking, but that Lancer token almost completely covers the Mechaniks. Sure there's the little "stack" box in the corner but it's quite far from the units and barely noticeable. I'd actually never noticed it until you mentioned it. So if I go to move one of the Mechaniks, chances are good I'm going to end up grabbing the Lancer by mistake since logically I wouldn't even assume the Lancer IS covering the Mechaniks just by looking, but that the stack box was because the Lancer's covering some of the Deathjack. Even if I did, I'm trying now to select a Mechanik using the token select frame thingy (dbl-click, single doesn't work), and it doesn't work right (instead of picking up the selected token and pinning it to the cursor like normal, it picks it up about 350 pixels away from the mouse cursor). The Crew Chief Mechanik doesn't even get a select box popup because he's only about 3//4 covered and not fully. If I double click him, I get the selection box with the Lancer and Bodger in it.

I suppose it's not really important, just a minor annoyance. I just wanted to explain exactly what I meant since I thought maybe I wasn't clear the first time.

[Mrugnak]

Determining what arc an attack is coming from is actually quite important for GURPS, too. Older versions of D&D (AD&D) with backstabbing also need to know which way the target token is facing as well.

[aku]

how about this as a multi pronged solution. There is a visual indicator, on the map, with a duration set by a client side option for duration, to indicate how long it stays on screen (options including off, # of seconds, and click or keybind button press to remove), as well as a printed chat line hyper linking the involved parties?

It answers, as far as i can tell, all of the concerns about how long to indicate something has happened some where else, the option,but not the need, to click on the notifications, and a long term storage of the info, in the chat log.

[Azhrei]

Well, for non-tokens, yeah. I'm talking about actual tokens.

Oops, you're right. You would need to drop the first token on the map on the Object layer, Freesize it, resize the way you want, then change it to the Token layer. You can now copy/paste that token whenever you want a unit of the same image at the same size. Save the token to an external file and you should be able to drag-n-drop the token back to the map later. This process let's you do all your image sizing inside MapTool, which may (or may not) be easier than using a graphics program.

In WM, for example (what I work on) You need 3 different unit sizes (as mentioned). I suppose it's not really a big deal making sure your image is the right number of pixels and just setting it to "Native Size/Free Size" though. And after giving it more thought, I think this is probably the best solution for such a situation. (But I should point out the statusbar doesn't give any specific hints on image resizing).

Using a graphics tool to resize the image is another option, but if you have the same image that needs to be X number of different sizes, you need to do that all inside the graphics program. Not a problem, of course, but some may find it easier to do in MapTool.

There is a visual indicator, on the map, with [...]

Interesting idea. It made me think of the old games where "something" that was off-screen was represented by an icon along the edge of the visible area showing which direction you had to travel to reach that "something". The WarHawk game for the PS3 comes to mind, as the map includes heads-up display that shows which direction are allies and enemies.

For our use, it could be a very slim, colored marker of some arbitrary design/shape. Ideally, client preferences could indicate how to render the marker: size, color, image to use, how often to update, etc.

(Edit: Oops, I answered a different question! In rereading the OP, it's the firing arc that you're referring to and not a directional beacon.)

[aku]

no, i actually was thinking of a directional beacon, i thought someone else had mentioned something like it earlier in the thread, but were concerned about the length of time it would pop up, either being too short to be useful, or having to be manually cleared

[SeanDAnderson]

I also don't have a lot of practice with Maptool. I've only used it for one game and that was well over 2 years ago. However I have to agree that a lot of these issues are automation issues and not table top emulation issues. The features that I think are most needed for tabletop games (war or otherwise) are:

1: Linked movement. Whether it's being able to group into a larger token or something more subtle the ability to move things like troop formations or, I think, more importantly vehicles with token units is a major issue. In certain games you have to be physically capable of placing your units on the vehicle in order for them to move with it and, if they are exposed, they can be shot. This would mean that you need to be able to place units is a certain arrangement, with exposed units layered above the vehicle and concealed units layered beneath, and turn that into one big unit that will rotate facing and whatnot together (otherwise those units on the back of the transport are all of a sudden on the ground next to it instead of inside).
You can sort of work around the group movement by selecting a bunch of tokens and moving them at the same time but you can't turn them together or anything making it very time consuming to move units this way.

The only current workarounds to vehicle one are taking the units off the 'table' when they board the vehicle or stacking them all up and moving them as a stack instead of in position. Neither of these keep the targetable units in the right place though

2- “flippable’ units: really, I have no idea how you would do this one logistically. So many games use cards or tokens to mark ‘unknowns’ and only certain players get to look at them at certain times. This works around a table because everyone is watching and if you look at something you shouldn’t they can beat you with a stick. On MT however if the information is in place where you can look at it then you can look at it (duh) and no one will notice. So you either have to restrict the information to one person (which doesn’t really fix anything) or it’s open to everyone which means cheating will be rampant.

The best solution I can think of would be to include some sort of information type for tokens marked ‘secret’ or some such that announces to everyone when that information is viewed and who viewed it. I.e. Sam looked at Treasue Token 12. Or Same looked at Door Card 23. This could be irritating if the game uses very many of them though. I.e. the chat box is clogged with ‘Sam looked at’ for all 10 cards Sam looked at, plus the 5 times he had to look at #2.

Really I think the contents of that info could probably be randomly filled out with a macro. It wouldn’t be pretty, but it should be doable.