Ok I have not had a chance to play test maptools yet work has decided that i must travel all over the US this past couple of weeks and it is cutting into many aspects of my life from my son and down to my gaming time. But my friend is just starting up his game and will be using maptools and has had time to test it a little here is one of things that we both think would be cool to have.
For each token to have a sight radius set for it like 60 feet which can then remove the fog of war around that token in the given radius.
The sight radius and automatic fog of war removal has turned out to be a fairly difficult problem. If we remove the fog of war as you are moving, then a player that is simply planning their move would potentially expose things he could not otherwise see. If we wait until the player has committed their move with the final release triggering the fog of war, they could see something they would have potentially seen earlier in their move that makes them change their direction and then we would have exposed too much of the map.
Any suggestions you have for how this would work would be appreciated, but in the mean time, we do plan on allowing tokens to have vision ranges and this should help the GM decide how much of the fog of war to manually expose.
I have been thinking about the points your have brought up and I can not think of a good way to handle it. I also thought of another issues that may or may not be there as i have still not had a chance to play test it yet. Is if a pc moves does the GM see the path that he took. The reason i ask is if there is a trap set at a certain spot on the floor then the GM needs to know how did the PC get to his spot again this may be done already
How will the GM now the tokesn vision range will it be an visible showing like a transparent circle around the token?
The path a token takes is shown as the move takes place. There is a tracker to make the path stay on the screen for a minimum period of time (like 2 seconds or something). We have also talked about having the token's last path show whenever it is selected. That way you can always click on a token and find the exact path it took to get there.
In some future point we plan on allowing the GM to place triggers on the map that will automatically trigger when a token moves into that cell. There isn't a time frame for that yet.
We imagine that visibility will be something like a circle drawn around the token representing the visibility distance.
Its been many, many years since I've done any programming, so please forgive me if my ideas are impractical. When a GM loads a map up, they would need a tool which allows them to draw lines/objects on the map that block site radius (so you can do dungeons, enclosed buildings, etc) ideally they should also block movement on the players map, so that they dont accidentally walk through a wall. Counters would need to have a movement value (normally their walk speed), a player can only move while the value is less than or equal to double the value (later on you might want to support the option to do a run, which is 4x(or 5x) in a straight line, with no crossing rough terrain or moving through other counters), once they have had their move, thats it, they cant move their character again until the GM okays it (it would be useful if the GM were also able to allow the player to take back their move just in case the player slips or otherwise makes a horrible mistake, but it must only be at the GMs discretion), if a player chooses to rush ahead with out considering the consequences, on their head be it.
For version 1.0 we're focusing on simply making a "shared state" game board, similar to if everyone was sitting around the table. That means most of the responsibility of movement restrictions and visibility are on the players/GM.
For future versions (2.0 perhaps) we will look at introducing optional functionality such as you are describing. In fact, the path that your token shows is calculated using a simple path finding algorithm. The intention is that at some point the GM will be able to create an obsticle mask and the tokens will automatically route the shortest path around the obsticle.
Fair enough. Still having the ability to draw lines which block the revealing of the map would be a splendid feature.
As a side note, you can hold down the SHIFT key to snap to grid. It might make exposing single cells a little more accurate