Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Vanilla

Reply
 
Thread Tools Display Modes
Old June 26, 2009, 21:50   #41
PaulBlay
Knight
 
Join Date: Jan 2009
Posts: 657
PaulBlay is on a distinguished road
Quote:
Originally Posted by Marble Dice View Post
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).
__________________
Currently turning (Angband) Japanese.
PaulBlay is offline   Reply With Quote
Old June 26, 2009, 22:56   #42
PowerDiver
Prophet
 
Join Date: Mar 2008
Posts: 2,712
PowerDiver is on a distinguished road
Quote:
Originally Posted by Marble Dice View Post
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
PowerDiver is offline   Reply With Quote
Old June 27, 2009, 02:11   #43
zaimoni
Knight
 
zaimoni's Avatar
 
Join Date: Apr 2007
Posts: 590
zaimoni is on a distinguished road
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.)
zaimoni is offline   Reply With Quote
Old June 27, 2009, 05:21   #44
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 5,414
Donated: $40
Pete Mack is on a distinguished road
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!)
Pete Mack is offline   Reply With Quote
Old June 27, 2009, 07:07   #45
PaulBlay
Knight
 
Join Date: Jan 2009
Posts: 657
PaulBlay is on a distinguished road
Quote:
Originally Posted by Pete Mack View Post
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.
__________________
Currently turning (Angband) Japanese.
PaulBlay is offline   Reply With Quote
Old June 27, 2009, 07:28   #46
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 5,414
Donated: $40
Pete Mack is on a distinguished road
Quote:
Originally Posted by PaulBlay View Post
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...]
Pete Mack is offline   Reply With Quote
Old June 27, 2009, 07:32   #47
zaimoni
Knight
 
zaimoni's Avatar
 
Join Date: Apr 2007
Posts: 590
zaimoni is on a distinguished road
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(Δx)==1, abs(Δy)==1, or abs(abs(Δx)-abs(Δ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.
zaimoni is offline   Reply With Quote
Old June 27, 2009, 08:47   #48
PaulBlay
Knight
 
Join Date: Jan 2009
Posts: 657
PaulBlay is on a distinguished road
Quote:
Originally Posted by Pete Mack View Post
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.

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).
__________________
Currently turning (Angband) Japanese.
PaulBlay is offline   Reply With Quote
Old June 27, 2009, 09:02   #49
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 5,414
Donated: $40
Pete Mack is on a distinguished road
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.

Last edited by Pete Mack; June 27, 2009 at 09:08.
Pete Mack is offline   Reply With Quote
Old June 27, 2009, 09:18   #50
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 5,414
Donated: $40
Pete Mack is on a distinguished road
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.)
Pete Mack 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 6, 2009 00:02
feature request - disturb on reverse LOS PowerDiver Vanilla 2 May 18, 2009 07:46
Angband User Manual Wiki JamesDoyle Oook! 31 February 7, 2008 01:25
Angband Wiki K.I.L.E.R Oook! 7 June 4, 2007 09:48
I need a forum for non-variant specific development discussion CJNyfalt Oook! 6 May 19, 2007 01:16


All times are GMT +1. The time now is 04:45.


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