targetting and LOS

[Pete Mack]

[QUOTE=PowerDiver;20869]

So you don't think you should be able to see the outline of a large lit room when you enter it adjacent to a wall?

This is a key question. If the M horizontally next to a # has an expanding cone of shadow, it cannot see the @. By symmetry, the @ cannot see all of the walls of the room. There is no way around this without changing one of those properties.

Eddie, this doesn't make sense. Walls will always fill an arctangent-1 of LOS, because their surface is a straight line. The issue is whether the monster is (almost) flush with the surface. If he fills some fraction of the square, there will be some distance beyond which you will be mutually out of LOS.

[PowerDiver]

[QUOTE=PaulBlay;20794]

The suggested changes would make the following situation *not* LOS.

######################M
@

Frankly I think targetable / LOS at that distance is just greedy. ;-)

So you don't think you should be able to see the outline of a large lit room when you enter it adjacent to a wall?

This is a key question. If the M horizontally next to a # has an expanding cone of shadow, it cannot see the @. By symmetry, the @ cannot see all of the walls of the room. There is no way around this without changing one of those properties.

[Atanvarno]

To sum up, "wouldn't it be nice if"

* What you see is what you can hit with a spell (and vice versa).
* What you see can also see you (and vice versa).
* Standing directly next to a pillar should produce an expanding shadow.
* Reasonably fast code can be produced to implement the FOV, etc.
* No 'trick shots' required (or possible) to hit monsters that you can't target directly.

Is everyone agreed on the above (if they are possible)?

How does the current system specifically differ from the above?

Are any of those points not possible?

I will refer to these five points as (1)-(5). I will not say anything about (4).

I think it is important to decide what should happen, when A shoots an arrow at B and there might be monsters or walls in between. I see at least to different options:

(a) There are one or two natural paths from A to B (given by Bresenham's algorithm). If one of these is free, then the arrow hits B. If both are blocked, then one is selected and the arrow hits the first obstacle on this path.

In this system (5) is impossible. If we require (1), then we get a FOV satisfying (2) and (3), but it is very restricted and does not look very good. If we only want (2) and (3), then there are probably many possibilities.

We could get (5) by a hack: if the arrow (or spell) would hit something that could not be hit directly, then it will not hit, but it will drop on the floor (or the spell will do nothing). This would cause beam spells to have "holes".

(b) Calculate FOV for A treating monsters as walls. If B is visible, then the arrow hits B. Otherwise it hits something in between A and B.

FOV and "something in between" can be defined so that (1) and (5) are satisfied. If we also require (2), then we can't get (3). This leads to a very permissive FOV, and again there are small issues with beam spells.

[d_m]

But it's easy enough to manufacture an example of discontinuous sight in the 2x2 system as well:

Well, you're right about there being a discontinuity, although it's a different one than you marked--a contiguous group of 3 squares:

+----------+
|######xxxx|
|#....#xxxx|
|#....#xxxx|
|#....#...#|
|#@.#xxxxxx|
|####xxxxxx|
+----------+

I'm still not ready to give up 2x2; I don't find this discontinuity troubling (and imagine that the 4x4 system will also have similar cases). I guess we'll see what happens.

[etaomyx]

To be clear: this is not the suggestion to make each tile into a 4x4 grid and use the middle. Rather, it splits each tile into a 2x2 grid, and each of those grids is only filled if there is another contiguous wall.

Ah I see, my example referred to a 4x4 grid system, sorry for not be more specific. I had thought the 2x2 system had been abandoned already; as you say, it suffers from potentially discontinuous shadows.

EDIT: Rats, my mistake.

[buzzkill]

[QUOTE=PaulBlay;20794]

The suggested changes would make the following situation *not* LOS.

######################M
@

Frankly I think targetable / LOS at that distance is just greedy. ;-)

I agree. There are always plenty of suggestions on how to make the game easier, making it a little harder just this once won't hurt that much.

[d_m]

Here's the diagram again:

xx####
xx?x.#
xx.!.#
xx#..#
##...#
#@...#
######

As I understand it, based on Eddie's description, the wall tile just north of @ only extends halfway (just to the center point and not beyond); thus, any squares east of straight-north will not be blocked by it. Since the north-east column is a single point with no area, it will only block squares along an exact slope (the x between ? and !).

Thus, since ! is no on the direct line between @ and the column, it is visible. And since the ? is east of the northern wall, and not on the exact diagonal of the column, it too is visible.

To be clear: this is not the suggestion to make each tile into a 4x4 grid and use the middle. Rather, it splits each tile into a 2x2 grid, and each of those grids is only filled if there is another contiguous wall. Thus in many cases a LOS can only be blocked if there are two walls present. E.g.:

+-----+
|@#xxx|
|.....|
|.....|
+-----+

+-----+
|@....|
|.#...|
|..x..|
+-----+

+-----+
|@#xxx|
|.#xxx|
|..xxx|
+-----+

P.S. Inevitably I found another bug. Newest version attached. At least no one on this board will ever mistake me for competent

[etaomyx]

According to the program I wrote (which had a bug that I just fixed, and probably has more) there are no disconnected visible squares:

xx####
xx?x.#
xx.!.#
xx#..#
##...#
#@...#
######

Hmm, so we differ on the tile I marked ?. But the slope of the line between the centers of @, ? is 16 / 4 = 4 / 1. And the slope of the line connecting @ with the lower-right-hand corner of the wall directly above @ is 3 / 1. So any tiles with a steeper slope than 3 / 1 should be obscured. Surely that means ? is not visible?

EDIT: Oops, we also differ on !. But the slope to ! is 3 / 2, which should be blocked by the wall two square up, one square right, which obscures tiles between 9 / 3 and 7 / 5?

[d_m]

According to the program I wrote (which had a bug that I just fixed, and probably has more) there are no disconnected visible squares:

xx####
xx.x.#
xx...#
xx#..#
##...#
#@...#
######

I used this as the input to the program:

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

I am attaching the updated version.

[etaomyx]

I am pretty sure it does not have the reverse problem

Please correct me if I am wrong (this example was done by hand), but with 50% walls:

######
#xxx.#
#x.x.#
#x#..#
##...#
#@...#
######

(x ~ not visible). There is a disconnected visible tile here.

[PowerDiver]

This system allows the player to see very much, even more than the digital field of view (http://roguebasin.roguelikedevelopme..._field_of_view):
.

I've convinced myself that if you want symmetric and also cones, then it is required that the viewer [and symmetrically viewee] have to be smaller than the obstruction. That rules out the field of view above IIUC.

I think there is a solution, of questionable computation time, that I could describe if only I could draw those pretty pictures. Stick with the idea of breaking each square into 16 sub-squares. Give the square's vertices coords divisible by 4, e.g. (0,0) + (0,4) + (4,0) + (4,4). A pillar is then a blockage in the area (1,1) + (1,3) + (3,1) + (3,3). If walls are orthogonally adjacent, connect them in the obvious way. Now the trick. The square [or monster in it] is considered to have 4 eyes, at the midpoints of the edges of the blockage. I.e. at (1,2) + (2,1) + (3,2) + (2,3). Then define two squares to be in LOS of each other if any eye on one can see [unobstructed] any eye on the other. At least that is obviously symmetric.

This does not produce a cone when you are in the same row or column with the obstruction, but it does give cones in the diagonal situations that were annoying people upthread. At least, I hope it does. I don't have graph paper handy. Since only two eyes can look in any direction, and their separation is smaller than the perceived diameter of a blockage, there ought to be a cone of shadow.

It's not totally clear something this complicated is worth the effort.

[d_m]

In my understanding, any field-of-view system which relies on testing for the existence of an uninterrupted centre-to-centre line over a discrete grid will have the problems I have alluded to. You can always align yourself to have a singular (or sufficiently small) beam of sight, and when you do, you will end up seeing only those tiles which match the fraction exactly, which will generally be a sequence of disconnected tiles. This looks awful, and makes no sense.

I think you are misunderstanding; the problem you stated was having small holes in a large field of view, which the system does have. I am pretty sure it does not have the reverse problem ("a sequence of disconnected tiles which you can see")--one of the points of making walls fractional and making monsters/players points is to make it easier to see around corners and through gaps, and make more squares/monsters visible.

[etaomyx]

In my understanding, any field-of-view system which relies on testing for the existence of an uninterrupted centre-to-centre line over a discrete grid will have the problems I have alluded to. You can always align yourself to have a singular (or sufficiently small) beam of sight, and when you do, you will end up seeing only those tiles which match the fraction exactly, which will generally be a sequence of disconnected tiles. This looks awful, and makes no sense.

I like full-tile walls. IMO, partial walls just look wrong, particularly on systems where walls are represented as blocks rather than the hash. In particular, you can't have partial walls and a system where sight is consistent with targeting without allowing projectiles to pass through wall tiles, which again, IMO, would look really bad. Above all else, full-tile walls are easily understood by the player and easy to reason with, people have no reason to assume without prior knowledge that walls don't "actually" take up the whole tile.

In short: I like the present system. It is perfectly consistent if you picture @ as a single point in the middle of the tile, and all monsters as occupying the full tile. It is symmetric: sight is assumed to imply counter-sight, and indeed it would if you take my interpretation. If you want sight and targeting to be equivalent, then you could easily make it so. In particular, the present algorithm explicitly finds the set of discrete angles which intersect each tile, whenever FOV is generated, so it would be easy-as-pie and cost virtually nothing to give targets cover proportionate to the ratio of discrete angles passing through the target tile that are seen. "Half-visible" tiles would get 50% cover. I would be happy to code this.

As for the ghost scenario, I'm for making monsters on walls non-visible, non-targetable, and unable to target you. If a monster in embedded in a full-tile wall, it doesn't really make sense to hit it anyhow.

[d_m]

To sum up, "wouldn't it be nice if"

* What you see is what you can hit with a spell (and vice versa).
* What you see can also see you (and vice versa).
* Standing directly next to a pillar should produce an expanding shadow.
* Reasonably fast code can be produced to implement the FOV, etc.
* No 'trick shots' required (or possible) to hit monsters that you can't target directly.

Is everyone agreed on the above (if they are possible)?

How does the current system specifically differ from the above?

Are any of those points not possible?

I agree that these are all desirable, and if they are not mutually exclusive I'd like them all. I do worry that out of #2-4 we can only have at most two, but if someone can provide an implementation then that would be great.

Incidentally, I think I may have implemented Eddie's suggestion; I wrote a test program (loser.c) that can read in mini-maps and print out LOS diagrams in ASCII. I used it to implement something that I think corresponds to point-based LOS. I am attaching it in the hopes that others can implement and debug their own ideas in this framework. It should cleanly compile via "gcc loser.c" or the Windows equivalent.

[Marble Dice]

What about when the line exactly touches the edge of the 'blocked' area at the edge of the square. In the attachment can the @ see the G or not?

Doesn't make a lot of difference as long as you're consistent. I'd say border cases (single point intersection) are visible. So for our hero and the ghost:

Player          Ghost

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

You wouldn't be able to see them from any further down than that with such a system, however.