Future FoW: Possible Pitfall

[dorpond]

We have all thought about and requested that light automatically removes FoW.

I was at my game last night and I was talking to the other players about MapTool. We got on the subject about light and the players automatically assumed it already removed FoW. With that assumption in mind, the one player asked how the GM can prevent a player from moving (revealing the FoW) and then changing his mind and moving somewhere else instead (removing more FoW).

I quickly wrote it down so I wouldn't forget it.

So let us think about this a moment. I know my players will grab their character during their turn and try many different pathways to get to the enemy. How would we handle the auto-remove FoW feature when this is going on? Should we have a 'commit move' option or are we just stuck with the fact that the FoW will be revealed? How would 'revert to last move' work with FoW?

I throw this out to the other players to think about because we will have to come up with a system when Trevor starts to implement this in the future.

[giliath]

This is a difficulty with FOW that we discussed and one of the main reasons that automatic removal of FOW has not yet been implemented.

One suggestion was the dual layer FOW (1 automatic with light and one manual from the GM). This would allow the ambience that the automatic removal of the FOW but at the same time prevent players from using their character movement as a paintbrush to remove FOW without regards to their characters actual movement.

Another suggestion was movement commiting. Where the users move is not final until the GM says so and then the FOW is removed. The problem with this is that the FOW is not removed *as* they move and players might miss things that they would have otherwise seen.

Yet another suggestion was to combine the 2 above approaches and have a mechanism on the token for the GM to remove the "GM layer FOW" with a right-click action -> "Remove FOW per visibility".

Honestly I think that we are just going to have to implement something and try it because it is a very complex problem. The answer is likely going to have to be configurable to some degree because one persons answer might be competely unacceptable to another in this particular area.

[Steel Rat]

I don't think anything fancy needs to be done here. If your whole gaming group is doing this, then you need a new gaming group, lol. If it's only one or two members, then the GM needs to say, OK, you can't move your token any more, because you're taking advantage of the system. From that point on the GM moves for them, until they decide they can follow the rules.

It's the same thing with die rolling. Those people that insist on rolling out of everyone else's sight are most likely cheating, seen it many times. So, you tell them you need to see everyone's rolls, so everyone rolls up on a common area. Magically the person that always rolled to themselves doesn't hit as often, doesn't make a save as often...

[RPTroll]

I always liked the dual FoW layer idea. Either you set a default reveal on the player FoW or you allow light to show it. The main FoW stays like it is now.

I don't like the idea of movement commiting since it involves additional work for the DM and gets the players into the mode of "Can I please move here?".

With FoW the way it is now the players can move anywhere within the currently exposed area so I think that is restrictive enough. Once movement rates/controlled movement are in place, the other stuff sort of takes care of itself.

[Phergus]

My first response is that it is a GM problem but I'll try and be nice.

The FoW reveal could be configurable so that it only reveals when the move is committed. Until that point only the hexes they moved through would be revealed.

Is that "realistic"? No. Neither is allowing the players to move randomly around the map until they find the most optimum position for their character.

Controlled Movement will help mitigate against players moving around to remove FoW and reveal areas they aren't actually in.

FoW being restored when the light source leaves an area will also minimize the problem.

With the dual-layer FoW so that players can't reveal anything the GM doesn't want them to player movement reveals is the least of the problems.

A more serious problem is what happens when you have two rooms seperated by 20-30' of space. If the light sources don't stop when they hit the Blocking (GM) FoW then the second room could be illuminated from the first through solid rock. And worse it shows the players the possible locations of secret passages and doors.

Until the second room is actually entered by the players obviously the GM wouldn't have removed the GM FoW layer but once that is done the problem exists.

Depending on how light radii are being drawn it may be easy for MT to stop light once it hits the GM FoW layer. I hope so.

[Edit: removed -> restored]

[RPTroll]

A while back someone had the idea for FoW lines that could be drawn on top of walls. This adds to the time to create a dungeon but would solve some of the light reveal and movement problems.

The problem with this approach is that it adds yet another layer to FoW as you wouldn't want the normal FoW reveal to remove these lines.

[trevor]

A more serious problem is what happens when you have two rooms seperated by 20-30' of space. If the light sources don't stop when they hit the Blocking (GM) FoW then the second room could be illuminated from the first through solid rock. And worse it shows the players the possible locations of secret passages and doors.

Yup, that's the rub. We have discussed creating a third fow layer, or rather a light blocking layer that would prevent over-exposing. At some point I'd really like to do this.

We'll have to take it in steps though, first the dual layer fow, then adjust, then add more.

[Phergus]

I agree. One step at a time.

Even with the potential problems of revealing too much the dynamic FoW layer will be a big boost in the gameplay experience.

[acon360]

automatic-removal presents a whole slew of problems.

The problem of PCs using movement to reveal FOW they would not otherwise have seen is nothing but a discipline issue. Penalize them or eject them. Set a house rule that says where your token moves is where your character moves, period. B/c that is adding too much complexity for the end user for such a little thing that shouldn't occur to begin with.

But the issue of the walls is slightly more significant. Perhaps you could allow the GM to "draw walls" on a layer above the map. These "walls" wouldn't necessarily be visible, but the automatic-FOW-removal-algorithm would detect these "walls" and then substitute their coordinates for edges of the light source. Did I say that right?

Lastly, I just want to say that I think we all need to keep simplicity in mind with our suggestions. I've seen many times where ppl will contribute this idea and that idea, and the final solution is too complex for the average lazy user to get into and the software never takes off.

[trevor]

Set a house rule that says where your token moves is where your character moves, period.

And yet it is still even more complicated. Let's say there is a trap in between their origin and destination location. You would want to stop them half way through their committed path

But the issue of the walls is slightly more significant. Perhaps you could allow the GM to "draw walls" on a layer above the map. These "walls" wouldn't necessarily be visible, but the automatic-FOW-removal-algorithm would detect these "walls" and then substitute their coordinates for edges of the light source. Did I say that right?

Actually, this is the plan, good to know others think the same way !

Lastly, I just want to say that I think we all need to keep simplicity in mind with our suggestions. I've seen many times where ppl will contribute this idea and that idea, and the final solution is too complex for the average lazy user to get into and the software never takes off.

Agreed. Hopefully we've added interesting features without over complicationg the UI, if anyone feels anything has become clutter or overcomplicated, please let me know.

[acon360]

Let's say there is a trap in between their origin and destination location. You would want to stop them half way through their committed path

How about have the GM designate the trap square/s as a "wall" as previously mentioned and then use the same algorithm that prevents a PC from moving into dark/fow areas to prevent him from moving "through" a wall or trap designated square. And have this wall-layer serialized with the campaign save files.

And, in case I forgot to mention, I think this tool is f'ing awesome!

[trevor]

Let's say there is a trap in between their origin and destination location. You would want to stop them half way through their committed path

How about have the GM designate the trap square/s as a "wall" as previously mentioned and then use the same algorithm that prevents a PC from moving into dark/fow areas to prevent him from moving "through" a wall or trap designated square.

Which is a possibility, we've talked about the idea of having "triggers" that stop the movement, so the users can specify where they want to move, and if there is a trigger in the path, it stops them automatically, but doesn't give any hint that there's a trap there .... until they trip it.

And, in case I forgot to mention, I think this tool is f'ing awesome!

Rock on !

[RPTroll]

One thing to remember is that you don't always get the movement you want when using a mouse. There are times when hardware issues with mice that cause an inadvertant move. When you have a touchpad the problem becomes worse.

All that said, I'm not saying do things one way or another just that whatever approach is taken needs to be a bit fault tolerant. This is one of the reasons I like to dual FoW method. Plays see what they've seen without accidentally going somewhere they shouldn't.

[trevor]

One thing to remember is that you don't always get the movement you want when using a mouse. There are times when hardware issues with mice that cause an inadvertant move. When you have a touchpad the problem becomes worse.

I'd love to hear ideas on improving this. One thought I had: currently I hide the mouse pointer when moving a token, but this has the side effect that if the mouse pointer is right near an edge, releasing the mouse button might sufficiently move the mouse to pick the wrong cell. Showing the pointer might give a more natural "drop in the center" feel. I'm sure better keyboard (cursor keys) would also help.

[Phergus]

I'm not sure what it has to do with anything but I noticed that if I click in the middle of a large+ token and then drag it, when I release the mouse the pointer is typically on the left edge or top-left corner.

Indeed if you take a Gargantuan sized token, click in the bottom-right corner to start your drag the token actually gets positioned as if you had grabbed the top-left corner.