Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Vanilla

Reply
 
Thread Tools Display Modes
Old June 25, 2009, 21:22   #21
d_m
Angband Devteam member
 
d_m's Avatar
 
Join Date: Aug 2008
Location: Philadelphia, PA, USA
Age: 39
Posts: 1,516
d_m is on a distinguished road
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.
d_m is offline   Reply With Quote
Old June 25, 2009, 21:22   #22
aeneas
Adept
 
Join Date: Jun 2007
Location: The place of virtuous unbelievers
Posts: 158
aeneas is on a distinguished road
Quote:
Originally Posted by PowerDiver View Post
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.
aeneas is offline   Reply With Quote
Old June 25, 2009, 21:26   #23
PaulBlay
Knight
 
Join Date: Jan 2009
Posts: 657
PaulBlay is on a distinguished road
Quote:
Originally Posted by d_m View Post
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).
__________________
Currently turning (Angband) Japanese.
PaulBlay is offline   Reply With Quote
Old June 25, 2009, 21:26   #24
RogerN
Swordsman
 
RogerN's Avatar
 
Join Date: Jul 2008
Posts: 308
RogerN is on a distinguished road
Quote:
Originally Posted by PaulBlay View Post
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...
RogerN is offline   Reply With Quote
Old June 25, 2009, 21:31   #25
PaulBlay
Knight
 
Join Date: Jan 2009
Posts: 657
PaulBlay is on a distinguished road
Quote:
Originally Posted by RogerN View Post
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.
Attached Thumbnails
Click image for larger version

Name:	geometry.jpg
Views:	110
Size:	17.1 KB
ID:	221  
__________________
Currently turning (Angband) Japanese.
PaulBlay is offline   Reply With Quote
Old June 25, 2009, 21:43   #26
zaimoni
Knight
 
zaimoni's Avatar
 
Join Date: Apr 2007
Posts: 590
zaimoni is on a distinguished road
Quote:
Originally Posted by d_m View Post
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.
zaimoni is offline   Reply With Quote
Old June 25, 2009, 21:45   #27
RogerN
Swordsman
 
RogerN's Avatar
 
Join Date: Jul 2008
Posts: 308
RogerN is on a distinguished road
Yet another diagram, demonstrating that the LOS does not touch the corners of any intervening diamonds:

RogerN is offline   Reply With Quote
Old June 25, 2009, 21:50   #28
d_m
Angband Devteam member
 
d_m's Avatar
 
Join Date: Aug 2008
Location: Philadelphia, PA, USA
Age: 39
Posts: 1,516
d_m is on a distinguished road
Quote:
Originally Posted by zaimoni View Post
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).
d_m is offline   Reply With Quote
Old June 25, 2009, 22:07   #29
RogerN
Swordsman
 
RogerN's Avatar
 
Join Date: Jul 2008
Posts: 308
RogerN is on a distinguished road
Quote:
Originally Posted by d_m View Post
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.
RogerN is offline   Reply With Quote
Old June 25, 2009, 22:09   #30
zaimoni
Knight
 
zaimoni's Avatar
 
Join Date: Apr 2007
Posts: 590
zaimoni is on a distinguished road
Quote:
Originally Posted by RogerN View Post
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).
zaimoni is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
targetting and LOS PowerDiver Vanilla 187 July 5, 2009 23:02
feature request - disturb on reverse LOS PowerDiver Vanilla 2 May 18, 2009 06:46
Angband User Manual Wiki JamesDoyle Oook! 31 February 7, 2008 00:25
Angband Wiki K.I.L.E.R Oook! 7 June 4, 2007 08:48
I need a forum for non-variant specific development discussion CJNyfalt Oook! 6 May 19, 2007 00:16


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


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