targetting and LOS

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • jv123
    replied

    Is this different from the assumption that walls can be zero-width lines? ... I'd like to avoid doing math with smaller squares inside of unit squares if it can be helped.
    So would I! I think it is different, because of the behaviour of single-block pillars. Under your proposed scheme, a pillar horizontally or vertically away from the player would indeed block monsters behind it, by treating the pillar as a zero-size obstruction at its centre. So in this scenario --- @...#...M --- the @ can't see the monster, which I think we all agree is the desired behaviour.

    But as etaomyx describes in post 18 to this conversation, this won't work so well when you're not in a horizontal or vertical line from the player. So in your scheme, things would look like this, with the blank squares being invisible to the @:
    Code:
    ...........
    .@.........
    ...#.......
    ..... .....
    ....... ...
    ......... .
    ...........
    With my suggestion, it would be more like this:
    Code:
    ...........
    .@.........
    ...#.......
    ....  .....
    .....   ...
    ......    .
    .......
    (Of course, I haven't gone to the trouble of calculating this perfectly accurately, but you get the idea.)

    Leave a comment:


  • d_m
    replied
    Originally posted by jv123
    Here's a refinement of PowerDiver's suggestion which solves this problem. Suppose that monsters (and the character, and items) aren't thought of as 'filling' their entire square, but instead are located in a smaller square area inside it. So it the entire square is located with x- and y-coordinates between 0 and 1, then we can imagine a monster (and the character, and items) only occupying the space between 0.25 and 0.75 on each axis. Isolated walls would work the same way. Continuous blocks of wall would only work this way around their edges.
    Is this different from the assumption that walls can be zero-width lines? If you imagine players and monsters only occupying the central point, and lines of sight not being allowed to intersect wall points or wall lines, I think it has the same benefits as yours.

    What are the other important differences? Maybe I'm just not fully understanding, but I'd like to avoid doing math with smaller squares inside of unit squares if it can be helped.

    Leave a comment:


  • jv123
    replied
    I think it's clear that a new system for line-of-sight is needed, and this excellent new proposal has some very good features. But I don't think it's quite right yet: surely we don't want to give up the intuitively-familiar idea that you can hide behind a single pillar.

    Here's a refinement of PowerDiver's suggestion which solves this problem. Suppose that monsters (and the character, and items) aren't thought of as 'filling' their entire square, but instead are located in a smaller square area inside it. So it the entire square is located with x- and y-coordinates between 0 and 1, then we can imagine a monster (and the character, and items) only occupying the space between 0.25 and 0.75 on each axis. Isolated walls would work the same way. Continuous blocks of wall would only work this way around their edges.

    To test if the @ can see a monster, you just test to see if there are any lines that can pass from any point in the @'s area, to any point in the monster's area, without passing through an area occupied by a wall. This test is obviously symmetrical. There is a non--floating point algorithm that can perform this check.

    This is slightly more complicated than the original suggestion, but still intuitive. It maintains all of the good aspects, but behaves better in terms of single isolated wall elements. Let me know what you all think!

    Leave a comment:


  • Bandobras
    replied
    Originally posted by d_m
    This proposal is good--in particular it addresses some annoying inconsistencies with the current treatment of passwall.

    Also, I assume your LOS would be symmetric. I consider that one of the most sorely-needed features.
    Wholeheartedly agreed.

    BTW, I wonder how it relates to LOS modifications in NPP and other variants. I think none were symmetrical and I also don't like the idea that LOS is different from shooting cone, as in NPP. But LOS range and shooting range being different is OK for me. Anyway, I'm curious how the approaches compare...

    Leave a comment:


  • PaulBlay
    replied
    You could use these suckers.



    Although you would almost certainly need to supply a font to go with that.

    [EDIT] I couldn't actually find a font that supports the terminal graphics characters - so I asked someone to add it to their font. .

    Code:
    #############
    #        @
    #      ###### 
    #      #
    ########
    Code:
    [COLOR="Silver"]▛▀▀▀▀▀▀▀▀▀▀▀▀[/COLOR]
    [COLOR="Silver"]▌[/COLOR]        @ [SIZE="1"]- Aargh! It burns my eyes![/SIZE]
    [COLOR="Silver"]▌      	▗▄▄▄▄▄ 
    ▌       ▐█████
    ▙▄▄▄▄▄▄▟█████[/COLOR]
    Éomer soon regretted eating that mushroom.
    Last edited by PaulBlay; June 19, 2009, 14:08.

    Leave a comment:


  • etaomyx
    replied
    Originally posted by PowerDiver
    If you draw a line from the center of one square to the center of another, and it passes through a blockage, not visible.
    Mmm, okay, but then there can be weird gaps in the field of view, like:

    Code:
    .......
    .@.....
    ...#...
    ..... .
    .......

    Leave a comment:


  • PowerDiver
    replied
    Originally posted by etaomyx
    Apologies if I have misunderstood, but in cases like

    Code:
    ............      ........
    .@.###.....M  or  .@......
    ............      .....#..
    ............      ........
    1. Is M visible?
    2. Do the walls even cast shadows?

    (As a random observation, this LOS system would be totally awesome if Angband were represented in unicode, and so you could print those box-drawing glyphs for walls: then LOS would be completely consistent with the visuals. But I don't know, the # symbol looks rather like it should take up a whole tile?)
    Don't overthink the model. It need not be perfect, nor even make sense. The important things are that it should be consistent enough to code easily and properly, and that it gives decent gameplay.

    Given that there seems to be sentiment for non-visible in what I called the boundary case, I can state that the M cannot see the @. The reasoning is that an individual disconnected # counts as a radius 0 blockage at the center. Two adjacent would count as a 0-width line. If you draw a line from the center of one square to the center of another, and it passes through a blockage, not visible. That's the rule.

    Of course, if someone can come up with a different model that is more intuitive that has better gameplay properties, please step forward. You'll notice I didn't put "feature request" in the title of this thread. At this point it's still the "what should we do" phase. I'd love it if someone came up with something better.

    Leave a comment:


  • Atarlost
    replied
    You still have to handle them somehow unless you remove the tunneling mechanic.

    Leave a comment:


  • etaomyx
    replied
    Originally posted by PaulBlay
    those walls cannot exist
    Yep, that's what I had thought. But it also means that rubble would need to be treated differently than walls for LOS, and some occasional strangeness when using stone-to-mud or encountering burrowers ... I don't like where all of that is going.

    Leave a comment:


  • PaulBlay
    replied
    Originally posted by etaomyx
    (As a random observation, this LOS system would be totally awesome if Angband were represented in unicode)
    *ahem*

    Anyway to answer your question in cases like the following I think it is only logical to assume that those walls cannot exist. This would necessitate a change to the dungeon generation routines and vault maps.

    Code:
    ............      ........
    .@.###.....M  or  .@......
    ............      .....#..
    ............      ........

    Leave a comment:


  • etaomyx
    replied
    Apologies if I have misunderstood, but in cases like

    Code:
    ............      ........
    .@.###.....M  or  .@......
    ............      .....#..
    ............      ........
    1. Is M visible?
    2. Do the walls even cast shadows?

    (As a random observation, this LOS system would be totally awesome if Angband were represented in unicode, and so you could print those box-drawing glyphs for walls: then LOS would be completely consistent with the visuals. But I don't know, the # symbol looks rather like it should take up a whole tile?)

    Leave a comment:


  • takkaria
    replied
    +1 from me too.

    Leave a comment:


  • will_asher
    replied
    Originally posted by PowerDiver
    Either it is hard to miss something when targeting something else, or it isn't. The rule, which ISTR was described prominently in the early rules, erred ridiculously in the direction of "it's hard to miss".

    The rule was introduced to stop players shooting "through" party members. However, it is exceptionally hard to get these things right and still playable, and the D&D combination of evasion and damage reduction into a single value called AC makes it impossible. The only way to fix the rule is to throw it away. That is a lesson to be considered when thinking about things like "cover" bonuses in an angband framework.
    The nice thing about pen & paper role-playing games like DND is that when the rules don't work, the DM can change them. How good the DM is makes a whole lot of difference in how good the game is going to be. It's what makes the game playable because it's nearly impossible to make rules that work in every situation that comes up. ..But now I'm way off-topic so maybe I should shut up.

    Leave a comment:


  • PowerDiver
    replied
    Originally posted by will_asher
    The thing wrong with this is that the roll to-hit something assumes that you're trying to hit it. It seems to me that any competent DM would make it very unlikely to hit something like that bat in between by accident.
    Either it is hard to miss something when targeting something else, or it isn't. The rule, which ISTR was described prominently in the early rules, erred ridiculously in the direction of "it's hard to miss".

    The rule was introduced to stop players shooting "through" party members. However, it is exceptionally hard to get these things right and still playable, and the D&D combination of evasion and damage reduction into a single value called AC makes it impossible. The only way to fix the rule is to throw it away. That is a lesson to be considered when thinking about things like "cover" bonuses in an angband framework.

    Leave a comment:


  • will_asher
    replied
    Originally posted by PowerDiver
    When I see D&D and LOS in the same sentence, I remember the rules that made it harder to miss something in between than to hit your target.

    "No, no, I'm not shooting at the bat. I'm aiming at the tree behind it. Before you tell me the AC of the tree, let's see if I make the roll to miss the bat."
    The thing wrong with this is that the roll to-hit something assumes that you're trying to hit it. It seems to me that any competent DM would make it very unlikely to hit something like that bat in between by accident.

    Leave a comment:

Working...
😀
😂
🥰
😘
🤢
😎
😞
😡
👍
👎