targetting and LOS

[Catatonic]

(Edit to add the second comment, which slipped my mind the first time through.)


For what it's worth, this is more or less exactly what I suggested a couple of pages back.

That'll teach me to skim-read

One problem with this is that it also means that the ghost wouldn't be visible, or targetable, even if it were in a wall immediately adjacent to the player - which doesn't necessarily make as much sense. I see no obvious way to avoid this without special-casing, and I'm not sure whether or not this is undesirable enough to all by itself disqualify this approach from consideration.

Well, I think it's important to satisfy the los-symmetry requirement first of all... asymmetrical los leads to potentially abusable situations (even AI 'abusing' los to ambush the player), which IMO is a lot more severe than just
having 'odd' los rules.

On top of that, you have the requirement that creatures 'inside' a wall can shoot out, which basically means that a wall can't hide its own contents.

This seems to induce the general rule that los calculation ignores the status of the start and end tiles. I don't think this generates any weird corner-cases. I suppose you could hand-wave that away by saying ethereal creatures emit light that is only partially blocked by real objects, if that's the sort of thing you like doing

[The Wanderer]

(Edit to add the second comment, which slipped my mind the first time through.)

It seems to me that the core issue is the distinction between wall visibility (intuitively edge-based) and creature/contents visibility (intuitively center-based). We end up with mutually-exclusive requirements only when we insist that they be one and the same thing.

Why not just say that a tile is visible (and therefore gets stored in the memory map) if you can see an edge (or even a corner), but its contents are only visible (and therefore targetable) if you can see its center.

For what it's worth, this is more or less exactly what I suggested a couple of pages back.

This deals nicely with one of the core 'problem cases' of a ghost in a wall 20 tiles down a corrdor. The wall is visible, but neither the ghost not its wall are targetable (and by symmetry, it can't target the player).

One problem with this is that it also means that the ghost wouldn't be visible, or targetable, even if it were in a wall immediately adjacent to the player - which doesn't necessarily make as much sense. I see no obvious way to avoid this without special-casing, and I'm not sure whether or not this is undesirable enough to all by itself disqualify this approach from consideration.

[Catatonic]

It seems to me that the core issue is the distinction between wall visibility (intuitively edge-based) and creature/contents visibility (intuitively center-based). We end up with mutually-exclusive requirements only when we insist that they be one and the same thing.

Why not just say that a tile is visible (and therefore gets stored in the memory map) if you can see an edge (or even a corner), but its contents are only visible (and therefore targetable) if you can see its center. This deals nicely with one of the core 'problem cases' of a ghost in a wall 20 tiles down a corrdor. The wall is visible, but neither the ghost not its wall are targetable (and by symmetry, it can't target the player). This also seems to be intuitive when, for instance, tossing a stone-to-mud at a distant wall. Sure you can see the wall, but it only gets 'mudded' if you hit it dead center, which requires you to dig out some intervening tiles, rather than just hit it with a 'glancing transmutation'.

Edit: Another thing that occurred to me while I was reading this thread was the handling of 'peeking', where the player gets to see everyone in the room just by standing at the doorway. To me, it seems infinitely more elegant simply to offer a 'peek' command, which functions as a los-limited 'detect monster' spell centered at a location of choice adjacent to the player. This eliminates the 'shootable by anyone in the room' problem, while at the same time allowing the player to check the room out without exposing themselves (assuming the monsters they can already see aren't sufficiently terrifying )

[Pete Mack]

HexRogue (java required) works well although I think the dungeon looks more like a cave this way since the walls are often more irregular.
I admit the / and \ don't look like standard ascii characters but it should be possible to fix that.

I don't think Angband needs to move to hex.
However, I've been pondering about doing an hex variant for years but I haven't managed to beat my lazyness so far ^^

It takes some getting used to (and I think they should disable the j&k keys). I'd forgotten just how brutal rogue is...

Killed by an orc at level 4!

[buzzkill]

I don't think Angband needs to move to hex.
However, I've been pondering about doing an hex variant for years but I haven't managed to beat my lazyness so far ^^

That's cool, but definitely in the variant realm.

[zaimoni]

Double-tiling is bad enough with graphics that have tile borders. (and yes, I have seen a game that uses rectangular "hex" grid because of a two unit per tile limit) Without tile borders, which ascii doesn't support, it's going to be completely illegible.

Or rather, most implementations of curses for text consoles don't support --the flags for selectively showing bottom/top/left/right borders are required by reasonably recent XOPEN curses specifications.

Curses wrappers for graphical frontends (e.g., PDCurses/SDL) don't have this difficulty.

[Nolendil]

HexRogue (java required) works well although I think the dungeon looks more like a cave this way since the walls are often more irregular.
I admit the / and \ don't look like standard ascii characters but it should be possible to fix that.

I don't think Angband needs to move to hex.
However, I've been pondering about doing an hex variant for years but I haven't managed to beat my lazyness so far ^^

[Atarlost]

Double-tiling is bad enough with graphics that have tile borders. (and yes, I have seen a game that uses rectangular "hex" grid because of a two unit per tile limit) Without tile borders, which ascii doesn't support, it's going to be completely illegible.

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

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

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

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

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

[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

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

?

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