targetting and LOS

[d_m]

As I understand Marble Dice's suggestion, he is treating the space between contiguous walls as flat, and then using diamonds to approximate the corners of wall sections. Thus:

diamond  two non-attached diamonds
....      ....
.#..      .#..
....      ..#.
....      ....

hexagon      octagon
....         ....
.#..         .##.
.#..         .##.
....         ....

I can understand interpreting the suggestion as "all walls are diamond shaped" but I don't think that's what is actually meant.

[PowerDiver]

@MarbleDice

In this situation, where the player is in the corner of a room, how much of the adjacent walls can he see?

+########
#@
#
#
#
#
#
#


I think the heart of our difference is that I think he should be able to see the entire outline of the room up to 20 square visibility or whatever, but I am interpreting [possibly misinterpreting] your model to say that he cannot.

[PowerDiver]

It's worth remembering that your original suggestion treats walls differently based on their immediate adjacency with other walls.

Here we get to the heart of it. The difference between notation and what is being modeled. I said that the notation of two adjacent #s meant a particular type of wall at a particular location. My modeling was about the walls, not the notation.

E.g.

####
#..#
#..#
####

is our notation for a room in which 4 monsters can stand and 12 passwall monsters can loom on the periphery. However, there are multiple ways to interpret what that means in terms of wall placement and monster extrusion.

So I didn't have any special-case rules about visibility "if this square is next to a wall". I had a particular reinterpretation of what the notation meant, and then clean rules acting upon the model.

My belief is that the last suggestion starts with a clean model, in which everything is approximated by diamonds, and then the rules make special cases that are not fully consistent with the model, but I was confused before and I may still be confused.

Nevertheless, I've got to say my proposal isn't close to perfect. I just like the proposed alternatives less.

[d_m]

I'm not saying diamond obstructions are hackish. They are pretty elegant given the problems of a square grid. I'm saying treating some squares as being defined by diamonds, and others as defined by their centers is hackish. Any rule with "unless it is next to a wall" is hackish.

It's worth remembering that your original suggestion treats walls differently based on their immediate adjacency with other walls.

[Marble Dice]

I'm not saying diamond obstructions are hackish. They are pretty elegant given the problems of a square grid. I'm saying treating some squares as being defined by diamonds, and others as defined by their centers is hackish.

Surely this isn't saving my case against the label "hackish", but visibility is always point-based. Units, open tiles, and walls are points when being checked for visibility, but walls are diamonds when checking for obstruction. It's strange because walls are point-like under observation, but diamond-like at other times. Maybe I should have called this method "quantum visibility" instead of "diamond obstructions."

The upshot is there are some tiles the system will not permit you to see because you wouldn't be able to see a unit there, even though you technically should have LOS on a wall if it was there. But, if you see a wall, I think you should also be able to see the unit inside that wall, but you don't have LOS on the center (the unit point), just the wall (the diamond border).

Any rule with "unless it is next to a wall" is hackish.

It is hackish, but the "unless it's next to a wall" bit is there, of course, because you need to permit border intersection to allow the hockey stick around corners, but you shouldn't be able to see through orthogonally adjacent walls:

.    #.#    .
  .  #.#  .
    .#.#.
     #@#
    .#.#.
  .  #.#  .
.    #.#    .

I still think it sounds promising. Maybe I'll try implementing it, too.

[PowerDiver]

If so you must be thinking of a situation that did not occur to me, because I had PASS_WALL monsters in mind when I typed those rules out. I am assuming here that any monster in a visible tile can be seen by the player - so if the wall tile which hosts a pass waller is visible, then the monster itself is also visible.

I was probably combining different worries in some twisted way and just confused myself.

[PowerDiver]

I see we disagree here, so that's understandable, but I don't feel like diamond obstructions is any more hackish than is necessary

I'm not saying diamond obstructions are hackish. They are pretty elegant given the problems of a square grid. I'm saying treating some squares as being defined by diamonds, and others as defined by their centers is hackish. Any rule with "unless it is next to a wall" is hackish.

[Marble Dice]

I don't particularly like the "4 eyes" thing. I meant it as an example of how clunky you have to get to force expanding cones. I considered it necessary over center-to-center so that one wall square does not obstruct another on a long straight wall.

Ah okay, it seemed a little clunky to me too, so mission successful.

If you are willing to use obstructing diamonds, why not just accept the "field of view" that even comes with an implementation?

The only problem I could find with digital field of view are its shadows around pillars - they don't expand on the hori/vert but they expand quite noticeably on the diagonal. I prefer expanding shadows; more than that, I prefer roughly consistent (i.e. similar) pillar shadows from all directions. This is also my basic complaint with your original and modified proposals.

I don't think single pillars can be reasonably removed from Angband's dungeon model, and for consistency's sake, I feel they should have similar shadows from all directions. A square tile map makes this complicated and difficult. I think they should produce expanding shadows, because intuitively I think these two situations should have complimentary fields of view:

......     #.....
......     #.....
@#....     @.....
......     #.....
......     #.....

You start with a clean elegant method, and then apply some hackish mods. I don't see any obvious problem, but I expect there are some lurking. One difficulty is that I think expanding shadow cones for single # columns is a mistake...

I see we disagree here, so that's understandable, but I don't feel like diamond obstructions is any more hackish than is necessary when working with a square tile system that allows diagonal adjacency and pseudo-360 degree targeting. You are right there could be some lurking critical flaw with diamond obstructions, but I cannot find any.

I also think you should *start* with defining and modeling the properties of passwall monsters. They are fundamental to the game, and if you don't start with them your solution is unlikely to deal with them properly at the end.

I don't understand what you're getting at here - do you feel my description above leaves them out? If so you must be thinking of a situation that did not occur to me, because I had PASS_WALL monsters in mind when I typed those rules out. I am assuming here that any monster in a visible tile can be seen by the player - so if the wall tile which hosts a pass waller is visible, then the monster itself is also visible.

[Atarlost]

Does monster LoS ever matter for anything except the player?

If not you can easily get symmetry for any setup by only looking at player LoS and using the bugblatter beast of traal method for determining monster LoS.

[PowerDiver]

PowerDiver: Your "4 eyes" solution does produce expanding shadows on the diagonal only, albeit very long, thin ones. Does this 4 eyes method provide any benefits above a system where walls function as you describe, yet LOS is simply checked from center-to-center (the original 4x4 sub-grid method)?

Let me propose another method for review (obstructing diamonds):

• Visibility between two tiles is determined by a single unobstructed line between the center of the first tile to the center of the second.
• Wall tiles contain an obstructing diamond, with the 4 points of the diamond centered along the 4 edges of the wall tile.
• Obstruction from the observer's tile and the observed tile are disregarded.
• Visibility is permitted on the border of the obstructing diamond, EXCEPT at one of a diamond's four points WHEN there is an adjacent wall tile.

I don't particularly like the "4 eyes" thing. I meant it as an example of how clunky you have to get to force expanding cones. I considered it necessary over center-to-center so that one wall square does not obstruct another on a long straight wall.

If you are willing to use obstructing diamonds, why not just accept the "field of view" that even comes with an implementation? I would bet that the author of that method has thought about obstructing diamonds longer than you or I ever will.

You start with a clean elegant method, and then apply some hackish mods. I don't see any obvious problem, but I expect there are some lurking. One difficulty is that I think expanding shadow cones for single # columns is a mistake, so I'm not sure that I can evaluate your idea properly given my viewpoint. Am I biased here, or is an expanding cone the logical flaw that should end the argument? I don't know.

I view what you are doing as trying to impose finer granularity, but only part way. The more normal wargaming viewpoint is that at the minimum granularity, the unit is expected to be spread over the entire square. That means it should have the full visibility of all points in the square it covers, and be able to attack in all directions. When you change this, there will be unintended consequences. The "field of view changes this to being spread over the inscribed diamond, but then is completely consistent with that refinement. In my original proposal I changed this, but I was very very careful about it and mainly changed it for a # directly between the viewing endpoints.

I also think you should *start* with defining and modeling the properties of passwall monsters. They are fundamental to the game, and if you don't start with them your solution is unlikely to deal with them properly at the end.

[Marble Dice]

Resolving projectile blocking in most visibility systems could probably spawn its own discussion as large as this one about targeting and LOS. I see a few good alternatives:

A) No projectile absorption

If you can see it, then you can hit it with an arrow. Nailing the yeek standing behind an ancient multi-hued dragon in a straight, narrow corridor doesn't make a lot of sense, but then again neither does being able to see that yeek in the first place. The latter certainly makes for better gameplay IMO, maybe the former would also be tolerable. It would make groups of ranger monsters more dangerous.

B) Monsters only absorb at their center

This would allow rows of monsters in horizontal and vertical corridors to absorb projectiles, but you'd be able to shoot through them diagonally in most cases. There would only be sparse absorption (dotted and discontinuous) along non-45 degree lines, which would be difficult for the player to mentally calculate in order to make informed decisions.

C) Monsters also absorb in a diamond pattern, also absorbing at the diamond's border intersection.

This approach's main drawback would probably be implementation complexity, but it might work out pretty well. Haven't thought a lot about it just yet.

D) Implement a path-finding algorithm for projectiles

This would allow projectiles to walk towards the target, avoiding walls and possibly other absorbing monsters when possible, but would also be more complex to implement and be more difficult for the player to use in informed actions.

[d_m]

Let me propose another method for review (obstructing diamonds):

1. Visibility between two tiles is determined by a single unobstructed line between the center of the first tile to the center of the second.
2. Wall tiles contain an obstructing diamond, with the 4 points of the diamond centered along the 4 edges of the wall tile.
3. Obstruction from the observer's tile and the observed tile are disregarded.
4. Visibility is permitted on the border of the obstructing diamond, EXCEPT at one of a diamond's four points WHEN there is an adjacent wall tile.

I believe such a method would...
...have guaranteed symmetry, and be suitable for LOS=projectability with no trick shots.
...be immune to the artifact described above. I can't think of any others that would affect it.
...display ghosts in corridor walls up to two spaces away.
...reveal the knight's move around corners (visible hockey stick).
...exhibit similarly sized expanding shadows behind pillars in all directions.

I am pretty tired though so I'm sure I'm overlooking something.

I think your results seem good. The only strange result you get (which all of these systems have to some degree) is that the projection path will either hit squares that weren't considered blocking, or that the projection path will "tunnel" between two squares:

1      2      3
#@..   #@..   #@..
##o.   ##..   #.o.
.#h.   ##h.   ##h.

In case (1), the wall and the orc don't block @'s LOS to the dark elf. Should a projectile hit the wall? If not, should a projectile hit the orc? If no to both, you get an "electron tunneling" effect where the arrow goes between # and o.

If the arrow hits the # then you end up with a lot of squares that are visible but not projectable, and case (2) seems kind of bad.

If the arrow hits the "o", then things are mostly fine (and this is probably how I would implement it) although there is some tension in how to handle (3). Some people might want the shot to avoid the orc, although I am fine with having both of those intervening squares "absorb" arrows, if they are not clear (or if one is a wall).

I added a conservative LOS mode to my program; I will try to code up this diamond mode also.

[Marble Dice]

PowerDiver: Your "4 eyes" solution does produce expanding shadows on the diagonal only, albeit very long, thin ones. Does this 4 eyes method provide any benefits above a system where walls function as you describe, yet LOS is simply checked from center-to-center (the original 4x4 sub-grid method)?

The only complaint I've heard so far with a 4x4 sub-grid is some visual artifacting of this nature:

####????????????
...#?????????...
...#?????......?
...#?...????????
@.#?????????????
###?????????????

Let me propose another method for review (obstructing diamonds):

1. Visibility between two tiles is determined by a single unobstructed line between the center of the first tile to the center of the second.
2. Wall tiles contain an obstructing diamond, with the 4 points of the diamond centered along the 4 edges of the wall tile.
3. Obstruction from the observer's tile and the observed tile are disregarded.
4. Visibility is permitted on the border of the obstructing diamond, EXCEPT at one of a diamond's four points WHEN there is an adjacent wall tile.

I believe such a method would...
...have guaranteed symmetry, and be suitable for LOS=projectability with no trick shots.
...be immune to the artifact described above. I can't think of any others that would affect it.
...display ghosts in corridor walls up to two spaces away.
...reveal the knight's move around corners (visible hockey stick).
...exhibit similarly sized expanding shadows behind pillars in all directions.

I am pretty tired though so I'm sure I'm overlooking something.

[d_m]

I guess I made the mistake of immediately implementing your suggestion, which seems to work well. So I may be a little too eager to frame the conversation around that because there is a testable implementation out there.

I guess the answer is to try to implement the 4x4 subgrid solution next

[PowerDiver]

My understanding of your original suggestion was that the visibility of a square isn't affected by whether the square itself is a wall or not. Is this no longer the case? If so, what are the different criteria for visibility? If not (which I had assumed) then old #1 and new #1 are identical (I think).

I am not the overlord, and do not have the power to impose the final solution. Hopefully all of my proposals are consistent with the principles I espouse, but when talking about general principles it is important to see how they interact with all of the ideas under consideration, including ones I don't like as much as others.