Viewing Issue Simple Details Jump to Notes ] Wiki ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0002250 [DCSS] FR: Gameplay Balancing minor have not tried 2010-08-10 15:13 2010-09-07 14:19
Reporter Lemuel View Status public  
Assigned To rob
Priority normal Resolution suspended  
Status resolved   Product Branch 0.8 ancient branch
Summary 0002250: Let's test out square LOS
Description There are some people (like me) who think square LOS and square ranges would be the best way to make them consistent, since everything else in Crawl (most importantly movement) happens on a square grid. There are other people who think a square field of view would be hopeless unaesthetic.

It's hard to settle this question in the abstract. So it seems like we should test it out. Why not create a version with square LOS and square ranges and put it on CDO for people to play for a while? Then the Devs could make a more informed decision.
Additional Information
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0007060)
doy (developer)
2010-08-10 16:51

+1. We could really even just do this directly on trunk and leave it up on cdo for a few days... can always be reverted pretty easily if people don't like it, and that would give it a much wider range of people trying it (other than people who have most likely already made up their minds about it).
(0007061)
dolorous (updater)
2010-08-10 19:20

+1
(0007062)
Cryptic (developer)
2010-08-10 19:25

+1 certainly can't hurt, though after tourney, for wider audience?
(0007064)
Timbermaw (reporter)
2010-08-10 19:48

+1
(0007067)
Porkchop (reporter)
2010-08-10 19:56

test after tourney ^^^ for sure.
(0007098)
evilmike (developer)
2010-08-11 12:34

+1

This is something I'd love to try out. I've always thought that square LOS (and ranges, and so on) would make a lot of sense from a gameplay perspective. It would also be a great way to get feedback from people who don't have an opinion on the matter.

Even if the change is just put in temporarily at first, it's a great way to test the waters for a potentially radical change. It it fails, no harm done.
(0007099)
due (developer)
2010-08-11 13:06

-1. Squares are ugly.
(0007100)
KiloByte (manager)
2010-08-11 13:11

-1. Just draw a mockups of how things would like... and the comparison of diagonal moves on square vs circular LOS has been repeated over and over. With square, you can just rip the orthogonal keys from your keyboard and be done with it.
(0007103)
OG17 (reporter)
2010-08-11 14:34

Why do you still think that?
(0007104)
Nobody (reporter)
2010-08-11 14:38

+1. Surely it's at least worth trying?
(0007107)
Core Xii (reporter)
2010-08-11 16:39

+1

Playing the aesthetics argument on a roguelike is a moot point. It's a game that focuses on gameplay, not presentation. Square LOS improves gameplay, aesthetics come second.
(0007114)
dpeg (administrator)
2010-08-11 18:18

I never wanted to push the issue much but now it seems to have got a life of its own. If someone wants to make a square LOS branch, I'd suggest to follow rob's proposal of shrinking LOS length to 7 (instead of the current 8), so that the total number of seen squares stays approximately the same.
(0007124)
MrMisterMonkey (reporter)
2010-08-11 19:55
edited on: 2010-08-11 19:55

+1; squares are prettier than chunky circles, anyway, and more consistent with the square grid, etc.

(0007125)
OG17 (reporter)
2010-08-11 20:02

Instead of immediately reducing LOS length, it'd be better to begin by squaring the current viewport and leaving the rest alone. That'd demonstrate square LOS without bundling it with other avoidable gameplay changes - reducing LOS distance would significantly affect spell ranges, for example, which would need to be individually adjusted, creating a balance issue in itself. One of the draws of square LOS is how you can just drop it into the game and watch everything else fall right into place - if the greater view area ends up being a problem, it can always be addressed later, but this should be started simply.
(0007128)
minmay (reporter)
2010-08-11 22:02

+1, circular LOS has always been one of the things in Crawl that "just bothers me."
(0007129)
neunon (developer)
2010-08-11 22:13
edited on: 2010-08-11 22:13

-1. Circular line-of-sight is far more logical than square LOS. Just take a few seconds to consider how real-life LOS sight works, which is what we're basically trying to emulate.

The only advantage to square LOS may be processing time, as it'd be easier to calculate. But I don't perceive it as worthwhile.

(0007130)
MrMisterMonkey (reporter)
2010-08-11 22:57

Real life uses euclidean space, not chessboard.
(0007131)
Krishh (reporter)
2010-08-11 22:58

+1. Aesthetics should reinforce gameplay, not the other way around. And Crawl is one of the last roguelikes I'd go to if I wanted one emulating reality.
(0007132)
nrook (updater)
2010-08-11 23:06

+1. I personally like the idea, and practically speaking it seems to have a well of support, so it might as well be tried.
(0007133)
elliptic (developer)
2010-08-12 03:04

+1. I don't think that it is possible to tell what a change like this would really feel like without trying it out, and the current circles do feel strange to me, so...
(0007134)
TGW (reporter)
2010-08-12 03:17
edited on: 2010-08-12 03:22

neunon: I'm not sure if you were around to witness the other Mantis issues on the topic, but the main things square LOS/range fixes are that stealth is easier when moving diagonally and that approaching enemies spend far fewer turns in range when coming at you from a diagonal (LCS only reaches two squares diagonally, I think, and reaching brand doesn't work at all on diagonals).

Square LOS and range fixes these gameplay issues with dramatically less collateral damage than a diagonal movement cost of sqrt(2) or whatever the other solution is.

(0007135)
mageykun (reporter)
2010-08-12 03:22

-1

Having to spend one less turn mapping out a corner outside of LOS is not worth allowing more enemies target me at once in scary areas like the tomb. Who cares about aesthetics or logic, I just don't want to be smote to death faster.
(0007136)
Core Xii (reporter)
2010-08-12 04:09

mageykun that's merely a balance issue to be fixed afterwards. Does not warrant a fundamental improvement to go unimplemented.
(0007137)
Lemuel (updater)
2010-08-12 07:42

mageykun: The proposal is not to implement square LOS. It's to test it out, so we can see how serious issues like the one you raise are in practice.
(0007337)
jpeg (manager)
2010-08-18 15:55

+1. For short range spells (Flame Tongue etc.) the impact of losing 1 cell due to euclidian rounding is enormous, esp. at low power == in the early game, so I'd like to at least try the alternative.
(0007338)
KiloByte (manager)
2010-08-18 16:06

jpeg: and tell me, where exactly short range spells lose 1 cell? Let's see at the table of distances of ranges up to 3:

18 13 10 9 10 13 18
13 8 5 4 5 8 13
10 5 2 1 2 5 10
 9 4 1 * 1 4 9
10 5 2 1 2 5 10
13 8 5 4 5 8 13
18 13 19 9 10 13 18

As you can see, at very short range, every Chebyshev distance can be emulated with Eulidean ones but not the other way, making Euclidean strictly better. You want to emulate Chebyshev distance of 1? Use Euclidean sqrt(2). Want to emulate Chebyshev of 2? Use Euclidean sqrt(8).

Thus, what you said is a strong argument AGAINST square LOS, since square allows less flexibility here.
(0007344)
OG17 (reporter)
2010-08-18 18:16

If the game used proper ranges in the first place, there'd be no need to "flexibly" beat spells into some semblance of functionality, as they would already work. A system that's "strictly better" at inconsistently hiding its innate hopeless flaws isn't actually preferable to one that's without them - chebyshev distances being unable to emulate a euclidean system is a nonsensical objection, as euclidean distances will never be remotely appropriate for this grid-based game.
(0007350)
jpeg (manager)
2010-08-18 21:36

Sorry, KiloByte, I've no idea what your image is supposed to show me.

I'm talking about Flame Tongue having a starting range of 2 for a DEFE (according to the spell screen) but diagonally the range is only 1.
While the same shortening must also apply to longer-range spells (e.g. Magic Dart, Mephitic Cloud), I haven't actually noticed - presumably because for a long distance it doesn't matter so much, whereas in practice the difference between adjacent and 2 squares away feels much bigger.
(0007351)
Nobody (reporter)
2010-08-18 22:54

I feel like a tool for quoting myself, but it seems to be relevant here.

https://crawl.develz.org/mantis/file_download.php?file_id=674&type=bug [^]

Assumes round LoS and compares square ranges against round. For details, see comment 5819 in FR 0001716.
(0007365)
KiloByte (manager)
2010-08-19 10:02

jpeg: Flame Tongue having a range^2 of 5 where you want 8 is not an effect of circular LOS -- heck, it already is different than 4. Making it 8 is not a problem, it's merely a matter of choice.
(0007373)
OG17 (reporter)
2010-08-19 12:34

Kilobyte, the way you're juggling LOS and ranges is incredibly disingenuous. Is this intentional? Jpeg wants to try square LOS because of its accompanying square ranges - claiming that truncated diagonal ranges aren't an effect of circular LOS is laughable, unless you're suggesting a return to the mixed .6 system.

I'll admit that a "euclidean" system where every distance was dressed up to be identical to its chebyshevian counterpart would work pretty well, though!
(0007375)
KiloByte (manager)
2010-08-19 13:03

OG17: 2 < sqrt(5) < sqrt(8) < 3
How is exactly that "dressing up"? It's basic math.
If you don't like sqrt(5) like jpeg doesn't, pick sqrt(8) -- it's as valid a choice as any other.
(0007388)
Lemuel (updater)
2010-08-19 17:06

Kilobyte,

You are right that spell ranges could have been adjusted when you switched to Euclidean distances in such a way that the range of Flame Tongue, reaching weapons, etc., was not reduced. But of course they weren't adjusted, leading to the problem Jppeg is pointing to.

This just points out, again, that the switch to Euclidean distances for spell ranges in the context of a game played on a square grid has a lot of implications that have to be thought through. Which, in turn, is an argument for trying to fix the problems of the old system in a way that does not open such a big can of worms.

My question for you, though, is this: why are you against even trying square LOS as an experiment? If it's as bad as you expect it to be, don't you think people will see that and prefer your approach? And conversely, isn't it at least possible that you won't find it as ugly in practice as you do in theory?
(0008029)
minmay (reporter)
2010-09-06 18:40

Now that the tournament is over, can we try this out?
(0008037)
StudioMK (reporter)
2010-09-06 20:32
edited on: 2010-09-06 20:32

+1 for squares. Because my screen is square and so is my console, so why isn't me LOS sqwarred too.

(0008050)
KiloByte (manager)
2010-09-06 22:39

Based on what the real complaints were, I'd test actual Euclidean first.
(0008053)
OG17 (reporter)
2010-09-06 23:12

You don't mean making diagonal steps take longer than cardinal ones, do you?
(0008054)
KiloByte (manager)
2010-09-06 23:30

At least:
1. fixing short-range spells
2. removing stealth boost for moving diagonally

These are non-disruptive.
(0008061)
elliptic (developer)
2010-09-07 03:39

KiloByte: I don't know what you think the "real complaints" were, but the largest issue with circular LoS/range is simply that you get more turns in range/LoS of something if you approach horizontally/vertically than if you approach diagonally. This usually has nothing to do with stealth; it has a large effect on the optimal strategy whenever either you or the monster has any ranged attacks or spells at all. I haven't heard a single suggestion to address this flaw other than making diagonal steps take longer than cardinal ones (which has even larger issues itself of course).

Your problem is that "actual Euclidean" is complete nonsense so long as movement isn't Euclidean.
(0008063)
Lemuel (updater)
2010-09-07 05:25

elliptic is right, I think: As long as movement is on a square grid, there will be serious inconsistencies with range and LoS on a Euclidean grid.

"Removing stealth boosts" makes movement Euclidean one purpose, but not for others. By itself, this seems like a bit of a hack -- why should a diagonal step count as 1.4 times a cardinal step for purposes of stealth, but not for food use, monster actions, etc. But partly-Euclidean movement makes perfect sense as a first step toward putting movement completely on the Euclidean grid.

Maybe that's is where the DevTeam wants to end up. If that's the consensus among developers, fine, I'm not going to argue. But if developers are not sure which way they want to go, then it would seem logical to test out *both* Kilobyte's preferred steps, and a square LoS. Of course, that depends on whether there is a coder who wants to write a square LoS. Is there?

EDIT: Also, if you do want to move in the Euclidean direction, another priority should be fixing the AI so it understands how the two grids interact. E.g.

.........
.@.....12
.......34

If there is a fleeing monster at 1, it should prefer moving to 4 rather than 2, since that is more likely to put it out of range of spells. Similarly for a monster without ranged attacks at 4: It should prefer moving to 3 rather than 1. On the other hand, an orc wizard (say) at 4 should prefer moving to 1 rather than 3, since that's more likely to get it into range. Right now, the player uses moves like these to take advantage of the inconsistencies between the two grids, so monsters should too.

Or we could get rid of the inconsistencies, by going to either square LoS or Euclidean movement.
(0008066)
OG17 (reporter)
2010-09-07 05:57

It's hard to imagine euclidean being successful, as human beings simply don't think in this manner when presented with a grid. It's an unintuitive abstraction of what a square does clearly and directly.
(0008070)
b0rsuk (updater)
2010-09-07 06:51
edited on: 2010-09-07 06:52

+1
I think square LOS is very natural for a roguelike which allows diagonal movement. There's no escaping squares and associated gameplay artifacts even if you make diagonal movement cost more. In any case, it can't hurt to *try*, right ? Let's see what the feedback is, perhaps SA forums won't implode.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Square LOS would clearly communicate the one unintuitive part of Crawl movement. It's like a statement "Squares are limited, we know it, and you should know it too".
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

(0008078)
rob (developer)
2010-09-07 14:19

I've written up some details on square LOS including details on what would need to be done code-wise at https://crawl.develz.org/wiki/doku.php?id=dcss:brainstorm:square_los [^] . Feel free to help with that page.

- Issue History
Date Modified Username Field Change
2010-08-10 15:13 Lemuel New Issue
2010-08-10 16:51 doy Note Added: 0007060
2010-08-10 19:20 dolorous Note Added: 0007061
2010-08-10 19:25 Cryptic Note Added: 0007062
2010-08-10 19:48 Timbermaw Note Added: 0007064
2010-08-10 19:56 Porkchop Note Added: 0007067
2010-08-11 12:34 evilmike Note Added: 0007098
2010-08-11 13:06 due Note Added: 0007099
2010-08-11 13:11 KiloByte Note Added: 0007100
2010-08-11 14:34 OG17 Note Added: 0007103
2010-08-11 14:38 Nobody Note Added: 0007104
2010-08-11 16:39 Core Xii Note Added: 0007107
2010-08-11 18:18 dpeg Note Added: 0007114
2010-08-11 19:55 MrMisterMonkey Note Added: 0007124
2010-08-11 19:55 MrMisterMonkey Note Edited: 0007124
2010-08-11 20:02 OG17 Note Added: 0007125
2010-08-11 22:02 minmay Note Added: 0007128
2010-08-11 22:13 neunon Note Added: 0007129
2010-08-11 22:13 neunon Note Edited: 0007129
2010-08-11 22:57 MrMisterMonkey Note Added: 0007130
2010-08-11 22:58 Krishh Note Added: 0007131
2010-08-11 23:06 nrook Note Added: 0007132
2010-08-12 03:04 elliptic Note Added: 0007133
2010-08-12 03:17 TGW Note Added: 0007134
2010-08-12 03:19 TGW Note Edited: 0007134
2010-08-12 03:21 TGW Note Edited: 0007134
2010-08-12 03:22 TGW Note Edited: 0007134
2010-08-12 03:22 mageykun Note Added: 0007135
2010-08-12 04:09 Core Xii Note Added: 0007136
2010-08-12 07:42 Lemuel Note Added: 0007137
2010-08-18 15:55 jpeg Note Added: 0007337
2010-08-18 16:06 KiloByte Note Added: 0007338
2010-08-18 18:16 OG17 Note Added: 0007344
2010-08-18 21:36 jpeg Note Added: 0007350
2010-08-18 22:54 Nobody Note Added: 0007351
2010-08-19 10:02 KiloByte Note Added: 0007365
2010-08-19 12:34 OG17 Note Added: 0007373
2010-08-19 13:03 KiloByte Note Added: 0007375
2010-08-19 17:06 Lemuel Note Added: 0007388
2010-09-06 18:40 minmay Note Added: 0008029
2010-09-06 20:32 StudioMK Note Added: 0008037
2010-09-06 20:32 StudioMK Note Edited: 0008037
2010-09-06 20:32 StudioMK Note Edited: 0008037
2010-09-06 22:39 KiloByte Note Added: 0008050
2010-09-06 23:12 OG17 Note Added: 0008053
2010-09-06 23:30 KiloByte Note Added: 0008054
2010-09-07 03:39 elliptic Note Added: 0008061
2010-09-07 05:25 Lemuel Note Added: 0008063
2010-09-07 05:57 OG17 Note Added: 0008066
2010-09-07 06:51 b0rsuk Note Added: 0008070
2010-09-07 06:52 b0rsuk Note Edited: 0008070
2010-09-07 14:19 rob Note Added: 0008078
2010-09-07 14:19 rob Status new => resolved
2010-09-07 14:19 rob Fixed in Branch => 0.8 development branch
2010-09-07 14:19 rob Resolution open => suspended
2010-09-07 14:19 rob Assigned To => rob


Mantis 1.1.8[^]
Copyright © 2000 - 2009 Mantis Group
Powered by Mantis Bugtracker