targetting and LOS
Collapse
X
-
-
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
-
(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 FilesLast edited by d_m; June 21, 2009, 04:12.Comment
-
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
-
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
-
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
-
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).Comment
-
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).Comment
-
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 nextComment
-
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:####???????????? ...#?????????... ...#?????......? ...#?...???????? @.#????????????? ###?????????????
- 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 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
-
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 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.
Code:1 2 3 #@.. #@.. #@.. ##o. ##.. #.o. .#h. ##h. ##h.
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.Comment
-
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: 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.
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
-
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
Comment