targetting and LOS

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[Marble Dice]

@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.

No, you're quite correct, in my model he cannot actually see much of the room's walls at all. I have very conflicted feelings about this point, I'll get into that in a sec. Here's how it would look as I proposed it:

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

Now, while those wall tiles are not actually visible, they're still walls so if you've seen them in the past, the game would still display them to you. However, if an umber hulk bursts into the room at one of those non-visible wall locations, you would not be able to see it (nor would it be able to see you).

The heart of this issue is that I believe LOS should be symmetric. Consider a door into a room. Stand at that door. You can't see the entire room, just a cone of it. Under a symmetric LOS algorithm, being able to see all room walls from any interior room tile would imply you could see every interior room tile while standing on any door to that room. To phrase it backwards, if, under a symmetrical LOS system, standing in a door yields a cone-shaped field of view, then if you were standing in any of those initially non-visible tiles, you would be unable to see that door to the room.

If this is an unacceptable flaw to you, then this system is still salvageable: you just have to give visibility to any wall which possesses an edge to which you can draw an unobstructed line from the player's center point. This would require more than a single center-to-center check, but might not require more than a couple of lines. However, this opens up another problem:

There may be many wall tiles you can see, but if there was an open tile at that location (and by extension a monster at that location), you would not be able to see the floor or the monster. What happens when there's a pass-wall monster at one of these "bonus visible wall" locations? The monster can't see through any walls except the one he's standing on, so for him it's like he's standing on a door, and he can't see you. Therefore under a symmetrical system, you shouldn't be able to see him. But then you'd have a visible wall with a non-visible pass-wall monster inside it. If that's okay, then great no problem. If you think you should be able to see all pass-wall monsters inside of visible walls, then you have to scrap the symmetry or its back to the drawing board.

Did all that make sense? I'm sure I could make some pictures if it would help illustrate the problems.

Intuitively, I agree with you, I think you should be able to see all of a rectangular room's walls while standing inside that room. However, I do think LOS should be symmetric, and I think standing on a door should yield a cone-shaped FOV. I don't think just because you're inside a room, cowering in a corner, that you should be able to see every monster lurking on the doors to the room that are on the walls you're standing next to (your vision would be too narrow to see around the corner). Having limited room wall visibility simulates this, and since the game does remember where walls are, not being able to see every wall tile from every interior position would not look strange.

Personally I prioritize symmetry, expanding/cone-shaped visibility/shadows, and directional consistency over being able to see behind every door to a room, from any position inside of that room.

Sorry for the long post, I hope that makes sense to you, even if you probably don't agree with it.

[PowerDiver]

No, you're quite correct, in my model he cannot actually see much of the room's walls at all.

The heart of this issue is that I believe LOS should be symmetric. Consider a door into a room. Stand at that door.

I put a door in my diagram. My example was about the char not in the doorway but in the interior of the room. If you don't think a char several feet into the interior should be able to see all the walls of a rectangular room, we've passed the point where we are close enough to have a meaningful discussion.

My original proposal deals with everything cleanly, and doesn't introduce problems if you cast stone-to-mud at a passwall monster in a wall as some proposals would. The single problem is that an isolated # does not produce a cone, but rather a line along which LOS is blocked. The pillar is already assumed not to entirely fill the square [else treasure rooms are impassable], so it doesn't bother me that the char could "lean" to the left and right in his square to see enough to reduce a cone to a line. Not perfect, but not terrible.

As to room entrances, I think you are locked up in your experience with the current broken system. Consider a room entrance

#########
##      #
##      #
ABC     #
##      #
##      #
#########

You are familiar with the notation that B is partial cover, and C is in the interior, in the current paradigm. My proposal is to change the notation so that the center of B is the threshhold, the point at which you can see the full interior but not the surface of the left wall -- i.e. your eye is at the center of B and is flush with the edge of the wall, and A is the closest square with partial cover. Suddenly all of the computations are clean. Nothing really changes from a gameplay perspective except that you have to adjust to the new notation. You still have a square of partial cover followed by stepping to a square visible to the entire room. When viewable == targetable, the immediate feedback should keep even a player well accustomed to the old ways informed of how things work.

The real question in my model is whether the left wall should be visible too from B. You could "lean" forward in the square and see it according to my model, and if passwall monsters extrude from a perfectly straight wall you ought to be able to see them without leaning, but leaving the wall and monsters in it not visible seems to make other things work out better. This really is a boundary case in terms of the math, so one should feel free to choose whichever solution feels better, and the alternative that a single # pillar blocks no LOS at all would certainly annoy a lot of people.

[PowerDiver]

The more I think about it, the more I wonder if the "digital field of view" is the right solution. The place where it wins is with two diagonal pillars.

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

In my suggestion, you can look between the pillars easily. In the DFOV, the two together block you from looking past the pillar along the row below the @.

[Marble Dice]

If walls took up the full tile, but had beveled edges around corners as d_m describes in #98, then I think digital field of view would be suitable. Without beveled edges, shadows cast on the diagonal are grossly inconsistent with the hori/vert.

[PowerDiver]

If walls took up the full tile, but had beveled edges around corners as d_m describes in #98, then I think digital field of view would be suitable. Without beveled edges, shadows cast on the diagonal are grossly inconsistent with the hori/vert.

Are you sure you understand it? OTOH, am I sure I understand it? Here is my understanding.

Adjacent #s are adjacent diamonds, no more and no less. If they are horizontally adjacent, the points touch and so they provide a continuous obstruction. I don't see how beveling can come into this.

Diagonals are consistent with horizontal in that a single pillar viewed from a single square casts a straight line shadow equivalent to the one where you do center to center and only the center obstructs. That is not the definition per se, but it follows from the geometry At least I think it does.

I just clicked on your link, and that's not the original. The original reference was by Atanvarno to http://roguebasin.roguelikedevelopme..._field_of_view

[Marble Dice]

Look at the page with information on the implementation:

DFOV Implementation at RogueBasin

You can see an image which illustrates concepts behind line of sight in DFOV. The walls are arbitrary polygons, not diamonds. Treating the walls as full-tile with beveled edges is basically a simplification of the arbitrary polygons present in that article; you could also treat each wall as a diamond if you wanted to, and that would have a similar and acceptable effect.

Running the example program, it appears to function suitably, so I assume the demo implementation does not treat walls as full-tile squares, which is all I was getting at.

DFOV would change the meaning of a single #. Currently it's a massive 10'x10' obstruction, but in DFOV, it is a flimsy column. Pillar shadows are narrow and continuous from 0, 45, and 90 degrees, but all other angles are narrows, sparse and broken. Additionally there is very little partial cover around corners:

###.#
###C#
.AB.#
#####

Point A and all of the west hallway can see around up to and including point C, point B can see the entire northward hallway. Rooms behave similarly (standing on the door is full room visibility, standing one square behind is the typical cone-shaped partial cover).

It's different but it seems pretty good.

[Atarlost]

One problem with the lack of cover, though, is that cover is important to evasion of monsters with ranged attacks and evasion is a huge part of gameplay. That's the real reason for conical shadows.