targetting and LOS

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • PowerDiver
    Prophet
    • Mar 2008
    • 2820

    #76
    Originally posted by jv123
    The ONLY reason this was suggested was to get around the problem that, based on the OP's suggestion, single pillars would cast no shadow at all.
    A different solution is to change the dungeon generation code so that single pillars are not created in the first place. If the player chops one out, he would have only himself to blame for a lack of cover.

    Comment

    • PaulBlay
      Knight
      • Jan 2009
      • 657

      #77
      Originally posted by zaimoni
      Point 2 is the "nobody can ambush worth anything" property; as such, I find it bad for gameplay.
      Well I didn't explicitly mention lighting. You can obviously be ambushed if you are in a lighted area and the monster isn't. In a game with instadeath I'm not sure ambushes need much more encouragement than that.
      Currently turning (Angband) Japanese.

      Comment

      • d_m
        Angband Devteam member
        • Aug 2008
        • 1517

        #78
        (EDIT: As in my earlier posts, I am still arguing for the original suggestion, which is what I implemented in loser.c)

        Just to be clear, the original suggestion does produce shadows... they just aren't as large or nice-looking as people might want.

        If you imagine trying to hide behind a 4-foot diameter tree trunk, it's obviously not casting a huge shadow. And in fact, trying to hide behind it at a distance would be pretty hard.

        I'm also not convinced that monsters in walls are hard. There are two options:

        1. Seeing a wall square means seeing everything in it. In this case, a monster looking out from it gets the same FOV as if the square were open. Players and death drakes can target each other.

        2. Monsters in wall squares are hidden (e.g. not poking out). In this case, the monster's FOV is blocked in all directions, and nothing can target it.

        Either way, you maintain symmetry and normal LOS.
        Attached Files
        Last edited by d_m; June 21, 2009, 04:12.
        linux->xterm->screen->pmacs

        Comment

        • PowerDiver
          Prophet
          • Mar 2008
          • 2820

          #79
          I've figured a better way of explaining why I like my initial proposal. It would be nice to be able to approximate a single grid square by the point at the center. For visibility purposes, that means that it would be nice if the square that are visible from an edge in the half-plane extending out from the edge are similar to those that are visible from the center.

          In the current model, where one sort of assumes that #s fill their entire square, the approximation of a sqaure by its center does not work at the entrance to a room. The following is not exact, but has the flavor of my approach. Imagine the map according to the current system, defining #s to fill their squares entirely. Then shift the grid 1/2 square horizontally and 1/2 square vertically. At this point, grid squares' edges' visibilities are very well approximated by their centers.

          The main problem with my suggested method is that an isolated pillar in the old method ought to be describe by a 2x2 set of #s in the new method, and so individual #s give strange properties. This is most important in rooms where a quarter or half of the interior is made of pillars. Of course, in the current model you really should *not* be allowed to step between two diagonally touching pillars, so it is not surprising that the rooms half-filled with pillars would have to be redesigned. Also, in this new model, you cannot describe two pillars whose exteriors are 10' [1 square] apart., but that is in sync with a minimum width of 20' [1 square + 2 half-squares] for a corridor in the model I described.

          Comment

          • PowerDiver
            Prophet
            • Mar 2008
            • 2820

            #80
            Originally posted by d_m
            2. Monsters in wall squares are hidden (e.g. not poking out). In this case, the monster's FOV is blocked in all directions, and nothing can target it.
            Passwall monsters have to be able to melee from an adjacent wall, for tradition's sake, and also so that a mage-caster cannot make himself invulnerable to passwall monsters' attacks by casting create doors. If a monster can melee you, surely it ought to be able to breathe on you, so they need to be poking out of an adjacent wall. Also, they need to be poking out if you are to be able to melee them. I'd say if they poke out of a wall when you are adjacent, they should still poke out when you are not adjacent..

            Comment

            • d_m
              Angband Devteam member
              • Aug 2008
              • 1517

              #81
              @PowerDiver:

              So would it be fair to say you support option #1 (that LOS for a passwall monster works as if it were a regular monster occupying an open square)?
              linux->xterm->screen->pmacs

              Comment

              • PowerDiver
                Prophet
                • Mar 2008
                • 2820

                #82
                Originally posted by d_m
                @PowerDiver:

                So would it be fair to say you support option #1 (that LOS for a passwall monster works as if it were a regular monster occupying an open square)?
                That's not what #1 meant before. I think I agreed with the prev #1, but not with this. The problem is that some people have made suggestions in which a wall would be visible, but a monster in an empty square at the same location would not be visible. The quote above would make the wall but not the passwall monster visible in such a scenario.

                Comment

                • d_m
                  Angband Devteam member
                  • Aug 2008
                  • 1517

                  #83
                  My understanding of your original suggestion was that the visibility of a square isn't affected by whether the square itself is a wall or not. Is this no longer the case? If so, what are the different criteria for visibility? If not (which I had assumed) then old #1 and new #1 are identical (I think).
                  linux->xterm->screen->pmacs

                  Comment

                  • PowerDiver
                    Prophet
                    • Mar 2008
                    • 2820

                    #84
                    Originally posted by d_m
                    My understanding of your original suggestion was that the visibility of a square isn't affected by whether the square itself is a wall or not. Is this no longer the case? If so, what are the different criteria for visibility? If not (which I had assumed) then old #1 and new #1 are identical (I think).
                    I am not the overlord, and do not have the power to impose the final solution. Hopefully all of my proposals are consistent with the principles I espouse, but when talking about general principles it is important to see how they interact with all of the ideas under consideration, including ones I don't like as much as others.

                    Comment

                    • d_m
                      Angband Devteam member
                      • Aug 2008
                      • 1517

                      #85
                      I guess I made the mistake of immediately implementing your suggestion, which seems to work well. So I may be a little too eager to frame the conversation around that because there is a testable implementation out there.

                      I guess the answer is to try to implement the 4x4 subgrid solution next
                      linux->xterm->screen->pmacs

                      Comment

                      • Marble Dice
                        Swordsman
                        • Jun 2008
                        • 412

                        #86
                        PowerDiver: Your "4 eyes" solution does produce expanding shadows on the diagonal only, albeit very long, thin ones. Does this 4 eyes method provide any benefits above a system where walls function as you describe, yet LOS is simply checked from center-to-center (the original 4x4 sub-grid method)?

                        The only complaint I've heard so far with a 4x4 sub-grid is some visual artifacting of this nature:

                        Code:
                        ####????????????
                        ...#?????????...
                        ...#?????......?
                        ...#?...????????
                        @.#?????????????
                        ###?????????????
                        Let me propose another method for review (obstructing diamonds):
                        1. Visibility between two tiles is determined by a single unobstructed line between the center of the first tile to the center of the second.
                        2. Wall tiles contain an obstructing diamond, with the 4 points of the diamond centered along the 4 edges of the wall tile.
                        3. Obstruction from the observer's tile and the observed tile are disregarded.
                        4. Visibility is permitted on the border of the obstructing diamond, EXCEPT at one of a diamond's four points WHEN there is an adjacent wall tile.


                        I believe such a method would...
                        ...have guaranteed symmetry, and be suitable for LOS=projectability with no trick shots.
                        ...be immune to the artifact described above. I can't think of any others that would affect it.
                        ...display ghosts in corridor walls up to two spaces away.
                        ...reveal the knight's move around corners (visible hockey stick).
                        ...exhibit similarly sized expanding shadows behind pillars in all directions.

                        I am pretty tired though so I'm sure I'm overlooking something.

                        Comment

                        • d_m
                          Angband Devteam member
                          • Aug 2008
                          • 1517

                          #87
                          Originally posted by Marble Dice
                          Let me propose another method for review (obstructing diamonds):
                          1. Visibility between two tiles is determined by a single unobstructed line between the center of the first tile to the center of the second.
                          2. Wall tiles contain an obstructing diamond, with the 4 points of the diamond centered along the 4 edges of the wall tile.
                          3. Obstruction from the observer's tile and the observed tile are disregarded.
                          4. Visibility is permitted on the border of the obstructing diamond, EXCEPT at one of a diamond's four points WHEN there is an adjacent wall tile.


                          I believe such a method would...
                          ...have guaranteed symmetry, and be suitable for LOS=projectability with no trick shots.
                          ...be immune to the artifact described above. I can't think of any others that would affect it.
                          ...display ghosts in corridor walls up to two spaces away.
                          ...reveal the knight's move around corners (visible hockey stick).
                          ...exhibit similarly sized expanding shadows behind pillars in all directions.

                          I am pretty tired though so I'm sure I'm overlooking something.
                          I think your results seem good. The only strange result you get (which all of these systems have to some degree) is that the projection path will either hit squares that weren't considered blocking, or that the projection path will "tunnel" between two squares:

                          Code:
                          1      2      3
                          #@..   #@..   #@..
                          ##o.   ##..   #.o.
                          .#h.   ##h.   ##h.
                          In case (1), the wall and the orc don't block @'s LOS to the dark elf. Should a projectile hit the wall? If not, should a projectile hit the orc? If no to both, you get an "electron tunneling" effect where the arrow goes between # and o.

                          If the arrow hits the # then you end up with a lot of squares that are visible but not projectable, and case (2) seems kind of bad.

                          If the arrow hits the "o", then things are mostly fine (and this is probably how I would implement it) although there is some tension in how to handle (3). Some people might want the shot to avoid the orc, although I am fine with having both of those intervening squares "absorb" arrows, if they are not clear (or if one is a wall).

                          I added a conservative LOS mode to my program; I will try to code up this diamond mode also.
                          linux->xterm->screen->pmacs

                          Comment

                          • Marble Dice
                            Swordsman
                            • Jun 2008
                            • 412

                            #88
                            Resolving projectile blocking in most visibility systems could probably spawn its own discussion as large as this one about targeting and LOS. I see a few good alternatives:

                            A) No projectile absorption

                            If you can see it, then you can hit it with an arrow. Nailing the yeek standing behind an ancient multi-hued dragon in a straight, narrow corridor doesn't make a lot of sense, but then again neither does being able to see that yeek in the first place. The latter certainly makes for better gameplay IMO, maybe the former would also be tolerable. It would make groups of ranger monsters more dangerous.

                            B) Monsters only absorb at their center

                            This would allow rows of monsters in horizontal and vertical corridors to absorb projectiles, but you'd be able to shoot through them diagonally in most cases. There would only be sparse absorption (dotted and discontinuous) along non-45 degree lines, which would be difficult for the player to mentally calculate in order to make informed decisions.

                            C) Monsters also absorb in a diamond pattern, also absorbing at the diamond's border intersection.

                            This approach's main drawback would probably be implementation complexity, but it might work out pretty well. Haven't thought a lot about it just yet.

                            D) Implement a path-finding algorithm for projectiles

                            This would allow projectiles to walk towards the target, avoiding walls and possibly other absorbing monsters when possible, but would also be more complex to implement and be more difficult for the player to use in informed actions.

                            Comment

                            • PowerDiver
                              Prophet
                              • Mar 2008
                              • 2820

                              #89
                              Originally posted by Marble Dice
                              PowerDiver: Your "4 eyes" solution does produce expanding shadows on the diagonal only, albeit very long, thin ones. Does this 4 eyes method provide any benefits above a system where walls function as you describe, yet LOS is simply checked from center-to-center (the original 4x4 sub-grid method)?

                              Let me propose another method for review (obstructing diamonds):
                              • Visibility between two tiles is determined by a single unobstructed line between the center of the first tile to the center of the second.
                              • Wall tiles contain an obstructing diamond, with the 4 points of the diamond centered along the 4 edges of the wall tile.
                              • Obstruction from the observer's tile and the observed tile are disregarded.
                              • Visibility is permitted on the border of the obstructing diamond, EXCEPT at one of a diamond's four points WHEN there is an adjacent wall tile.
                              I don't particularly like the "4 eyes" thing. I meant it as an example of how clunky you have to get to force expanding cones. I considered it necessary over center-to-center so that one wall square does not obstruct another on a long straight wall.

                              If you are willing to use obstructing diamonds, why not just accept the "field of view" that even comes with an implementation? I would bet that the author of that method has thought about obstructing diamonds longer than you or I ever will.

                              You start with a clean elegant method, and then apply some hackish mods. I don't see any obvious problem, but I expect there are some lurking. One difficulty is that I think expanding shadow cones for single # columns is a mistake, so I'm not sure that I can evaluate your idea properly given my viewpoint. Am I biased here, or is an expanding cone the logical flaw that should end the argument? I don't know.

                              I view what you are doing as trying to impose finer granularity, but only part way. The more normal wargaming viewpoint is that at the minimum granularity, the unit is expected to be spread over the entire square. That means it should have the full visibility of all points in the square it covers, and be able to attack in all directions. When you change this, there will be unintended consequences. The "field of view changes this to being spread over the inscribed diamond, but then is completely consistent with that refinement. In my original proposal I changed this, but I was very very careful about it and mainly changed it for a # directly between the viewing endpoints.

                              I also think you should *start* with defining and modeling the properties of passwall monsters. They are fundamental to the game, and if you don't start with them your solution is unlikely to deal with them properly at the end.

                              Comment

                              • Atarlost
                                Swordsman
                                • Apr 2007
                                • 441

                                #90
                                Does monster LoS ever matter for anything except the player?

                                If not you can easily get symmetry for any setup by only looking at player LoS and using the bugblatter beast of traal method for determining monster LoS.
                                One Ring to rule them all. One Ring to bind them.
                                One Ring to bring them all and in the darkness interrupt the movie.

                                Comment

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