Targetting and LOS discussion wiki page

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • d_m
    Angband Devteam member
    • Aug 2008
    • 1516

    #31
    Originally posted by RogerN
    The project_path() algorithm could be rewritten to treat both walls and monsters as diamonds instead of squares. In this case, then neither y nor o will block the arrow. In fact, even if both of them were present at the same time the arrow could still squeeze between them... but that could be handled by a special case since it's probably not desired behavior.
    That seems reasonable. I worry that packs of novice rangers will become way more deadly if they can easily shoot around each other, but maybe that's ok.

    Originally posted by RogerN
    I don't like the idea of having a 50% chance of one of them blocking the arrow. But if both o and y are present, you could randomly choose which one gets hit.
    At that point I think having a determinstic order for which gets hit is better (e.g. hit "o" if present, then hit "y" if present, then hit target).

    Originally posted by RogerN
    I think it's important to ensure the projection paths are symmetrical. If o or y is blocking for @ then it should also be blocking for p.
    Agreed.
    linux->xterm->screen->pmacs

    Comment

    • takkaria
      Veteran
      • Apr 2007
      • 1895

      #32
      Originally posted by d_m
      That seems reasonable. I worry that packs of novice rangers will become way more deadly if they can easily shoot around each other, but maybe that's ok.
      If we're looking at a different system for V, then I would say you don't want that kind of behaviour changing. The idea is to find a system that fixes the current problems without widely impacting on gameplay where the system wasn't previously suboptimal.
      takkaria whispers something about options. -more-

      Comment

      • d_m
        Angband Devteam member
        • Aug 2008
        • 1516

        #33
        Originally posted by takkaria
        If we're looking at a different system for V, then I would say you don't want that kind of behaviour changing. The idea is to find a system that fixes the current problems without widely impacting on gameplay where the system wasn't previously suboptimal.
        I think that's a good metric to use. It helps to get your perspective on this.
        linux->xterm->screen->pmacs

        Comment

        • Pete Mack
          Prophet
          • Apr 2007
          • 6697

          #34
          Here's a summary of what I understand from this discussion, along with some of my preferences.

          I will assume that walls are convex hulls around diamond-shaped wall grids--it makes more sense than anything else.

          Definitions:
          LOS(p1, p2) line from point p1 to point p2 misses (or is tangent to) any intervening wall diamonds.
          T(a, b) grid b is targetable from grid a. (Targeting Line of Sight TLOS)
          V(a, b) grid b is visible from grid a. (Visual Line of Sight VLOS)
          C(a) center point of grid a

          These are my desiderata:
          1. Target symmetry
          1a. assuming a is not a wall and b is not a wall.
          T(a, b) == T(b, a)
          1b. For ghosts in the wall, ghost is treated as in an empty square for T(G,@), but is treated as a wall block for T(@, G)

          2. LOS symmetry
          V(a, b) == V(b, a)

          3. Dominance of V over T. This guarantees VLOS for reverse T(G,@)
          T(a, b) => V(a, b)

          4. Unpermissive TLOS (I lean towards 4a)
          4a By center:
          LOS(C(a), C(b)) <==> T(a, b) [ <==> T(b, a) ]
          4b Existential:
          p1 a p2 b LOS(p1, p2) <==> T(a, b)
          4c. Existential2:
          p1 a, p2 b LOS(p1, p2) <==> T(a, b)

          5. Permissive VLOS. (I lean towards 5a)
          5a. By center
          LOS(C(a), p2 b) | LOS(C(b), p1 a) <==> V(a, b)
          5b. Existential:
          p1 a, p2 b LOS(p1, p2) <==> V(a, b)

          Am I missing anything in this? In this case, a picture may be worth a thousand words, but a little math is worth a thousand pictures. (You may conclude what you will by transitivity )


          EDIT: definitions improved for clarity.
          ... and completeness, and correctness. (5b was badly wrong. 4c was missing.)
          Last edited by Pete Mack; June 26, 2009, 16:52.

          Comment

          • d_m
            Angband Devteam member
            • Aug 2008
            • 1516

            #35
            I will have to start copy-pasting that post to get the set notation

            So one of your implied desiderata is that set the set of visible squares is a proper superset of the set of targetable squares, right (since it follows from 4 and 5)? Where does that rank? In other words, is that property more important than the particulars of 4 and 5, or less so?
            linux->xterm->screen->pmacs

            Comment

            • PaulBlay
              Knight
              • Jan 2009
              • 607

              #36
              Originally posted by Pete Mack
              Here's a summary of what I understand from this discussion, along with some of my preferences.
              You use VLOS once (Visual Line-of-Sight ?). Any difference to the LOS definition at the start of your post?

              I'm going to agree with you on 1, 1a and 1b (tweaking on the 1b situation would be for another thread another day).

              Agree on 2.

              Is 3. defined the right way around?

              TLOS (True Line of Sight ?) isn't defined either.

              ... 考え中 ...
              Currently turning (Angband) Japanese.

              Comment

              • Pete Mack
                Prophet
                • Apr 2007
                • 6697

                #37
                Originally posted by d_m
                I will have to start copy-pasting that post to get the set notation
                Get them from the source.


                So one of your implied desiderata is that set the set of visible squares is a proper superset of the set of targetable squares, right (since it follows from 4 and 5)? Where does that rank? In other words, is that property more important than the particulars of 4 and 5, or less so?
                More important. 4(a-b) and 5(a-b) are particular models that seem to have nice properties, and have already been mentioned in these threads.

                Paul writes
                You use VLOS once (Visual Line-of-Sight ?). Any difference to the LOS definition at the start of your post?
                Yes, VLOS is visual line of sight. LOS(p1, p2) means that there's an unobstructed (by diamond-shaped walls) line between p1 and p2. VLOS and TLOS (targeting LOS) are properties of grids, not points.

                Is 3. defined the right way around?
                Yes, Targeting implies visible.

                I'm going to agree with you on 1, 1a and 1b (tweaking on the 1b situation would be for another thread another day).
                1b is a corollary of a reasonable model for 1a, 2 and 3. I added it for what I thought was clarity . Also, sorry about changing notation (T->TLOS, V->VLOS) midstream. I will fix my original post.
                Last edited by Pete Mack; June 26, 2009, 16:27.

                Comment

                • Pete Mack
                  Prophet
                  • Apr 2007
                  • 6697

                  #38
                  Originally posted by PaulBlay
                  TLOS (True Line of Sight ?) isn't defined either.
                  By the way, I don't know what true line of sight means, or even if it's a meaningful concept for grids. Maybe 5b?

                  Comment

                  • PowerDiver
                    Prophet
                    • Mar 2008
                    • 2780

                    #39
                    Originally posted by aeneas
                    I'm still trying to figure out why it should be changed. But I agree that if it is changed it should be changed so that you can target anything you can see. This still poses problems, when you have ESP.

                    Anyway, I looked over my recent posts with the help of a friend and came to the conclusion that a few of them were not as civil as they should have been. I happen to be missing the part of my personality that cares about civility. So I apologize if you found my earlier posts overly rude. I don't understand that, but I'm willing to take it on faith.
                    Why to change? "It breathes, you die." I find it incredibly irritating to die to a ranged attack from a monster that is within my light radius but is not visible. I find it very irritating to have a death drake in a wall breathe on me but I cannot target it in return. I believe you should support pure spellcasters. I think if a passwall monster can melee an adjacent spellcaster, the spellcaster ought to be able to target it without having to cast stone-to-mud first. I consider each of these to be a much much bigger deal than how you model pillars.

                    We need a highlighting method anyway for the situation where you fire a launcher. In 3.1 there are visible monsters that are technically targetable, but are out of firing range. Solving that properly should be extendable to ESP.

                    I've changed my mind again. You've convinced me that a top priority should be that the display should make LOS totally obvious. I now think my original proposal is best, because everything can be displayed obviously with a properly designed font. I just need to add the restriction that dungeon generation does not ever produce an unattached wall tile.

                    Draw segments between centers of wall tiles that are adjacent horizontally or vertically, and LOS between tiles is interrupted if any such segment intersects the line from the center of one tile to the center of the other. That's the whole model. It allows for walls of width 0, such as the separation of the moat from the interior of a pit, so unfortunately I cannot predict approval, but maybe I'll present a decent case. That intersection problem has been extremely well studied, so efficient implementation is not an issue. To describe everything with proper pictures will have to wait until next week.

                    Stone to mud will occasionally have to destroy multiple wall symbols instead of 1, but that doesn't seem like a dealbreaker, and in my model it should be interpreted to destroy a 20'x20' area in the center of 3x3 10'x10' tiles so it might even be consistent with common sense except for one special case involving a door.

                    I guess my radius-0 obstructing pillars can only appeal to a select few. I should have known anything I thought was really cool would be a mistake.

                    As to your apology, nothing to apologize for, to me anyway. If anything, I am flattered to be called a revolutionary.

                    Comment

                    • Marble Dice
                      Swordsman
                      • Jun 2008
                      • 412

                      #40
                      Eddie, you talkin' about something like this?

                      Code:
                      ##║.║#####║.║######  ##║.║#####║.║######  ##║.║#####║.║######  ##║.║#####║.║######
                      ##║.║#####║.║######  ##║.║#####║.║######  ##║.║#####║.║######  ##║.║#####║.║######
                      ##║.║#╔═══╝+╚═══╗##  ##║.║#╔═══╝+╚═══╗##  ##║.║#╔═══╝+╚═══╗##  ##║.║#╔═══╝+╚═══╗##
                      ##║.║#║.........║##  ##║.║╔╝.........║##  ##║.║╔╝.........║##  ##║.╚═╝.........║##
                      ══╝.╚═╝.........║##  ══╝.╚╝..........║##  ══╝.╚╝..........╚╗#  ══╝.............╚╗#
                      ......@.........║##  ......@.........║##  ...............@.║#  ......@..........║#
                      ══════╗.........║##  ══════╗.........║##  ══════╗.........╔╝#  ══════╗.........╔╝#
                      ######║.........║##  ######║.........║##  ######║.........║##  ######║.........║##
                      ######╚═════════╝##  ######╚═════════╝##  ######╚═════════╝##  ######╚═════════╝##
                      ###################  ###################  ###################  ###################
                      
                      ###################  ###################  ###################  ###################
                      #╔═══════════════╗#  #╔═══════════════╗#  #╔═══════════════╗#  #╔═══════════════╗#
                      #║...............║#  #║...............║#  #║...............║#  #║...............║#
                      #║.╔═══════════╗.║#  #║.╔═══════════╗.║#  #║.╔═══════════╗.║#  #║.╔═══════════╗.║#
                      ═╝.║...........║.║#  ═╝.╨...........║.║#  ═╝.╨...........║.║#  ═╝.╨...........║.║#
                      .@.║...........+.║#  ..@............+.║#  ...............+.║#  ...............+.║#
                      ═╗.║...........║.║#  ═╗.╥...........║.║#  ═╗.╥.@.........║.║#  ═╗.;@..........║.║#
                      #║.╚═══════════╝.║#  #║.╚═══════════╝.║#  #║.╚╡.╞════════╝.║#  #║..;.╞════════╝.║#
                      #║...............║#  #║...............║#  #║...............║#  #║...............║#
                      #╚═══════════════╝#  #╚═══════════════╝#  #╚═══════════════╝#  #╚═══════════════╝#
                      ###################  ###################  ###################  ###################
                      This is probably as good as you can get with the standard extended ASCII, as it lacks solid corner pieces to go along with these: █ ▄ ▌ ▐ ▀ Dwarf Fortress uses similar graphics for smooth walls.

                      Do you no longer feel that DFOV would make LOS very obvious, especially with the highlighting feedback on visible tiles? I assume targeting in DFOV would use the same algorithm as visibility, except including monsters for obstruction. Combined with a targetting UI that considered range and absorption from monsters when accepting targets, I have trouble imagining how anyone could surprise themselves.

                      Comment

                      • PaulBlay
                        Knight
                        • Jan 2009
                        • 607

                        #41
                        Originally posted by Marble Dice
                        Eddie, you talkin' about something like this?
                        Flashback to rogue here.

                        This is probably as good as you can get with the standard extended ASCII, as it lacks solid corner pieces to go along with these: █ ▄ ▌ ▐ ▀ Dwarf Fortress uses similar graphics for smooth walls.
                        The corner pieces exist (in theory) in Unicode land (but I haven't found a font that displays them all sensibly).
                        Currently turning (Angband) Japanese.

                        Comment

                        • PowerDiver
                          Prophet
                          • Mar 2008
                          • 2780

                          #42
                          Originally posted by Marble Dice
                          Do you no longer feel that DFOV would make LOS very obvious, especially with the highlighting feedback on visible tiles?
                          DFOV is equivalent to my model when all you have are rooms and corridors. In either case, IMO the walls of rooms and corridors should be displayed that way. You get intuitive feedback because a monster/player's char at an entrance obviously protrudes past the wall into the interior of a room, instead of things appearing as if the tiles to either side block your view. It also shows passwall monsters protruding which I think, though am not sure, is a good effect. I was thinking about how to display DFOV when I changed my mind back to my original view. If you have a wall of a moat and you use stone-to-mud to cut off a pillar, the display would change [presumably pillars show up something like diamonds] in a strange non-intuitive way. That conflicts with a goal of prioritizing players' comfort with the display.

                          The reasons I think 0-radius pillars are necessary for consistency in my model are subtle. Sometimes inconsistencies are more intuitive, so I'll just have to try to find a minimal set of hacks to get somewhere I can convince people that the hacked model is a good choice.

                          BTW my model incorporates 10'x10' square pillars. The weakness is that the centers of two adjacent pillars have to be 30' apart rather than 20' apart. Also, pillar centers are on grid crossings rather than in the centers of tiles.

                          editing: IMO it is important that the line describing the wall of a moat should be noticeably thinner than any character describing a monster

                          Comment

                          • zaimoni
                            Knight
                            • Apr 2007
                            • 551

                            #43
                            Hmm...variant material here. Too complex for V, but mentioning as this feels like it would have interesting play mechanics for grognards:

                            Let aggressive/defensive stance control unified visibility/projectability for monsters/@ against opponents without telepathy as follows
                            * aggressive: or-symmetrize projectability; aggressive passwall monsters are both visible and targetable, and can launch ranged attacks.
                            * passive: and-symmetrize projectability; passive passwall monsters are neither visible nor targetable, and may not launch ranged attacks.

                            Passive stance for non-passwall monsters/@ isn't as useful. It breaks physical visibility and targetability by bolt/missile/LOS effects, but not telepathic visibility (all monsters have telepathy, currently) or targetability by ball effects.

                            (This has a natural implementation for Zaiband, of course.)

                            Defensive and aggressive modes would then be:
                            Code:
                            ???#@# ???#@#
                            p.xxx# pxxxx#
                            ###### ######
                            On moving to @'s current location, @ has to choose between being able to see the whole corridor (and being targetable by novice ranger p), or not being able to see the whole corridor (and not being targetable by novice ranger p). (For balance reasons, only get to change aggressive/passive stance on move. R)est command probably should be passive.)
                            Zaiband: end the "I shouldn't have survived that" experience. V3.0.6 fork on Hg.
                            Zaiband 3.0.10 ETA Mar. 7 2011 (Yes, schedule slipped. Latest testing indicates not enough assert() calls to allow release.)
                            Z.C++: pre-alpha C/C++ compiler system (usable preprocessor). Also on Hg. Z.C++ 0.0.10 ETA December 31 2011

                            Comment

                            • Pete Mack
                              Prophet
                              • Apr 2007
                              • 6697

                              #44
                              OK, I'm finally taking a serious look at the wiki. There's a lot of stuff there. What there isn't is a set of clear definitions (on one page) of the various algorithms.

                              Some points:
                              1. I don't like the DLOS (5b in my earlier post.) Discrete shadows make no sense, and are confusing as hell.

                              2. In these diagrams, the only model that makes sense to me is "diamond".

                              The others have the extremely non-physical and counterintuitive result that it's easier to hide behind a pillar when you are further away. If you are adjacent to the pillar, there should always be some position in which you can't be seen by a monster "on the other side." Figure 3 in "pillar behavior" (some internal #-bookmarks would be very useful!) shows that diamond is the only one in which the pillar always casts a shadow in some adjacent cell.

                              EDIT:
                              3. Who cares about performance? All algorithms are linear time if you just make a mask... (as angband already does!)

                              Comment

                              • PaulBlay
                                Knight
                                • Jan 2009
                                • 607

                                #45
                                Originally posted by Pete Mack
                                Some points:
                                2. In these diagrams, the only model that makes sense to me is "diamond".
                                diamond completely blocks view through diagonal gaps.

                                Code:
                                #@
                                M#
                                @ can't see M.
                                Currently turning (Angband) Japanese.

                                Comment

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