targetting and LOS

[zaimoni]

A symmetrized viewability/projection algorithm would end up with the following for @

But you don't use that in Zaiband, right?

Currently (Zaiband 3.0.9).

I'm almost annoyed enough with PowerDiver's insistence on advocating a subtly invalid argument with an already-constructed counterexample, to create a birth option for symmetrizing LOS/projectability for Zaiband 3.0.10. It may go in anyway, but I have a personal distaste for making decisons out of anger/annoyance/frustration.

[I have almost made the decision to ditch savegame import from earlier versions into Zaiband 3.0.10; 3.0.8 |-> 3.0.9 corrupts item memory, and trying to fix that currently causes rather catastrophic import bugs. I have made the decision that this isn't a release blocker, two days ago.]

[Nick]

I don't know how long you've been playing bands, but I wonder if you remember Lev. He was King of Bands at one point. He won Z in <50K by abusing every game mechanic he could. I'm still pretty impressed with Lev- he was a very good player. But I have a different philosophy- I only abuse a certain number of things .

One of the big questions about Angband is what constitutes abuse. As far as I am concerned _any_ digging meant to establish a better tactical position is abuse. Yeah- it's in the game. But it allows you to reduce the worst enemies in the game to walking treasure boxes. I don't consider any win that used ASCs at any point a real win.

I've only been playing about 6-7 years, and maintaining less than four. My view on this currently is that I will change LOS/targetting/whatever in FA when I see a compelling reason to do so - and I haven't yet.

As things stand, I tend to see LOS abuse as more a player decision than a maintainer one. This fits my general philosophy of giving the player as much choice of playstyle as possible - I think that even with the most egregious abuse possible it's a pretty hard game. But then I'm just a variant maintainer

[PaulBlay]

I hold that displaying additional walls (such as exterior and corner wall tiles of rooms) does not require making them technically visible or targettable. This applies to the arguments about whether expanding shadows are compatible with 'nice' display of room walls.

For clarity I've suggested some changes to the wiki page and I'd like to know whether anybody really thinks it's a good idea to expand visibility/targetability for walls displayed as a "special case".

Here's an example of what I mean from the "diamond wall blocks" system.

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

Our hero has just walked into a room. The '?' grids are wall tiles that are naturally 'out of sight'.

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

Same situation, but room walls are displayed as a special case. Although they are displayed, they are not targetable and a ghost in the position shown would not be shown (nor would it be able to target the @).

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

Same situation but displayed room walls are specially made visible and targetable. The G can target the @ and the @ could target the G (if there were spells that hit G's in walls). However if the @ casts a stone to mud where the G is it will no longer be a special case and will 'disappear' (no longer be able to target, or be targetable). I don't see why anyone would want this to happen - but if people do speak now or forever hold your peace.

[buzzkill]

I hold that displaying additional walls (such as exterior and corner wall tiles of rooms) does not require making them technically visible or targettable. This applies to the arguments about whether expanding shadows are compatible with 'nice' display of room walls.

I'll take either of the former, though I'd like to see 'special cases' avoided as much as possible, and this 'special case' is pretty trivial, purely aesthetic, and in the long run, probably more confusing than worthwhile.

A simpler way to look at this might just be to ask "How long do you want the hockey stick to be?". The longer the stick, the more permissive the visibility and targeting will be. The current 1x2 HS yields only 20' of visible wall when standing adjacent to it, 40' visibility at 10' distant, etc. Once we establish this number, then mechanics and special cases can be worked out. Poll anybody? [cringes]

[PaulBlay]

I'll take either of the former, though I'd like to see 'special cases' avoided as much as possible, and this 'special case' is pretty trivial, purely aesthetic, and in the long run, probably more confusing than worthwhile.

At least in the case of room walls of lit rooms I don't see that it would be confusing at all.

[EDIT] Deleted stuff I wasn't quite sure about.

[Rizwan]

This is about the advantage of hexes over squares. In a hex map, two adjacent tiles share a vertex iff [if and only if] they share an edge. In a square map, it is possible to share only a vertex.

In the current system, diagonally adjacent #'s are assumed not to touch. Changing that would be a big deal.

If you really want to change this, you should widen the discussion to include switching to a hex map where there is no problem, by design.

So in Angband

   #           and         #
  #                        #

are treated differently? It seems weird that in the case of vertical or horizontal walls we assume they touch with no gap in between but if you have diagonals then they don't touch. If we put two bricks together in the manner shown on the left then we cannot see through the edge that is touching .
And your diamond representation will not change this?
DFOV mentions polygons right? So could we use hexes instead of diamonds and not have it be a big deal?

[Pete Mack]

So in Angband

   #           and         #
  #                        #

are treated differently? It seems weird that in the case of vertical or horizontal walls we assume they touch with no gap in between but if you have diagonals then they don't touch. If we put two bricks together in the manner shown on the left then we cannot see through the edge that is touching .
And your diamond representation will not change this?
DFOV mentions polygons right? So could we use hexes instead of diamonds and not have it be a big deal?

They are certainly treated differently. Surely you recognize the difference between

#####################
# # # # # # # # # # #
## # # # # # # # # ##
# # # # # # # # # # #
## # # # # # # # # ##
# # # # # # # # # # #
#####################

and

#####################
# # # # # # # # # # #
# # # # # # # # # # # 
# # # # # # # # # # # 
# # # # # # # # # # # 
# # # # # # # # # # # 
#####################

[Rizwan]

They are certainly treated differently. Surely you recognize the difference between

#####################
# # # # # # # # # # #
## # # # # # # # # ##
# # # # # # # # # # #
## # # # # # # # # ##
# # # # # # # # # # #
#####################

and

#####################
# # # # # # # # # # #
# # # # # # # # # # # 
# # # # # # # # # # # 
# # # # # # # # # # # 
# # # # # # # # # # # 
#####################

You know you are right but somehow I always thought there was more of a space between those walls. Just shows you that you can play Angband for umpteen years and still not see whats right in front of you. Now that I know there is no space between those wall sits going to bug me whenever I enter into such a room. Thanks Pete
So if you can walk between the ones on top then you should also be able to walk between the ones on the bottom because the # representation visually fools you into believing that there is space there. Maybe the solid wall configuration would help? I still say that @ should not be able to see or walk thorough the pillars shown in the top view.

[zaimoni]

You are agreeing with me. In order to add the property of symmetry, you have to remove the property that an interior square can see the wall.

Actually, the current implementation would have to choose between losing strict conical shadows [logical-or symmetrization; the one-off corrector guarantees this] and interior square can see the wall [logical-and symmetrization].

I find it credible that logical-and symmetrization must lose any pre-existing property that an interior square can see the wall. Both Zaiband's algorithm, and V's current LOS painter, attained that only by messing with the angles that would be needed to calculate Permissive Field of View (and in both cases worked with rational tangents of those angles, rather than directly).

Logical-and symmetrization may well be required to lose the lines that enable the LOS, but it's not obvious. Sketching a naive rigorous demonstration is quick (short paragraph), but that sketch suggests it will be more than a couple of paragraphs if it exists.

Logical-or symmetrization: it should be possible to prove squelching of conical shadows on logical-or symmetrization just from an interior square seeing all walls bounding the room.

[PaulBlay]

They are certainly treated differently. Surely you recognize the difference between [figA] and [figB]

They are treated differently, but they don't necessarily have to be treated differently.

How about a system where

#####################
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
#####################

is identical to

      #####################
     # # # # # # # # # # #
    # # # # # # # # # # #
   # # # # # # # # # # #
  # # # # # # # # # # #
 # # # # # # # # # # #
#####################

?

[flight2q]

As I said, albeit very unclearly, I think that using permissive FOV for visibility but limited FOV for targetting is a good idea; it's very much in line with the current angband model.

+1

Just want to get my vote in while you guys continue to discuss.

While I'm here, but less important... I think visibility should be symmetrical. Targetability doesn't need to be symmetrical, but the exceptions should be simple and memorable, and not depend on the terrain occupied by either party.

[PowerDiver]

They are treated differently, but they don't necessarily have to be treated differently.

How about a system where

#####################
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
#####################

is identical to

      #####################
     # # # # # # # # # # #
    # # # # # # # # # # #
   # # # # # # # # # # #
  # # # # # # # # # # #
 # # # # # # # # # # #
#####################

?

Those two *have* to be treated differently. If the #'s touch in both, the second room contains a set of disconnected spaces. If they do not touch in either, there is no way to step between them in the first diagram when you are restricted to only step to an empty adjacent tile.

If you want to treat them similarly, the right way is to go to a hex map, and then you can alternate solid diagonal walls with connected diagonal spaces. There is a reason some wargamers made the switch to hex maps decades ago.

The DFOV model, i.e. the everything is diamonds model, explains the difference consistently in that diagonally adjacent diamonds do not touch but horiz/vert adjacent diamonds do touch. When I reformulate my suggestion, the second room will be impossible in my model, thus removing any consistency issues.

editing: Oh, I see now, you want an asymmetric system where #'s are adjacent to the NE but not to the SE. It will take some time to think that through.

[Atarlost]

You can't use a hex map without abandoning ascii representation because ascii charachters form a rectiliniar grid. That wouldn't be a true roguelike by the narrowest defenition anymore and would be completely inappropriate for vanilla Angband. It would be such a radical change that I would argue it goes beyond even variant territory.

[Marble Dice]

You can't use a hex map without abandoning ascii representation because ascii charachters form a rectiliniar grid. That wouldn't be a true roguelike by the narrowest defenition anymore and would be completely inappropriate for vanilla Angband. It would be such a radical change that I would argue it goes beyond even variant territory.

Now I'm not saying Vanilla Angband should switch to a hex map, but it wouldn't be that hard:

# # # # # # # # # # #
 # # # . . . . . . . #
# # # # . @ . . . . #
 # # # . . . . . . . #
. . . + . . . > . . #
 # # # . k . . . . . #
# # # # . . . . . . #
 # # # . . . . . . . #
# # # # # # # # # # #

Hexband, anyone?

[zaimoni]

You can't use a hex map without abandoning ascii representation because ascii charachters form a rectiliniar grid.

No, double-tiling works just fine. Read below as "one o and one @"

##oo#####
 ##..####
####@@##

That wouldn't be a true roguelike by the narrowest defenition anymore and would be completely inappropriate for vanilla Angband. It would be such a radical change that I would argue it goes beyond even variant territory.

Agreed.