Square LOS
Numeron
future if it happens at all, this feature request in the crawl mantis
thing has caught my eye. Id like to bring it over into rgrd to see
what people think of it, not just in terms of DCSS, but how we
possibly should be looking at our own games in the same light.
https://crawl.develz.org/mantis/view.php?id=1642
and also briefly touched on here:
https://crawl.develz.org/mantis/view.php?id=1716
Change the players FOV into a square to solve many ranged spell/abiliy
problems, and monster approaching distance irregularities at the cost
of aesthetics. Is it worth it?
-Numeron
David Ploog
> Change the players FOV into a square to solve many ranged spell/abiliy
> problems, and monster approaching distance irregularities at the cost
> of aesthetics. Is it worth it?
Assuming diagonal movement and free targeting (as in Crawl), there is a
conflict between spell ranges (counted in grids) and Euclidean (i.e.
circular) FOV. This allows to abuse the inconsistency by targeting
monsters out of sight using diagonals.
One approach (and the one implemented in DCSS Trunk) is to use Euclidean
distance for ranges. This solves the above abuse, but leaves the issue
that diagonal movements can still lead to odd behaviour w.r.t sighting.
The tremendous advantage of the square LOS approach is that it attacks the
problem at the root: instead of using two different metrics (Euclid for
sight, steps for ranges), you would use only one (steps). I believe this
is worth the change, and I don't believe that aesthetics would be harmed
much. But this is a subjective notion, and not pressing enough to quarrel
about it among developers, at least at this stage.
David
Pender
This introduces (or highlights) inconsistencies of its own. With a
square FOV, there are a lot of optimal routes to a midpoint of one of
the four edges, whereas there is only one to each of the four corners.
Nor is this an inconsequential inconsistency. For example, it's easier
to obstruct a PC or NPC who is trying to travel diagonally than one
trying to travel horizontally. Circular FOV at least minimizes the
extent of the inconsistency. As another example, a gas simulator in
which the quantity of gas in a given cell at time T is computed as the
average of the gas quantities in the nine-cell neighborhood at time
T-1 will cause an infusion of gas to expand in a circular cloud if
unobstructed -- even though that means that some edges of the cloud
are "closer" to the center than others. One more example: most
cellular automata algorithms will produce rounded shapes, even though
that means they are basically imputing the same cost to diagonal
movement that an artificially circular FOV algorithm does. The "root
of the problem" is not that two different metrics for distance are
employed -- because they're not. The root of the problem is that
roguelike diagonal movement is as cheap as horizontal or vertical
movement.
The fact is that Roguelike space is weird and inconsistent with our
intuitions about how space should behave. The inconsistencies are
inevitable when the space is discrete instead of continuous, when
movement is in four directions instead of more, and when traveling
diagonally has the same cost as traveling horizontally or vertically.
The solution you have employed disguises one symptom of these
inconsistencies at the cost of making another symptom much more
obvious, and I think you should use it only if the specific gameplay
problem you're addressing is substantial and too difficult to solve by
any less obvious means. And I think -- admittedly without a ton of
empirical support -- that it's unlikely that such a noticeably odd-
looking solution was the best from the typical player's perspective
relative to other solutions you could have deployed that were more
closely tailored to the specific problem you were addressing.
Because... square FOV is so ugly!
David Damerell
>Change the players FOV into a square to solve many ranged spell/abiliy
>problems, and monster approaching distance irregularities at the cost
>of aesthetics. Is it worth it?
It just looks so utterly horrible, though.
I've been experimenting with an octagonal LOS shape:
.....
.......
]........
.........
....@]..#
........G
...#.....
.# ....
...
[Squares explored but not currently in LOS elided. Also, yeah, that pillar
south of the player blocks a wide area. In the development version pillars
are narrower than one full square.]
This seems a reasonable compromise between seeing less far down diagonals
and the desire for a roundish shape. At large LOS radiuses the corners
need only have relatively few squares trimmed off them, so the octagon has
fewer "missing" squares than a circle. It's also easy to implement!
--
David Damerell <dame...@chiark.greenend.org.uk>
Clown shoes. I hope that doesn't bother you.
Today is First Stilday, June - a weekend.
Tomorrow will be Gorgonzoladay, June - a weekend.
Pender
wrote:
> This seems a reasonable compromise between seeing less far down diagonals
> and the desire for a roundish shape. At large LOS radiuses the corners
> need only have relatively few squares trimmed off them, so the octagon has
> fewer "missing" squares than a circle. It's also easy to implement!
Marginally fewer, but it takes the same number of steps to reach the
edge of the octagon at a 45-degree diagonal as it does on a circle.
David Damerell
>On Jun 11, 12:21=A0pm, David Damerell <damer...@chiark.greenend.org.uk>
>>This seems a reasonable compromise between seeing less far down diagonals
>>and the desire for a roundish shape. At large LOS radiuses the corners
>>need only have relatively few squares trimmed off them, so the octagon has
>>fewer "missing" squares than a circle. It's also easy to implement!
>Marginally fewer, but it takes the same number of steps to reach the
>edge of the octagon at a 45-degree diagonal as it does on a circle.
That is only true if it's a regular octagon. As mentioned, you can make
the diagonal sides shorter and it still looks better than square LOS.
Numeron
> The root of the problem is that roguelike diagonal
> movement is as cheap as horizontal or vertical movement.
Not saying that you suggested doing so, but directly addressing this
issue is not a good idea. I usually see at least one person have a
crack at giving diagonal movement a cost multiplier of 1.41 to some
personal project, around once a year. It plays very poorly, and is
unintuative for the behaviour of movement on a grid. Then take into
account attack costs, activation costs (doors for example), and you
have yourself a mess of what should cost more and what shouldnt - and
that does make a difference when you are being hit by something next
to you.
> Because... square FOV is so ugly!
It is possible however for it to be entirely unnoticable at the cost
of fixing the map view to the size of the square. Say you have a FOV
diameter of 17 tiles (as Crawl does), multiplied by 32 means that if
the view of the world is locked to 544x544 pixels then instead of an
obvious square FOV overlayed on the map, you instead just see
everything on the map (unless directly obstructed). This however is
problematic not just because you cant "see" beyond your own FOV
without moving there, but also possibly disasterous for the set up of
the interface, especially given that locking the size of the map would
make the program window shrink, and lose its ability to be resized.
-Numeron
Ray
> On Jun 12, 1:18 am, Pender <penderpr...@gmail.com> wrote:
>> The root of the problem is that roguelike diagonal
>> movement is as cheap as horizontal or vertical movement.
> Not saying that you suggested doing so, but directly addressing this
> issue is not a good idea. I usually see at least one person have a
> crack at giving diagonal movement a cost multiplier of 1.41 to some
> personal project, around once a year. It plays very poorly, and is
> unintuative for the behaviour of movement on a grid.
IMO differential cost for diagonal movement is probably the best
solution, but that's just to say that my "intuition" about
movement considers the gridly nature of the simulated space
secondary, at most, to the amount of real, ie, euclidean,
distance covered by a given movement. That is, I can see that
the diagonal step is further, and therefore I *expect* it to
take longer. I see that a monster approaching on the diagonal
is coming to me across the same distance as one approaching on
the orthogonal, and I *expect* it to take the same amount of
time so I have the same number of chances to shoot at it, even
though it's a smaller number of steps.
There are still inconsistencies, but the worst of them get less
important as the sight radius gets larger. A small sight radius
makes all types of inconsistencies worse, and if you have a
claustrophobic 2-radius or 3-radius, then number of actions
between first appearance and meelee range gets to be more
important. Since meelee range is longer on diagonals, the
consistency is proportionately worse.
What differential movement cost does bugger up, if your timing
system is so simplistic as to allow it in the first place, is
your ability to count turns in advance, chess-style. In
roguelikes this is what allows classic tactics like pillar
dancing and hack-and-back. But a timing system that allows
that kind of tactic in the first place is limited and
disappointing IMO, and the tactics themselves seem borderline-
abusive to me, so I don't thing preserving that kind of tactic
is worthwhile.
Bear
Numeron
> What differential movement cost does bugger up, if your timing
> system is so simplistic as to allow it in the first place, is
> your ability to count turns in advance, chess-style. In
> roguelikes this is what allows classic tactics like pillar
> dancing and hack-and-back. But a timing system that allows
> that kind of tactic in the first place is limited and
> disappointing IMO, and the tactics themselves seem borderline-
> abusive to me, so I don't thing preserving that kind of tactic
> is worthwhile.
This is what I was referring to when I said that its unintuative -
being able to count moves ahead to plan your way out of a hairy
situation is what gives roguelikes thier tacticalness. I want to know
if I will make it to a safe passage a distance to my diagonal before
that other monster heading orthagonally will reach me, but with
modified costs its mostly guesswork. Pillar dancing and hack-and-back
(good name for it) are still possible anyway, just as long as you keep
using the same direction type every time - for example you can still
count steps when dancing around a single point pillar because every
turn you and your chaser take always costs the same, being always
diagonal.
-Numeron
Kenneth 'Bessarion' Boyd
> Numeron wrote:
> > On Jun 12, 1:18 am, Pender <penderpr...@gmail.com> wrote:
> >> The root of the problem is that roguelike diagonal
> >> movement is as cheap as horizontal or vertical movement.
> > Not saying that you suggested doing so, but directly addressing this
> > issue is not a good idea. I usually see at least one person have a
> > crack at giving diagonal movement a cost multiplier of 1.41 to some
> > personal project, around once a year. It plays very poorly, and is
> > unintuative for the behaviour of movement on a grid.
>
> IMO differential cost for diagonal movement is probably the best
> solution, but that's just to say that my "intuition" about
> movement considers the gridly nature of the simulated space
> secondary, at most, to the amount of real, ie, euclidean,
>
> What differential movement cost does bugger up, if your timing
> system is so simplistic as to allow it in the first place, is
> your ability to count turns in advance, chess-style.
Not if you know it's coming. (Verified with Zaiband; movement cost
150 for diagonals, 100 for orthogonal moves).
I won't rule out making it harder to *induct* what's going on.
Gerry Quinn
@t34g2000prd.googlegroups.com>, irunsofastine...@hotmail.com
says...
> On Jun 12, 1:18 am, Pender <penderpr...@gmail.com> wrote: you.
>
> > Because... square FOV is so ugly!
I agree.
> It is possible however for it to be entirely unnoticable at the cost
> of fixing the map view to the size of the square. Say you have a FOV
> diameter of 17 tiles (as Crawl does), multiplied by 32 means that if
> the view of the world is locked to 544x544 pixels then instead of an
> obvious square FOV overlayed on the map, you instead just see
> everything on the map (unless directly obstructed). This however is
> problematic not just because you cant "see" beyond your own FOV
> without moving there, but also possibly disasterous for the set up of
> the interface, especially given that locking the size of the map would
> make the program window shrink, and lose its ability to be resized.
I was about to make the same point (it applies to my game Lair of the
Demon Ape which has a vision radius of 9 and a 19x19 viewport). I
think the points you make not likely to be too serios.
In the first place you can 'see' beyond the range of the map by the use
of a mini-map, or an option to scroll the viewport without moving (both
Lair and Crawl have this).
As for the user interface, you certainly can't reasonably use this
option with a variable light radius. But resizing can be implemented
by stretching or replacing the graphic tiles, and in the long term you
would want this option when doing major resizing anyway because this is
probably a response to excessively high monitore resolution.
There is however another issue distinct from LOS, and this is the range
of weapons or spells. Making every ranged effect able to hit anything
in the viewport has to be bad or at least very limiting, I think.
Small light ranges, by contrast, are cute and traditional - but their
absence does not take away a whole lot of gameplay options.
Crawl shows the tiles in range as brighter when a ranged weapon is
wielded or a ranged spell initiated. And for this it uses a circle,
i.e. circle aesthethics trump geometric consistency. In Lair I used a
square, but there is no highlighting.
I think you could get away with square highlighting if it were in a
very subtle form, e.g. gridlines in a different colour about the range.
But if you light up the squares as in Crawl I believe a circle is the
best option.
Exploitable quirks are in the nature of roguelikes. Don't fight it.
Welcome and control it.
- Gerry Quinn
Martin Read
>The root of the problem is that roguelike diagonal movement is as
>cheap as horizontal or vertical movement.
Actually, the root of the problem is that on his turn, the Rogue can
walk, kick ass, or chew gum, but he can't do more than one of those
things even if they are things that you _ought_ to be able to do
simultaneously.
--
\_\/_/ turbulence is certainty turbulence is friction between you and me
\ / every time we try to impose order we create chaos
\/ -- Killing Joke, "Mathematics of Chaos"
Mike Blackney
> [snip]
> Change the players FOV into a square to solve many ranged spell/abiliy
> problems, and monster approaching distance irregularities at the cost
> of aesthetics. Is it worth it?
I personally think so, but I agree that it looks terrible.
Something I did way back in Abura Tan was to make the generic terrain
visibility use a circle, but monster and special tile visibility is
square-based.
So you might see something like this:
#...
#.....
#####......
........T..
...........
.............
......@......
.............
..%......a.
...........T
.........TT
% ....... T
...
I think it worked really well.
--
mike blackney
mi...@mikeblackney.com
Grillen Verboten!