targetting and LOS

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • PaulBlay
    Knight
    • Jan 2009
    • 657

    #46
    Originally posted by PowerDiver
    If you want something along these lines, I think you'd have to define it as some sort of measure of the proportion of points in the two squares that can see each other.
    I did come up with a variation that was symmetrical, but apart from being even more complicated I had to introduce 'special case' handling to stop people being able to see the whole of rooms when in the entrance.

    I won't go into details unless I can think of a relatively easy (fast running) way to implement it.
    Currently turning (Angband) Japanese.

    Comment

    • d_m
      Angband Devteam member
      • Aug 2008
      • 1517

      #47
      As far as I can tell, the biggest criticism of Eddie's original spec is that the shadows it casts aren't nice looking.

      How much of a showstopper is this? After some thought, I think that attractive shadows may be incompatible with symmetry, and I definitely prefer the latter. Consider the following:

      Code:
      ###############
      #........o
      #.....
      #.@#
      #.....
      #........
      ###############
      The orc in the picture is not visible by @ (at least, according to one of the alternate proposals). However, it seems to me that if the positions of @ and o were reversed, @ would expect to see the orc (and currently would, I think). Thus, either the system is not symmetrical, we end up with some very strange LOS situations, or it is not coherent.

      EDIT: I should say that I think this argument applies to most of the systems designed to create "expanding shadows" via Eddie's argument that asymmetric beholder-beholden relationships imply asymmetric visibility.
      linux->xterm->screen->pmacs

      Comment

      • PaulBlay
        Knight
        • Jan 2009
        • 657

        #48
        I think we're all getting a little confused / off track here.

        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?
        Currently turning (Angband) Japanese.

        Comment

        • Marble Dice
          Swordsman
          • Jun 2008
          • 412

          #49
          Originally posted by d_m
          As far as I can tell, the biggest criticism of Eddie's original spec is that the shadows it casts aren't nice looking.

          How much of a showstopper is this?
          Considering that shadows also imply lack of visibility and thus the feasibility of cover, I think it's important. The problem isn't that they aren't nice looking so much as they don't provide adequate cover, and it's drastically inconsistent with the shadows cast on the horizontal/vertical (you're never going to fix that 100% in a square tile based system, but you can do a lot better than thin dotted line shadows).

          Here's how the situation you describe would look from both perspectives, using a line from tile center to tile center for visibility, and walls obstructing from 1/4 to 3/4 inside of a tile.

          Code:
          Player                 Orc
          #################      #################
          #..............?#      #..............o#
          #...........????#      #...............#
          #.......@#??????#      #.......?#......#
          #...........????#      #....???........#
          #..............?#      #????...........#
          #...............#      #??.............#
          ####.############      ####.############
          This is a lot easier for me to believe than having a series of disconnected blind spots in a diagonal line behind a pillar. Using a line from center to center is necessarily symmetric because if you can draw a line from one direction without obstruction, you can draw the same line from the other direction without obstruction.

          Paul - I agree with all your points, and I believe this system is compatible with all of them.

          Comment

          • PaulBlay
            Knight
            • Jan 2009
            • 657

            #50
            Originally posted by Marble Dice
            Here's how the situation you describe would look from both perspectives, using a line from tile center to tile center for visibility, and walls obstructing from 1/4 to 3/4 inside of a tile.
            Described like that you would not be able to see ghosts in the wall of corridors, nor would they be able to see you. (Because the middle of their tile is inside the wall)
            Currently turning (Angband) Japanese.

            Comment

            • Marble Dice
              Swordsman
              • Jun 2008
              • 412

              #51
              Originally posted by PaulBlay
              Described like that you would not be able to see ghosts in the wall of corridors, nor would they be able to see you. (Because the middle of their tile is inside the wall)
              Plus these two points:

              1) Walls don't obstruct themselves. If the only obstruction is a wall at the final "observed destination", then that tile is visible (otherwise you'd never be able to see any walls, ever).
              2) If an enemy is in a visible tile (wall or open), that enemy is visible.

              Am I missing something here?

              Comment

              • PaulBlay
                Knight
                • Jan 2009
                • 657

                #52
                Originally posted by Marble Dice
                Am I missing something here?
                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?
                Attached Files
                Currently turning (Angband) Japanese.

                Comment

                • will_asher
                  DaJAngband Maintainer
                  • Apr 2007
                  • 1124

                  #53
                  Originally posted by Marble Dice
                  One good reason is that in a symmetrical visibility system, it is easy and intuitive to determine which enemies have LOS on you. If there are many asymmetrical lines of sight, then it becomes difficult to avoid situations where enemies have asymmetrical LOS on you, and it also encourages the exploitation of AI which doesn't strive to avoid being the victim of asymmetrical LOS (the classic hockey stick).
                  With my suggestion (which I don't really expect many people to agree with), the player has the advantage that sleeping & stupid monsters don't hide behind corners. And also the fact that the player is much smarter than any of the monsters. Probably only intelligent creatures (people, orcs, dark elves..) should be considered smart enough to take advantage of the same things that the PC can take advantage of.
                  If you consider dragons intelligent, then there would still be the fact that there is a huge difference between a PC peeking around a corner (hard to notice) and a dragon peeking around a corner to breathe (big head == very easy to notice).

                  Originally posted by Marble Dice
                  Additionally I would argue that certain asymmetrical lines of sight would make the game significantly more tactically frustrating in a bad way - consider breaking into a room with breathers in the corners with a system where the room inhabitants can see you at the door, but you can't see them. Effectively, they'd get two chances to breath on you before you could even see them, once at the door and once as you stepped into the room. The first aggressor in Angband is already at a disadvantage due to the turn-based nature of the game, and asymmetrical lines of sight only exacerbate the problem.
                  Remember my example:
                  Code:
                      #.#    
                  #####@#
                  ..M...#
                  #######
                  where the @ is peeking around the corner. The same situation would apply when the PC is entering a room. It would be almost the opposite of what you said: The PC would see the big breathers you mention before entering the room because he can peek around the corners while he is next to a corner. At the same time, he would be hiding most of his body around the corner of the doorway, making it unlikely that the monster would notice him. There is also the fact that most big breathers start out sleeping and are not very alert.

                  Taking advantage of situations where you can see your target but the target can't see you is a very realistic aspect of battle and should be allowed IMO. Ideally, intelligent monsters would be given AI to avoid being the victim of asymmetrical LOS.

                  Unfortunatly my suggestion has the disadvantage of being probably extremely hard to implement so that it works correctly. I guess my point is that I think that line of sight should not be symmetrical, and since my suggestion would be very hard to implement, I prefer that LOS stay as it is currently.

                  EDIT: sorry that I kindof contradicted myself by agreeing to Powerdiver's suggestion in the OP, but I've thought about it more since then. I agree that walls should not be considered to take up the whole square (that would go well with my ideal suggestion), but not if it makes line of sight symmetrical.
                  Last edited by will_asher; June 19, 2009, 21:46.
                  Will_Asher
                  aka LibraryAdventurer

                  My old variant DaJAngband:
                  http://sites.google.com/site/dajangbandwebsite/home (defunct and so old it's forked from Angband 3.1.0 -I think- but it's probably playable...)

                  Comment

                  • Marble Dice
                    Swordsman
                    • Jun 2008
                    • 412

                    #54
                    Originally posted by PaulBlay
                    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:

                    Code:
                    Player          Ghost
                    
                    ?####G?????     ????#G#????
                    ...@.......     ???@....???
                    ?#####?????     ?#########?
                    You wouldn't be able to see them from any further down than that with such a system, however.

                    Comment

                    • d_m
                      Angband Devteam member
                      • Aug 2008
                      • 1517

                      #55
                      Originally posted by PaulBlay
                      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.
                      Attached Files
                      linux->xterm->screen->pmacs

                      Comment

                      • etaomyx
                        Rookie
                        • May 2009
                        • 17

                        #56
                        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.

                        Comment

                        • d_m
                          Angband Devteam member
                          • Aug 2008
                          • 1517

                          #57
                          Originally posted by 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 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.
                          linux->xterm->screen->pmacs

                          Comment

                          • PowerDiver
                            Prophet
                            • Mar 2008
                            • 2820

                            #58
                            Originally posted by Atanvarno
                            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.

                            Comment

                            • etaomyx
                              Rookie
                              • May 2009
                              • 17

                              #59
                              Originally posted by d_m
                              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:

                              Code:
                              ######
                              #xxx.#
                              #x.x.#
                              #x#..#
                              ##...#
                              #@...#
                              ######
                              (x ~ not visible). There is a disconnected visible tile here.

                              Comment

                              • d_m
                                Angband Devteam member
                                • Aug 2008
                                • 1517

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

                                Code:
                                xx####
                                xx.x.#
                                xx...#
                                xx#..#
                                ##...#
                                #@...#
                                ######
                                I used this as the input to the program:

                                Code:
                                ######
                                #....#
                                #....#
                                #.#..#
                                ##...#
                                #@...#
                                ######
                                I am attaching the updated version.
                                Attached Files
                                linux->xterm->screen->pmacs

                                Comment

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