Can of Worms - LOS / Targeting / Trick shots

[RogerN]

So I've now reached the point in my variant development where I must decide how to deal with targeting. Should I try to avoid trick shots? See the attached diagram if you don't know what I'm talking about.

Point A is cannot be targeted directly by the player because there is no direct line of sight to the center of the tile. However, by targeting point B, the player could potentially hit a target at point A because the path passes through the corner of the grid.

Personally, I'm torn on the issue. On the one hand I think players should never be forced (or allowed) to "trick" the game into hitting a monster that isn't actually visible. But on the other hand, I'm afraid that attempting to block all of these trick shots could yield some very unintuitive (and therefore confusing) game behavior.

ZAngband's approach is to basically have the UI do all the "trick shots" for you. Thus you can use the targeting interface to fire projectiles at creatures around corners, etc... This would be a decent solution if not for the fact that the player can get two free shots at monsters coming around corners.

The unintuitive option I suppose would be to forbid projectiles from hitting a monster if there is not a direct LOS to the center of the tile. In other words, a projectile could pass through point A in the diagram but it would not be allowed to hit a monster standing there. I think this approach solves the "trick shot" problem nicely, but creates its own problem in terms of unintuitive game behavior.

And, of course, there's the Vanilla approach which allows for trick shots but forces the player to manually target a tile beyond his intended target.

Thoughts?

[buzzkill]

In reality, if a person wanted to shoot down that 'empty' corridor, he would be able to, so the game character should certainly be able to. If he is able to, then IMO the game should automatically target a known creature (possible through ESP, or detection) standing at 'point a'.

The characters inability to target 'point a' is a failing of the targeting mechanism itself. If he can hit 'point a' by aiming at 'point b' then he can hit 'point a' and should be able to do so automatically. Unless you are willing to restrict the player from auto-targeting 'point b' then you shouldn't restrict 'point a' either. But if I were him, I'd deal with those pesky dogs first.

Aside, it would be nice if a wand or rod of light targeted the (slanting) corridor itself, if it's path is already known through exploration or mapping (since there is no actual target to target). You would just point down the corridor and the light would follow the slant as best it could. Maybe an option, since in some rare cases it may be undesirable.

[fizzix]

Well, how much do you want to work on this?

Personally, I dislike Angband's asymmetric LOS approach, and would want something a bit more symmetric. There are some good suggestions in the thread here:

http://angband.oook.cz/forum/showthread.php?t=2018

My personally favorite approach is one where you draw a line between the player and the monster and then calculate whether you are intersected by a wall. If you don't like exactly how this treats LOS you can fudge it by not having walls extend all the way out. This part seems fairly straightforward to code.

The hard part is dealing with the fired beam or arrow. When you fire a weapon or a beam targeted at a specific square the game calculates the straight line. Then it places the beam in the nearest square. However, if the straight line intersects a wall at any point, the beam is terminated.

So in your case, you would not be able to target that square, or hit it with a trick shot, since the beam will get clipped by the corner.

[RogerN]

The hard part is dealing with the fired beam or arrow. When you fire a weapon or a beam targeted at a specific square the game calculates the straight line. Then it places the beam in the nearest square. However, if the straight line intersects a wall at any point, the beam is terminated.

So in your case, you would not be able to target that square, or hit it with a trick shot, since the beam will get clipped by the corner.

So by that method, the player would not be able to target point B either? Although there is a straight line to point B, the line passes through point A and there is not a straight line to point A. Therefore the projection would end in the tile directly above point A.

[zaimoni]

....

ZAngband's approach is to basically have the UI do all the "trick shots" for you. Thus you can use the targeting interface to fire projectiles at creatures around corners, etc... This would be a decent solution if not for the fact that the player can get two free shots at monsters coming around corners.

As is Zaiband's, although Zaiband did a complete rewrite that defines line-of-sight in terms of targeting with a Wand of Light. Note that Zaiband allows monsters to V trick-shot @ (and has no method of turning this off).

The worst targeting problems go away if you abolish hockey pucks by simplifying the targeting algorithm. In V, non-pure diagonal shots always start off in a cardinal direction, which is completely unnecessary to enable the knight-move shot. Force non-pure diagonal shots to start the base projection algorithm from @ rather than one off from @: hockey puck dies, still have some minor weirdness.

[will_asher]

The unintuitive option I suppose would be to forbid projectiles from hitting a monster if there is not a direct LOS to the center of the tile. In other words, a projectile could pass through point A in the diagram but it would not be allowed to hit a monster standing there. I think this approach solves the "trick shot" problem nicely, but creates its own problem in terms of unintuitive game behavior.

This is the right solution, IMO. A monster doesn't take up the whole space it's in. Any monster in point A who has half a brain is going to be up against that corner where it has no chance of being hit by the PC, but the projectile can still go through the space that it's in. What's unintuitive about that?

[fizzix]

So by that method, the player would not be able to target point B either? Although there is a straight line to point B, the line passes through point A and there is not a straight line to point A. Therefore the projection would end in the tile directly above point A.

Ah I see the problem I think. So the approach would have to be that the beam disappears for the untargetable squares, and reappears for the targetable ones.