Angband Forums

Angband Forums (http://angband.oook.cz/forum/index.php)
-   Vanilla (http://angband.oook.cz/forum/forumdisplay.php?f=3)
-   -   Targetting and LOS discussion wiki page (http://angband.oook.cz/forum/showthread.php?t=2046)

PaulBlay June 25, 2009 09:55

Targetting and LOS discussion wiki page
 
I'm writing up a wiki page in roguebasin for the Targetting and LOS discussion (as the thread is rather out of hand).

What I would like are
1. Corrections and additions.
2. Permission to copy your post text into the wiki-licensed page.

Obviously direct participation in Roguebasin is welcome, but you can just post stuff here or in the main Targetting and LOS thread.

aeneas June 25, 2009 10:41

Wow- do me a favor and stay the hell away from V, OK. You need to be a variant maintainer, if only to keep the rest of us safe from this sort of thing.

I like to play Angband more than I like to theorize about visibilty. Part of playing Angband well is being able to figure out who can target you without having to check. This gets a bit complicated at times, and I have to admit that I do guess, occasionally. And then I check, if it matters. But I do this very rarely- I usually know who can target me without having to think about it.

If I have to memorize your diagrams to figure that out, well- we'll always have 3.0.6.

More seriously, I'd suggest that you play some Angband before suggesting catastrophic changes to it. There are a lot of ideas out there. You happen to be very loud about yours. You would make a great variant maintainer.

PaulBlay June 25, 2009 10:46

Quote:

Originally Posted by aeneas (Post 21131)
More seriously, I'd suggest that you play some Angband before suggesting catastrophic changes to it. There are a lot of ideas out there. You happen to be very loud about yours. You would make a great variant maintainer.

Er, all that stuff is taken out of a certain far too long thread and little of it is actually mine.

aeneas June 25, 2009 11:00

Quote:

Originally Posted by PaulBlay (Post 21133)
Er, all that stuff is taken out of a certain far too long thread and little of it is actually mine.

That's immaterial. What I want to know is this: can I easily figure out who can target me. I have a great deal of respect for Eddie, but if he suggests some weird diagram that I have to think about I'm perfectly willing to tell him to stay the hell away from V. I mean, I like his variant, but it uses the standard targeting code. And anyway it's a _variant_. Kind of fun too- but not V. Though I have to admit that I think V should adopt the no-sell bit.

Anyway, Eddie is a great Angband player. And he has some great ideas about Angband- some revolutionary ideas. But he has also proposed some incredibly dumb ideas. Lots of them. That's what's great about Eddie- he proposes all kinds of things and doesn't worry much about them after that. Except for the few things he added to his var5iant, but that's another story.

Anyway, here's the important bit about LOT. I'm going to be very pissed if I don't understand it. I've been playing Angband for years. I know who can target me, and when they can target me. If I get killed by Vecna because he stormed me when I thought he couldn't I'm not going to care much about whether the change was your idea or Eddie's idea.

Marble Dice June 25, 2009 17:36

The charts, diagrams, etc are just there to help people understand the various proposed systems, so we can think about which one makes the most sense. Trust me, no one wants to memorize a bunch of charts to drive an LOS/LOT system. I think the ideal here is symmetry in visibility and visibile = targetable. This would imply if you can see it, it can see you, and you can target it, and it can target you. If you can't see something it cannot see or target you, and vice-versa.

I updated the wiki page to include a bit more structure. Everyone feel free to look over it and add any points you feel have been left out.

At the conclusion of the big ol' targeting/LOS thread, we've basically arrived at two possible methods: 1) Digital Field of View or 2) something that incorporates expanding pillar shadows. I put the most information in the two methods I think best represent these two alternatives.

d_m June 25, 2009 17:57

If we are going to try to communicate via this wiki, what is the protocol? Should I just modify junk?

Also, I'd like to see more distinction between FOV and LOS/projectile-paths, since while they are related they are different and have their own nuances. For instance, certain FOV implementations might require interesting projectile paths to work. I am happy to add this as to the wiki as long as I can be sure not to step on someone else's toes.

Marble Dice June 25, 2009 18:03

Quote:

Originally Posted by d_m (Post 21153)
Should I just modify junk?

...long as I can be sure not to step on someone else's toes.

Conventional wiki wisdom dictates that you edit first, think later. If someone doesn't like what you've done, they'll just fix it. More likely they'll re-organize, expand, and improve upon what you contribute.

PaulBlay June 25, 2009 18:04

Quote:

Originally Posted by Marble Dice (Post 21152)
I updated the wiki page to include a bit more structure. Everyone feel free to look over it and add any points you feel have been left out.

I added back in the "Other points for consideration".

Added more fig numbers for ease of reference.

PaulBlay June 25, 2009 18:06

Quote:

Originally Posted by d_m (Post 21153)
If we are going to try to communicate via this wiki, what is the protocol? Should I just modify junk?

I would say that forum threads are a fine place to argue, but wiki pages are much better for keeping track of the points made.

PowerDiver June 25, 2009 18:20

Quote:

Originally Posted by aeneas (Post 21134)
Anyway, here's the important bit about LOT. I'm going to be very pissed if I don't understand it.

That is the appeal for reverse targetable implying visible. You get that with symmetry plus visible == targetable. I would like some sort of highlighting method to make obvious which monsters detected through spell or ESP are in, versus not in, reverse LOS.

There would still be a learning curve about stepping into LOS of a monster. If things change, there's no way to avoid that. I suppose you should modify disturb to stop you before it [knowingly] happens when you are running.

RogerN June 25, 2009 19:35

Regarding the section "Diamond walls, point visibility". A possible disadvantage is that, for certain arrangements of pillars, you can end up with disconnected regions of visibility (i.e. a dotted line of visible tiles which do not touch):

Code:

@#?????
...
###.#
    .
    ?.?

        ?.?


PaulBlay June 25, 2009 19:38

Quote:

Originally Posted by RogerN (Post 21162)
Code:

@#?????
...
###.#
    .
    ?.?

        ?.?


I think that's worth adding to the wiki. I think I'll do up a larger scale diagram to double check (not that I doubt you, but to make it easier to visualize).

RogerN June 25, 2009 19:47

Quote:

Regarding the section "Diamond walls, point visibility". A possible disadvantage is that, for certain arrangements of pillars, you can end up with disconnected regions of visibility (i.e. a dotted line of visible tiles which do not touch)
Incidentally, these artifacts are the result of allowing line-of-sight to pass through tiles which aren't visible. In other words, a line going to the center of tile A is obstructed by some other intervening wall, making tile A invisible. But a line which passes through the corner of tile A is allowed to go through (since it doesn't intersect the diamond), and therefore you may end up with disconnected visible tiles on the far side of tile A.

PaulBlay June 25, 2009 20:01

1 Attachment(s)
OK, here's my version of your fig.

Green diamonds = visible walls
Red diamonds = out-of-LOS walls
Dots = visible floor tiles

There's a big version at the wiki page. (A bit too big really ;-)

buzzkill June 25, 2009 20:47

Quote:

Originally Posted by PaulBlay (Post 21168)
OK, here's my version of your fig.

Green diamonds = visible walls
Red diamonds = out-of-LOS walls
Dots = visible floor tiles

There's a big version at the wiki page. (A bit too big really ;-)

I'll take issue with that. The 2 southernmost dots, are not visible. The furthest dot is a borderline case, normally visible, but since it is borderline blocked from 2 opposing sides, is has to be considered non-visible (even if a special exception be made). The dot above it has no line of sight to the center point.

RogerN June 25, 2009 20:59

Quote:

The 2 southernmost dots, are not visible. The furthest dot is a borderline case, normally visible, but since it is borderline blocked from 2 opposing sides, is has to be considered non-visible (even if a special exception be made). The dot above it has no line of sight to the center point.
Paul's diagram is not exactly the same as mine. In my diagram, the two southernmost points are 1 tile farther to the right. In the situation as I originally described it, both points clearly have LOS to the center and neither case is borderline.

Diagram to follow...

PaulBlay June 25, 2009 21:02

Quote:

Originally Posted by buzzkill (Post 21172)
I'll take issue with that. The 2 southernmost dots, are not visible. The furthest dot is a borderline case, normally visible, but since it is borderline blocked from 2 opposing sides, is has to be considered non-visible (even if a special exception be made). The dot above it has no line of sight to the center point.

This isn't the Digital Field of View method, there is nothing stated in the definition to disallow a LOV just because it touches exactly the point of a wall tile above in one place and below in another.

You're probably right about the dot in the middle, although it should be noted that my diagram is not 100% accurate and should be checked with maths before being taken as gospel.

Code:

@#?????
...
###.#
    .
    ? ?

        ?.?

Probably the middle dot shouldn't be there - as shown above.

PaulBlay June 25, 2009 21:13

Quote:

Originally Posted by RogerN (Post 21173)
Paul's diagram is not exactly the same as mine.

Yeah, it's a lot easier to see when you replace the spaces with x's.

Code:

@#?????xxxx
...xxxxxxxx
###.#xxxxxx
xxxx.xxxxxx
xxxxx?.?xxx
xxxxxxxxxxx
xxxxxxxx?.?

I'll put up a mark two.

RogerN June 25, 2009 21:15

This is the correct diagram. You can see that the two southernmost points are not borderline (although they are close to borderline); they are clearly visible according to the rules.

http://mysite.verizon.net/rogercnorris/los.png

PaulBlay June 25, 2009 21:19

Quote:

Originally Posted by RogerN (Post 21178)
This is the correct diagram. You can see that the two southernmost points are not borderline

The third of the horizontal trio is borderline, though. I think it 'just' touches the diamond, so it's safe under the definitions used.

d_m June 25, 2009 21:22

So I added a section on Terminology to the wiki page, which will hopefully clear up some confusion (or at least make some genuine disagreement explicit); please let me know if you don't agree or think I'm crazy.

The thing that I think is important to add to the discussion (which has so far mostly been left out) is how projectile-paths should be implemented in the particular suggestions. Especially in DFOV, there are situations where a wall square won't block a projectile, but players might expect a monster in that square to absorb the missile. E.g.:

Code:

@.#  @.#  @.#
#o#  o##  oy#
#p#  #p#  #p#

In each of these, most player would like to imagine that the novice ranger couldn't shoot them. The question is, what is the correct way to implement projectile path? Whatever your answer, consider the following:

Code:

@.#  @.#
o.#  .y#
#p.  #p#

Are the player's shots against the novice ranger blocked in both of these cases? Clearly, if the orc/yeek were walls, the shot would be available (according to DFOV). This implies (to me) that projectile paths will need to treat occupied squares and walls differently in terms of path-blockage.

Either that, or that projectiles will be much harder (or impossible) to block, which has very serious (probably unacceptable) problems for game play.

aeneas June 25, 2009 21:22

Quote:

Originally Posted by PowerDiver (Post 21159)
That is the appeal for reverse targetable implying visible. You get that with symmetry plus visible == targetable. I would like some sort of highlighting method to make obvious which monsters detected through spell or ESP are in, versus not in, reverse LOS.

There would still be a learning curve about stepping into LOS of a monster. If things change, there's no way to avoid that. I suppose you should modify disturb to stop you before it [knowingly] happens when you are running.

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.

PaulBlay June 25, 2009 21:26

Quote:

Originally Posted by d_m (Post 21180)
The thing that I think is important to add to the discussion (which has so far mostly been left out) is how projectile-paths should be implemented in the particular suggestions.

Zaimoni probably has the best handle on that (I added a section to the wiki page based on his recent post).

RogerN June 25, 2009 21:26

Quote:

Originally Posted by PaulBlay (Post 21179)
The third of the horizontal trio is borderline, though. I think it 'just' touches the diamond, so it's safe under the definitions used.

It just looks that way because I drew the diagram so small :) The line does not touch the diamond at all. I should draw up a larger version...

PaulBlay June 25, 2009 21:31

1 Attachment(s)
Quote:

Originally Posted by RogerN (Post 21183)
It just looks that way because I drew the diagram so small :) The line does not touch the diamond at all. I should draw up a larger version...

It touches in the big version I drew (my piccy in the wiki is reduced to 50% width/height). In fact it is simple geometry that it touches (measure the sides and remember "similar triangles" from comprehensive school ;-)

Just imagine two triangles, the one visible in the diagram and the one formed by the left hand point, the lower diamond point, and the center of the diamond.

zaimoni June 25, 2009 21:43

Quote:

Originally Posted by d_m (Post 21180)
The question is, what is the correct way to implement projectile path? Whatever your answer, consider the following:

Code:

@.#  @.#
o.#  .y#
#p.  #p#

Are the player's shots against the novice ranger blocked in both of these cases? Clearly, if the orc/yeek were walls, the shot would be available (according to DFOV). This implies (to me) that projectile paths will need to treat occupied squares and walls differently in terms of path-blockage.

Zaiband and V both handle this by using a parameter to signal whether occupied squares block (bolt/physical missile) or not (ball, beam).

In V:
* o blocks @'s shot of p but does not block p's shot of @
* y blocks p's shot of @ but does not block @'s shot of p

DFOV indeed would not let either o or y provide cover for anyone. The gameplay effects of this are indeed pervasive.

RogerN June 25, 2009 21:45

Yet another diagram, demonstrating that the LOS does not touch the corners of any intervening diamonds:

http://mysite.verizon.net/rogercnorris/los2.png

d_m June 25, 2009 21:50

Quote:

Originally Posted by zaimoni (Post 21186)
DFOV indeed would not let either o or y provide cover for anyone. The gameplay effects of this are indeed pervasive.

Thanks for reviewing V's current project_path() algorithm; I think it's a good place to start talking about projectile paths. It wasn't clear to me that DFOV would have to work any particular way which is why I posed the question.

I can imagine using the current project_path() algorithm but just skipping blockages by walls. I can also imagine either skipping both o and y (as you indicate) or various probabilistic approaches (e.g. where y and o both have a 50% chance of blocking the arrow).

RogerN June 25, 2009 22:07

Quote:

Originally Posted by d_m (Post 21188)
I can imagine using the current project_path() algorithm but just skipping blockages by walls. I can also imagine either skipping both o and y (as you indicate) or various probabilistic approaches (e.g. where y and o both have a 50% chance of blocking the arrow).

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.

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.

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.

zaimoni June 25, 2009 22:09

Quote:

Originally Posted by RogerN (Post 21189)
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.

V's problem is, in part, because the calculation of projection paths is inflexibly symmetrical (this is where the one-way cover comes from).

d_m June 25, 2009 22:18

Quote:

Originally Posted by RogerN (Post 21189)
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.

Quote:

Originally Posted by RogerN (Post 21189)
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).

Quote:

Originally Posted by RogerN (Post 21189)
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.

takkaria June 25, 2009 22:23

Quote:

Originally Posted by d_m (Post 21191)
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.

d_m June 25, 2009 22:28

Quote:

Originally Posted by takkaria (Post 21192)
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.

Pete Mack June 26, 2009 07:28

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 :D )


EDIT: definitions improved for clarity.
... and completeness, and correctness. (5b was badly wrong. 4c was missing.)

d_m June 26, 2009 13:41

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?

PaulBlay June 26, 2009 13:57

Quote:

Originally Posted by Pete Mack (Post 21202)
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.

... 考え中 ...

Pete Mack June 26, 2009 16:16

Quote:

Originally Posted by d_m (Post 21210)
I will have to start copy-pasting that post to get the set notation ;)

Get them from the source.


Quote:

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
Quote:

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.

Quote:

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

Quote:

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 ofhttp://angband.oook.cz/forum/images/icons/icon13.gif a reasonable model forhttp://angband.oook.cz/forum/images/icons/icon14.gif 1a, 2 and 3. I added it for what I thought was clarity :o . Also, sorry about changing notation (T->TLOS, V->VLOS) midstream. I will fix my original post.

Pete Mack June 26, 2009 16:46

Quote:

Originally Posted by PaulBlay (Post 21211)
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?

PowerDiver June 26, 2009 18:42

Quote:

Originally Posted by aeneas (Post 21181)
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.

Marble Dice June 26, 2009 20:26

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.

PaulBlay June 26, 2009 20:50

Quote:

Originally Posted by Marble Dice (Post 21223)
Eddie, you talkin' about something like this?

Flashback to rogue here.

Quote:

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).

PowerDiver June 26, 2009 21:56

Quote:

Originally Posted by Marble Dice (Post 21223)
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

zaimoni June 27, 2009 01:11

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.)

Pete Mack June 27, 2009 04:21

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!)

PaulBlay June 27, 2009 06:07

Quote:

Originally Posted by Pete Mack (Post 21232)
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.

Pete Mack June 27, 2009 06:28

Quote:

Originally Posted by PaulBlay (Post 21235)
diamond completely blocks view through diagonal gaps.

Code:

#@
M#

@ can't see M.


Ouch. I misunderstood "diamond". I thought it meant that the diamond was a diamond inscribed within the grid, then filled out with a convex hull. In that case, you can't see through:
Code:

@
###
 M

but you can see through:
Code:

#@
M#

There must be some model that satisifies these additional desiderata... [goes looking for a simple geometry program...]

zaimoni June 27, 2009 06:32

Reposting what I just put up on the roguebasin wiki:
Quote:

I proceeded with Zaiband by first simplifying V's base projection algorithm; this stopped hockey pucks as a side effect. Cf. flow.c for end result. [V starts directly emulating fractional steps at the second step. Zaiband does so starting at the first step.]

If there are fixable problems with the initial projection path (offsets directly along an axis or primary diagonal do not admit fixing):
* Check for standard one-off trick shots that anyone can hand-calculate: abs(&Delta;x)==1, abs(&Delta;y)==1, or abs(abs(&Delta;x)-abs(&Delta;y))==1. If they are applicable, use them.
* If no standard one-off trick shot applies, fall back to [Tyrecius'] Permissive Field of View.
** We use rational tangent values as proxies for the actual angles.
** The simplified base projection algorithm admits trivial calculation of the upper and lower rational tangent values for both hitting the target square, and hitting the obstruction. Take the set difference and see if the resulting interval is nonempty.
*** empty: target square is non-projectable.
*** non-empty: use tangent angle summation and half-angle formulae to determine a suitable positional target. Retry the base algorithm. If this path is obstructed, repeat the Permissive Field of View correction.

Zaiband defines visibility as "illumininated, and projectable with a wand/rod of light".

I was pleasantly surprised that this automatic fixup gets all advocated properties except symmetry; the player need never calculate trick shots. Imposing either logical-or symmetry or logical-and symmetry would be a rote change.

PaulBlay June 27, 2009 07:47

Quote:

Originally Posted by Pete Mack (Post 21236)
Ouch. I misunderstood "diamond". I thought it meant that the diamond was a diamond inscribed within the grid, then filled out with a convex hull. In that case, you can't see through:

I think it depends which page of the wiki you're on. :D

The only 'diamonds' in the Discussion:Talk page I put up are the ones you discussed and the ones in section 3.2 (See fig 6).

I think those are different to the diamond algorithm used by libtcod (which I don't know well).

Pete Mack June 27, 2009 08:02

Additional desiderata:

6. Shadows shall not be disconnected. If a single grid wall casts a shadow at a some point, there must exist a (diagonally) connected path of shadow from the wall to the point. (In ordinary parlance: it always becomes easier to hide behind something as you get closer to it.)

6b. Let a, b be two grids which are both in shadow by a column at grid w of grid @. Then there must exist a continuous path from @ to W which is in shadow of both a and b. (This requires a lot more definitions to pose it in set notation, but it's still pretty straightforward.)

I think that 6 & 6b pretty much eliminate all the proposed models but the diamond algorithm applied to diamond (or cylindrical) shaped wall grids. (Model 5a in my earlier post.) I will try to prove it...


BTW:
6 (with diamonds but not with cylinders) implies ASC's will be only partially effective, if monsters are a bit smart:
Code:

##########
#W#D#P# #
##U#R#@# #
##########

Depending on permissiveness, T(D,@), or even T(W,@), but not T(R,@). Cutting down on possibilities, 4a (with diamonds, but not cylinders) is a model for T(D,@), but not for T(W,@).
4b is a model for both T(D,@) and T(W,@), with either diamonds or cylinders.

Pete Mack June 27, 2009 08:18

Additional desiderata:

6. Shadows shall not be disconnected. If a single grid wall casts a shadow at a some point, there must exist a (diagonally) connected path of shadow from the wall to the point. (In ordinary parlance: it always becomes easier to hide behind something as you get closer to it.)

6b. Let a, b be two grids which are both in shadow by a column at grid w of grid @. Then there must exist a continuous path from @ to W which is in shadow of both a and b. (This requires a lot more definitions to pose it in set notation, but it's still pretty straightforward.)

I think that 6 & 6b pretty much eliminate all the proposed models but the diamond algorithm applied to diamond (or cylindrical) shaped wall grids. (Model 5a in my earlier post.) I will try to prove it...


BTW:
6 does not imply that ASC's will work, but only if the monsters are smart:
Code:

##########
#W#D#P# #
##U#R#@# #
##########

Depending on permissiveness, T(D,@), or even T(W,@), but not T(R,@). Cutting down on possibilities, 4a is a model for T(D,@), but not for T(W,@).
4b is a model for both T(D,@) and T(W,@) (and any (10) similarly situated monsters, up to d(M,@) <= 20 spaces away.)

PowerDiver June 27, 2009 17:15

Quote:

Originally Posted by Pete Mack (Post 21241)
Additional desiderata:

6. Shadows shall not be disconnected.

Before you start onto this, let me give a warning. To someone with knowledge of real analysis, disconnected may not mean what you think it means. Unfortunately, I have forgotten too much to say anything specific with any certainty.

I am not saying your (6) is necessarily inherently bad when you define connected the way that any normal person would. However, it is my suspicion that the intuitive definition will lead to strangenesses somewhere else. The mathematics on mappings from a euclidean space to a discrete space can be very very strange.

Pete Mack June 27, 2009 18:55

Yes, I can already see that, because the diamond model is not symmetric. I don't see how to fix it, but that doesn't mean fixing it is impossible. I suspect that forcing symmetry with a permissive combination will solve things. (In that case, there's some maximum length for single-pillar shadows. An unpermissive combination would give weird conical shadows, even at a distance--all very well for the sun and the moon, but doesn't make sense if you consider, say, 1/4 grid size as the diffraction limit.)

zaimoni June 27, 2009 19:18

Quote:

Originally Posted by PowerDiver (Post 21255)
Before you start onto this, let me give a warning. To someone with knowledge of real analysis, disconnected may not mean what you think it means. Unfortunately, I have forgotten too much to say anything specific with any certainty.

I am not saying your (6) is necessarily inherently bad when you define connected the way that any normal person would. However, it is my suspicion that the intuitive definition will lead to strangenesses somewhere else. The mathematics on mappings from a euclidean space to a discrete space can be very very strange.

It needs translation when going into higher mathematics. A simple translation would be "for any given shadowed square, there is another shadowed square with distance one under V's distance function". (After other terms are defined, of course.)

Any non-sophist mathematician reading Pete's description should immediately realize he's not using connected in the technical sense, and should have little problem working up the required translations.

PowerDiver June 27, 2009 20:55

Quote:

Originally Posted by zaimoni (Post 21260)
It needs translation when going into higher mathematics. A simple translation would be "for any given shadowed square, there is another shadowed square with distance one under V's distance function". (After other terms are defined, of course.)

I don't think that is enough. It is not enough to define a topology in the model from scratch. I think you need to look at the topology in the model induced by the topology you start with and the transformation you are using. I think to make a consistent model, you need to enforce that every image in the model of a connected set [in particular a line of sight] remains connected.

Since no one has defined a formal mapping from Euclidean space to any of the models, there is nothing specific to talk about. I don't want to argue about details anyway. I was just warning that things can be a lot more complicated than intuition suggests. What looks like a problem may just be the natural result of consistency when the underlying math is counterintuitive.

I agree that Pete's (6), as he intended it, is a desirable goal, but it may be hard to achieve.

Pete Mack June 27, 2009 21:06

You know, when all is said and done, Angband's definition of projectable and visible, minus the "hockey stick", isn't all that bad... Surely it just needs some tweaking?

PowerDiver June 27, 2009 21:19

You know, I have confused myself now. Why don't you all just laugh at me, and then we can move on and pretend I never said anything about Pete's request about shadows.

PaulBlay June 27, 2009 21:20

Quote:

Originally Posted by Pete Mack (Post 21268)
You know, when all is said and done, Angband's definition of projectable and visible, minus the "hockey stick", isn't all that bad... Surely it just needs some tweaking?

Well how about two tweaks.

1. When a 'project' hits something part way to the targeted grid, check whether the grid hit would be targetable if that grid was the target. That would stop 'trick shots'.

2. Allow Zaiband style flexibility ('diagonal starts') to avoid hitting walls early when not necessary.

Code:

??o
?x#
#x#
@.#

You won't meet many of the 'desired features' but you would get rid of two things that bug me most about the present system.

Nick June 28, 2009 01:01

Quote:

Originally Posted by PowerDiver (Post 21270)
You know, I have confused myself now. Why don't you all just laugh at me, and then we can move on and pretend I never said anything about Pete's request about shadows.

Hey, I've already been laughing at the entire thread. And the other one.

Donald Jonker June 28, 2009 01:19

Quote:

Originally Posted by Nick (Post 21280)
Hey, I've already been laughing at the entire thread. And the other one.

I presume you're also the one laughing at the piles of arrows that stack up around my feet every time it seems I should be able to hit something, but can't. ;)

Been playing solid for over a year + half; that's a long time to still not have an intuitive grasp of the targeting system. I don't think I'm that obtuse. Single biggest thing holding the game back, IMO. And once it's done for V it really should be ported to the variants.

PowerDiver June 28, 2009 01:57

[QUOTE=Marble Dice;21223]Do you no longer feel that DFOV would make LOS very obvious, especially with the highlighting feedback on visible tiles?[QUOTE]

Highlighting would solve issues about what you can target. However, aeneas mentioned a death due to not understanding LOS. Presumably that was about what can target you *after* you move, and I'm not sure how to make highlighting solve that problem.

Nick June 28, 2009 02:42

Quote:

Originally Posted by Donald Jonker (Post 21281)
I presume you're also the one laughing at the piles of arrows that stack up around my feet every time it seems I should be able to hit something, but can't. ;)

Been playing solid for over a year + half; that's a long time to still not have an intuitive grasp of the targeting system. I don't think I'm that obtuse. Single biggest thing holding the game back, IMO. And once it's done for V it really should be ported to the variants.

Well, it's kind of hysterical laughter.

In fact, I think I'd like to conjecture that this is like voting systems - you make a few simple assumptions about what an ideal one should be, and that results in a contradiction. While this seems bad, it's in fact very freeing - once you know perfection is impossible, you just go with what feels least bad.

So I'm kind of taking the view that hockey stick abuse and trick shots are less than ideal, but better the devil you know. And targetting tells you what you can target, so there shouldn't be a problem with trying to target things you can't hit. Especially if V implements the NPP displayed-path-to-target.


All times are GMT +1. The time now is 07:35.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.