Circling the square

[SaidTheAlligatorKingToHisSon]

Never really thought about it before, but read a thread on here a few days ago that mentioned "squarelos". This got me thinking about circles in the game. Circles make it better to approach a monster from a diagonal to stab/close to melee range (less distance), while it's better to approach along a horizontal to cast spells (get longer distance). Some spells have a circular radius (fire storm and glaciate come to mind). The phial of floods makes a nice little circle of water. Circles appear in this game a lot, which appeals to me on an aesthetic level.

However there is one glaring inconsistency to the implementation of circles in the game, and that is movement. Regardless of whether I move orthogonally (horizontal/vertical) or diagonally, the time it takes to move is the same. It may look further on the screen, but it takes the same time to move 4 tiles left and 4 up via a diagonal as to only move 4 up.

This seems to be the only inconsistency concerning distance that shows up in the game (are there others?), however it is an important one. To fix this I propose making movement along diagonals cost 1.4 times the time it takes to move orthogonally. This way distance is consistently implemented in the game, and my thread title makes sense. Even if it doesn't, I thought it was a cool title.

tl;dr - Make movement along diagonals cost 1.4 times the time to move orthogonally

[Quazifuji]

This seems to be the only inconsistency concerning distance that shows up in the game (are there others?)

Reaching targets in a square, rather than a circle like spells do (so a polearm can attack a space two diagonals away, while a spell with range 2 cannot).

Overall, making diagonal movement more expensive would be a very, very big change to the game, I think. Another alternative is to make things that are currently circular (vision, spells, phial of floods puddle, etc) a square instead, which would mean the game's geometry would still be non-Euclidian, but not quite as much so. That's still a pretty huge change, though.

While I'd love to see this issue fixed, I do wonder if it's one of these "so ingrained into the game you can't really remove it" issues.

[duvessa]

This doesn't actually fix any of the problems with Crawl geometry. Because Crawl takes place on a grid, you cannot have Euclidean geometry in Crawl. Period. Consistent geometries possible on a 2D grid include Chebyshev and Taxicab geometry. Crawl currently attempts Chebyshev in some places (movement, etc), and has a weird, terrible Fake Euclidean geometry in other places (LOS, ranges, explosions, etc)

Changing the diagonal movement cost to 1.4 solves absolutely nothing, and in fact actually makes the problem worse - instead of the mix of Chebyshev and Fake Euclidean that the game currently has, you'd have a mix of Chebyshev, Fake Euclidean, and Geometry Where Pi Is Equal To 3.1016. In addition, and more importantly for gameplay, Crawl actions take place on a "grid" just like Crawl geometry: performing five 14 aut actions is not equivalent to performing seven 10 aut actions, because monsters, the environment, etc. are able to act during those actions, while the player character is not. The result is the kind of disgustingly bizarre behaviour outlined in this post. I guarantee if this were implemented in Crawl I'd play either old versions or not at all until it got un-implemented, because tactical positioning - the entire reason I like Crawl - would become utterly nonsensical.

If you want to make Crawl geometry consistent, you have to either get rid of the grid or use a geometry that actually works on the grid. My preference would be to switch to pure Chebyshev; square LOS, square ranges, explosions, tornadoes, etc. Unfortunately, problems still arise because Crawl also tries to have continuous angles which are not really meaningful on a grid and result in aliasing; I gave a very short explanation of the problem with that here. You cannot eliminate angle aliasing on a grid as far as I know (many games such as NetHack attempt to hide this by only allowing you to shoot in 8 directions, but that just moves the problem from targeting to positioning). Here the only option to eliminate it is to get rid of the grid entirely, which is an obviously impractical change for Crawl. You could greatly reduce aliasing by switching from a square grid to a hexagon grid, but that's still a huge change to the game. So I support just switching to Chebyshev geometry, which fixes the inconsistencies even if it does leave the aliasing.

[tasonir]

Bonus point: if we go with Chebyshev, then melee weapons can be described as those weapons which can target the points within your Moore neighborhood. Thusly, they could just be called Moore weapons.

Personally I wouldn't mind squareLOS, but I'm not really that bothered by the current aliasing and diagonal movement issues either.

[crate]

There was a squarelos branch in crawl trunk some years ago and as far as I know the people who played it found it worked just fine, though I never tried it myself.

I definitely support squarelos (basically minmay's suggestion, his post is much better than anything I would've come up with).

[dpeg]

The conflict between LOS and ranged attacks was compounded when we added range differentiation for spells. That was supposed to distinguish spells better (and it does), but it also emphasises diagonals even more, on the short-range spells.

It may have been through spell ranges that squarelos was suggested and implemented (the contradiction between "step" and "distance" was really glaring). As far as I remember, most people were okay with it. The two primary objections were Realism and a technical one I forget (could have been duvessa's aliasing argument). From time to time, squarelos comes up in ##crawl-dev. I have the impression that developers are indifferent or positive towards it these days, but nobody ever made an actual move towards squarelos recently.

[njvack]

You could greatly reduce aliasing by switching from a square grid to a hexagon grid, but that's still a huge change to the game.

In particular, I can't imagine how you'd implement a good hex grid in console. Especially an 80x25 console.

squarelos++

[johlstei]

Minmay's post was really good and yeah, pure chebyshev would be a huge improvement. Then it can be taxicab for april fools.

[Psiweapon]

Squarelos is ugly as fuck, guys.

[Siegurt]

While I realize it's mostly an exercise in academia, what exacly the problem with making movement (for both players and monsters) at a diagonal costing more?

It'd mean that you moving towards creatures along a diagonal would take 70 AUT (at normal movement rate) and they moving towards you would correspondingly take 70 AUT (at normal movement rate) Sure it'd look a little jumpy, and moving at a diagonal would now be slightly riskier than moving horizontally or vertically (Since you'd be taking 1.4ish turns to move once, and things might get to go twice, but you'd know when and how that can happen.)

... importantly for gameplay, Crawl actions take place on a "grid" just like Crawl geometry: performing five 14 aut actions is not equivalent to performing seven 10 aut actions, because monsters, the environment, etc. are able to act during those actions, while the player character is not.

Well, if the monsters also took 1.4 times normal energy to move diagonally it'd all work out close to an even number of actions.

The result is the kind of disgustingly bizarre behaviour outlined in this post.

What behavior are you talking about specifically? I couldn't identify exactly what you meant from your post.

The main disadvatage I see is that unless you're a stickler for watching your AUTs it'd get kind of confusing for a novice to figure out what was going on.

[and into]

^ This would introduce a difference between distance for the purposes of spell range and distance for the purposes of movement. Diagonal spaces would be worth 1 for non-movement purposes, but worth ~1.4 or w/e for movement purposes. This would not only be extremely bizarre and counter-intuitive (even more so than variable movement itself), but would have major implications for game play that are probably not fun. I also think it would cause major pathing problems for allies as well as for enemy AI.

That's a lot of work and a lot of new problems introduced, just in order to accomplish... whatever it is that 1.4 aut diagonal movement would add to the game.

[TeshiAlair]

Squarelos is ugly as fuck, guys.

Plus this is a conflict between optimization and aesthetics/intuition, and I think the latter wins out for me in this case.

[PleasingFungus]

"Investigate squarelos" is on the 0.16 devplan (for whatever that's worth). AFAIK, as dpeg said, there's no one currently opposed to it and a number of supporters; it's just a large amount of technical work, and no one's mustered up the energy yet.

Squarelos is ugly as fuck, guys.

Who cares?

[KoboldLord]

Squarelos is ugly as fuck, guys.

I'm not seeing it. We have loads of squares in the game already, so what's the problem with bigger ones? At least to me, an elegant square is prettier than the weird fat cross we currently use for big AoE. At the very least, 'ugly' is so utterly subjective that value judgments based on it don't have any value.

So yeah, for whatever it's worth I'll add my me-too to minmay's post as well.

[Siegurt]

^ This would introduce a difference between distance for the purposes of spell range and distance for the purposes of movement. Diagonal spaces would be worth 1 for non-movement purposes, but worth ~1.4 or w/e for movement purposes. This would not only be extremely bizarre and counter-intuitive (even more so than variable movement itself), but would have major implications for game play that are probably not fun. I also think it would cause major pathing problems for allies as well as for enemy AI.

That's a lot of work and a lot of new problems introduced, just in order to accomplish... whatever it is that 1.4 aut diagonal movement would add to the game.

Distance is already 1.4ish for non-movement purposes. Right now if you have a range 6 spell, it hits six squares horizontally and vertically, and roughly (6/1.4ish) (4) diagonally. In fact that's how the 'fake euclidian geometry' works presently. (the counter proposal "SquareLOS" treats them both as "1", which is equally consistant, but as pointed out, ugly)

The problem that the OP attempts to address here, is that when shooting or when determining range or radius for explosions, a diagonal counts as roughly 1.4, however movement counts this same distance as 1, treating it the same way for both movement and range would increase consistency, and I don't realistically expect it to be any less bizzare or counter-intuitive than the current system.

Path finding for allies and AI (And for yourself when auto-traveling) wouldn't change. The shortest distance between two points would still be a straight line (or as straight as you could draw on a grid).

The work required for distance and range have already been done (Since that's how they work presently), it's just a matter of changing the energy cost/AUT difference for moving diagonally vs horizontally, which is a fairly small amount of work.

[dpeg]

Of all the proposals that I've seen, different aut costs for different keypresses (orthogonal vs diagonal) is the worst, in my opinion: a tactical situation in Crawl is very much about positions and turns. Do you want to internally (in your brain) represent a monster two diagonal spaces away as "almost 3 turns away"? Squarelos may look ugly, but 1.4 diagonal movement cost would play ugly. I wouldn't expect any developer to support this (and I'd fight against this notion should it come up in the team). Status quo is much better than that.

For what it's worth, you can try 1.4 movement cost along diagonals in the game Empire Deluxe II. (Note the crucial difference: there you are navigating a huge array of units, so managing a single one isn't crucial; in Crawl you only have a single unit.)

[Siegurt]

Well, "Would be difficult to manage in your head" is probably the most reasonable argument I've seen against it.

Although maybe it's just my head, but it just doesn't seem that hard to me. I already do the "The monster is X turns away" thing, because different monsters have different speeds as do I. In fact different actions have different "turn lengths" so adding the overhead of diagonals wouldn't change much for me, I already have to figure out how long the action I am going to take will be and how far the creature might move in that interval.

In practice though, what I *actually* do, most of the time, is divide the distance between me and my opponents into "is far enough away that they can't hit me" and "Is close enough they could hit me next turn (For most melee-only creatures this typically means "adjacent to")" 1.4 aut movement wouldn't change this calculation in my head other than possibly a vaguely pleasant surprise when something I thought might become adjacent to me on a given turn doesn't.

If this ever came into play (And I don't expect it will short of a major turnaround in thinking for a large chunk of the development team, fairly unlikely), a distance meter (in xv and possibly in the shortlist, maybe in the HUD display in tiles) would probably be warranted.

[Wahaha]

The way I evaluate distance is "next to me", "not next to me", "normal speed" and "faster/slower than me". If diagonals were 14 aut then I'd have to add up numbers like 1 + 1.4 + 1.4 to find out whether a normal speed monster can reach me or not when it is 1 or more squares away. Plus there would be situations where there's simply no way of knowing if it can reach you because you don't know the monster's energy amount.

[XuaXua]

Anything wrong with adjusting square granularity by keeping the current geometry, but making all squares 1/4th the current width/height and make a standard player consume a 4x4 square area?

[SaidTheAlligatorKingToHisSon]

The work required for distance and range have already been done (Since that's how they work presently), it's just a matter of changing the energy cost/AUT difference for moving diagonally vs horizontally, which is a fairly small amount of work.

This was what I was thinking when considering whether to "circle the square" (my suggestion) or "square the circle" (the other perfectly reasonable suggestion). Figured it would be easier to do the first though I don't know the code involved.

This doesn't actually fix any of the problems with Crawl geometry. Because Crawl takes place on a grid, you cannot have Euclidean geometry in Crawl. Period.

Not just because Crawl is on a grid. Any computer game cannot have true Euclidean geometry since that involves irrational numbers, which cannot be calculated/stored exactly. The best that is possible is to estimate the values, which I'm guessing is the Fake Euclidean geometry you mentioned? (I haven't read the wiki links or forum thread linked yet so if it's mentioned there feel free to berate me) If so that's what the 1.4 is, could be very precise and say 1.41421356 but the game is going to round to the nearest aut (I'm guessing?) so 1.4 should work well enough.

because tactical positioning - the entire reason I like Crawl - would become utterly nonsensical.

Why? For me tactical positioning mostly consists of fighting in the open versus fighting in a hallway/murderhole or the cutting off of LOS. I don't see how the proposed change would make this irrelevant.

I'm not attached to the proposal at all, just irritated at the inconsistency that came to my attention. One way or another everything should be consistent.

[duvessa]

You could greatly reduce aliasing by switching from a square grid to a hexagon grid, but that's still a huge change to the game.

In particular, I can't imagine how you'd implement a good hex grid in console. Especially an 80x25 console.

It actually has been implemented in console.

The conflict between LOS and ranged attacks was compounded when we added range differentiation for spells. That was supposed to distinguish spells better (and it does), but it also emphasises diagonals even more, on the short-range spells.

One relevant thing that you left out here is that spell ranges were square when originally added. A few versions later (0.7 I think?) they were changed to be circular for consistency with LOS. That change spawned a big argument about square LOS, I don't know how many there were before that.

The result is the kind of disgustingly bizarre behaviour outlined in this post.

What behavior are you talking about specifically? I couldn't identify exactly what you meant from your post.

Did you read the link that you edited out of this quote? Here it is again: https://crawl.develz.org/tavern/viewtopic.php?f=8&t=356&p=3541#p3541. It details why

Well, if the monsters also took 1.4 times normal energy to move diagonally it'd all work out close to an even number of actions.

doesn't actually work.

[Siegurt]

Did you read the link that you edited out of this quote? Here it is again: https://crawl.develz.org/tavern/viewtopic.php?f=8&t=356&p=3541#p3541.

Sorry, for some reason the client I was using at the time I wrote that didn't show "this post" as linked, nor did it bring in the URL when I quoted it (I didn't actually manually edit out the URL, that would be weird)

In any case, yes, the problems brought up in that topic would still be relevant, (Although they can also be summed up as "would create awkward and unintuitive situations") and mostly suffice to answer my question about "What the actual problem with moving slower diagonally would be"

In short: in order for diagonal movement to be a different thing than orthogonal movement, diagonal (melee) distance of 1 would have to be a different thing than orthogonal distance of 1, and turning off 'melee at diagonals' isn't an option for what I suspect are obvious reasons to everyone.

[SaidTheAlligatorKingToHisSon]

Read everything, best counterarguments are proposal would be nonfun complexity for the player to consider (currently situation is push any movement key and take the same amt of time) and the melee situations linked to (the ranged one is not an issue imo, also a few posts down someone proposes fixes to the melee ones though I'm iffy on the fixes). Original proposal would make everything more consistent (I don't buy the adding another geometry claim) but I am a fan of keeping everything simple for the player, unless the added complexity makes the game more fun.

Since that thread linked to is from 2011, I guess this inconsistency with movement has been an issue for awhile?

[njvack]

It actually has been implemented in console.

Wow, that's kind of amazing.

But it looks like they took the:

  Code:

# # # # # # # #
 . . . . . . .
. . . . @ . . .
 . D . . . . .
# # # # # # # #


approach, which is not great. Unless I'm totally mistaken, it's much less dense...?

But my intuition is that it would be a much bigger change to the game than squarelos, which I suppose was your original point

[nicolae]

Death to circledrome, long live the square flesh.

Just out of curiosity, if^H^H when squarelos gets implemented, would it be necessary to shrink the radius of it? There's the potential to have more monsters in LOS at once, but the ones at the edge of LOS diagonally would take just as much time to get to you as the ones at the edge of LOS orthagonally.

[crate]

I think squarelos branch had los radius of 7, instead of the current sqrt(65).

[Brannock]

Wouldn't squarelos cause exploring/LOS oddities? For instance, moving orthogonally in squarelos would reveal only one row or column of tiles. Moving diagonally would reveal one row and column.

[Siegurt]

Yeah.
SquareLOS(7) =169 visible tiles
FakeCircleLOS(8) = 157 tiles.

Even going down to a 7 LOS square still puts 12 more tiles in view every turn.

An 8 square LOS puts 225 tiles in view, which is 43% more tiles (and 43% more possible monsters to have on screen at a time, although hopefully not if you're playing decently well)

[duvessa]

Wouldn't squarelos cause exploring/LOS oddities? For instance, moving orthogonally in squarelos would reveal only one row or column of tiles. Moving diagonally would reveal one row and column.

the number of squares revealed by moving is already different for orthogonal vs. diagonal directions with circlelos, because grid

[dpeg]

The conflict between LOS and ranged attacks was compounded when we added range differentiation for spells. That was supposed to distinguish spells better (and it does), but it also emphasises diagonals even more, on the short-range spells.

One relevant thing that you left out here is that spell ranges were square when originally added. A few versions later (0.7 I think?) they were changed to be circular for consistency with LOS. That change spawned a big argument about square LOS, I don't know how many there were before that.

Yes, that is a good point. We tried back and forth to accomodate the two worlds, but there is artefacts either way. (With square ranges, you have to cap targeting to LOS, in other to get rid of cheesy kills.)

Reading all of this, I think it's status quo until/unless someone re-implements squarelos.