CircleLOS produces inconsistencies in game logic and balance problems.

[Eighth-of-Third]

CircleLOS makes absolutely no sense in a world based on square tiles. With, e.g., High Night Vision, you can see 5 squares on a diagonal and 7 squares on a horizontal. You can fit a maximum of 5 zombies on a diagonal line and a maximum of 7 zombies on a horizontal line that supposedly spans the same distance.

The trig-based movement costs are confusing, because the only place they are mentioned is in the options menu and turned on by default; if you don't look at the options menu, which most people won't, you'll have no clue it takes longer to move on a diagonal than on a horizontal. They also cause combat balance problems; if you can get zombies to move towards you on diagonals, you'll have more chances to shoot/hit them. For example, a zombie moving into a windowframe horizontally gives you 400 move to kill it before it attacks. The same zombie moving into the same windowframe, but diagonally, gives you 565 move to kill it before it attacks.

[Stevensonz]

well call it tactical positioning if zombies do move diagonally then it's their problem not yours. I don't see that much game breaking on trying to make a zombie stumble diagonally. But hey I believe the CircleLOS is a good change makes things somehow realistic than square ones.

[Eighth-of-Third]

We're not exactly aiming for "realism" in a game with sentient zombie goo and extra-dimensional horrors. I think having an internally-consistent, balanced game world is more important than trying to make that game world consistent with our world. Circular LOS and trig-based diagonal movement calculations are not consistent with the tile-based nature of movement. The extra movement cost isn't displayed when (;)looking at tiles, and really can't be displayed through (;)looking at tiles because the movement costs of tiles will constantly change depending on where you are in relation to those tiles. The extra movement cost also produces balance problems.

[Stevensonz]

@Izicata you mean with these changes zombies/monsters moving toward you diagonally on 100 movement tile to a 100 movement tile increase their movement more? or 100 movement tile to a higher one is causing the imbalance as opposed to strategy? as for the sight issues will monsters using squareLOS be a good fix or it un-balances due to player having a Circle one?

[Eighth-of-Third]

Yes, zombies that move diagonally, and end their movement next to you, will let you hit them more before fighting back than zombies that moved horizontally or vertically. Zombies actually have 70 speed, and moving diagonally will cost approximately 1.41 times as many movement points as moving horizontally. On flat ground, zombies moving diagonally will let you hit them for about 200 move and zombies moving horizontally will let you hit them for 143 move. That's about 1 extra attack, maybe more if you've got -torso encumbrance.

That is the balance issue I am talking about. As far as I know everything uses the same LOS calculations.

[kevingranade]

Oops, I did mean to switch it off by default, other than that I'm not commenting, this is AtomicDryad's thing.

[yobbobanana]

One benefit to proper radial distances is that they "look" correct. That is, when you look at the distance between you and a zombie 20 tiles away diagonally, it looks like it should be further away than one 20 tiles away horizontally.

I agree with you about the balance issues, but think that in stead of introducing them, this change exposed them. Moving onto window frames could be changed to add a flat movement cost, for example. And not noticing that diagonal moves cost more could be solved by giving the player some indication of how long their moves are taking (which would also let you know how fast you're swinging that baseball bat).

That said, having it optional is nice, as the game is indeed based on a square grid with diagonal connections.

[Eighth-of-Third]

Circles look correct, but they're not correct. With square tiles, a "square" is a circle. All points on the edge of a "square" are equidistant from the centre.

This is a circle. Cutting off the "corners" produces a diamond, not a circle. Trying to patch over that with trigonometry just produces movement problems, balance problems, and mechanics-transparency problems. Getting used to the square-circle is just part of playing terminal-based ASCII games.

I'm not sure what you mean by a "flat movement cost". Moving onto window frames already adds a flat movement cost of 300 compared to moving on open ground. Unless you're talking about making speed mostly irrelevant when moving over window frames, which opens up a whole new can of balance worms.

And this change definitely introduces balance problems. For example, it is now possible to near-infinitely kite zombies on diagonals when using martial arts. Zombies have 70 speed, moving diagonally takes 141.4~ move, so they use 202 move to move one square diagonally. Players mostly have 100 speed, so they use 141.4~ move to move diagonally, and one martial arts attack costs 65 move, total 206.4 move. Moving and attacking is only 4.4 move slower than a zombie moving once, so you can just keep moving diagonally for 46 player turns and only (maybe) get hit by the zombie's lunge attacks. Moving and attacking on a horizontal surface is 22 move slower than a zombie moving, and zombies take 142.8 move on a horizontal surface, so you'll get hit by a regular attack once every 6.4 player turns.

This update made kiting with martial arts around 700% more effective, but only if you move on diagonals.

[yobbobanana]

All kinds of silly kiting tatics are possible with the current code.

Drawing a square and asserting that it is a circle is a little absurd. Especially as it depends on the movement cost along diagonals, the very change being discussed. If it costs sqrt(2) times as much to move diagonally, then the constant amount isn't "tiles" or "keys pressed", it's "time taken". Constant time taken is a square if moving diagonally and horizontally cost the same, and a circle if cost is determined by euclidean distance.

You said that moving onto a window costs 400 horizontally, 560 diagonally. If in stead it was split into moving and window-clambering, it would be 400 and 440 (300 + normal movement cost). It would be trivial to also modify this 300 window-clambering penalty for player speed.

[Eighth-of-Third]

Drawing a square and asserting it is a circle is exactly what every single square-tile-based movement system on the planet does, because it works.

Even if you change the movement costs, you can't get around the volume inconsistencies. You can fit 5 zombies on a diagonal line that is supposedly the same distance as a horizontal line that can contain 7 zombies.

Even if you change the movement costs of window-frames, you can't get around the fact that moving one square diagonally takes more time than moving one square horizontally, allowing melee characters more initial attacks on enemies that move diagonally.

Squares are circles in square-tile based systems. This is for a reason.

[ejseto]

Just because every other roguelike equates squares and circles doesn't mean it makes sense or is correct. It's simpler, and it's a convention, that's all. How does it make sense if moving one square horizontally and one square vertically takes twice as long as moving one square diagonally, instead of sqrt(2) times as long? This introduces silly stuff exactly like you're complaining the change introduces, namely, metagaming around diagonals since it's faster to move like that (there is no drawback to moving diagonally, so one should ALWAYS move diagonally, as it can be potentially beneficial). Either diagonal moving is faster than in real life, or slower than in other roguelikes, there's no way around this. At least the most exploitable part of circular LOS is easily fixable (making window move costs constant, as mentioned).

As for volume inconsistencies, isn't the LOS code written so that zombies swarm instead of stacking in a line? This seems like something you won't notice in normal gameplay, but rather just a flaw or tradeoff of using a discrete grid. It's not like there are even any 1-tile wide horizontal hallways, let alone diagonal hallways, for the zombies to be taking up differing amounts of space in.

[kevingranade]

Both methods are approximations, both are "wrong" in different ways. On Jun 6, 2013 11:24 PM, "ejseto" notifications@github.com wrote:

Just because every other roguelike equates squares and circles doesn't mean it makes sense or is correct. It's simpler, and it's a convention, that's all. How does it make sense if moving one square horizontally and one square vertically takes twice as long as moving one square diagonally, instead of sqrt(2) times as long? This introduces silly stuff exactly like you're complaining the change introduces, namely, metagaming around diagonals since it's faster to move like that (there is no drawback to moving diagonally, so one should ALWAYS move diagonally, as it can be potentially beneficial). Either diagonal moving is faster than in real life, or slower than in other roguelikes, there's no way around this. At least the most exploitable part of circular LOS is easily fixable (making window move costs constant, as mentioned).

As for volume inconsistencies, isn't the LOS code written so that zombies swarm instead of stacking in a line? This seems like something you won't notice in normal gameplay, but rather just a flaw or tradeoff of using a discrete grid. It's not like there are even any 1-tile wide _horizontal_hallways, let alone diagonal hallways, for the zombies to be taking up differing amounts of space in.

— Reply to this email directly or view it on GitHubhttps://github.com/CleverRaven/Cataclysm-DDA/issues/1435#issuecomment-19088306 .

[Eighth-of-Third]

It's not merely a convention, for reasons I have repeatedly stated.

Moving on diagonals is "faster" if you're still thinking a "square" is a square. Moving on diagonals is exactly as fast as moving horizontally or vertically, because a "square" is a circle. The Pythagorean Theorum holds no sway here; in the land of tiles, A = B = C. Squares are four-sided circles and right-angle triangles are three-sided squares.

You say that window frames are the most exploitable part of circular LOS, I say it's merely the first or second exploit found in the first DAY. Just implementing your suggested fix means that either every single terrain type with a movement cost >100 will have to be special-cased, or the movement code will have to be rewritten. Again. I have intentionally not mentioned how the changes to the light code have caused multiple issues including a game-breaking freeze, because those can be fixed, but I think we should try to avoid changing stuff that works perfectly well if there's doubtful benefit to be gained from those changes.

Players can make as many horizontal or diagonal 1-tile hallways as they like using the construction menu.

[CorneliusAmphibulon]

Based KG can you just fix this stupid shit? 1 tile is x distance and moving 1x is still 1x whether it's hors/vert or diagonal. I can't believe that pythfags are trying to fucking defend this abomination.

[ejseto]

That's classy, github = 4chan now?

And wtf are you talking about fixing for? It's an OPTION, if you don't like it, don't use it.

[Eighth-of-Third]

@CorneliusAmphibulon You're not helping.

[Justice-]

I understand the desire for circular LOS and/or lighting effects, and Izicata is partially correct, but do we really want something this problematic and complex inserted just prior to Kickstarter and 0.6 release?

[Eighth-of-Third]

It's an OPTION, if you don't like it, don't use it.

That's all fine and good until that option starts having effects on the rest of the game, such as the aforementioned game-breaking lighting crashes, or if development starts to build around that option to the point that disabling it negatively affects the game experience. You can't tell me that Classic Zombies mode is actually balanced or being significantly developed for.

[i2amroy]

I would like to point out an example of a Rougelike that utilizes circular movement/distances, Dwarf Fortress Adventure mode, and it manages fairly well.

As for the "flat movement cost" idea (which I think might work rather well actually), the key to the idea is this. As of the moment if you move onto a window diagonally under the new system as is then it costs: window movement cost * ~1.4 = ~420 movement cost Under a flat penalty movement system it works like this: 1.4 * (100) [base movement cost] + window movement cost - base cost = ~ 340 movement cost.

Basically the way it works is that instead costing whatever amount times the penalty for moving diagonally, instead the only bit of cost multiplied by the diagonal penalty is the basic "movement cost" of 100.

[Eighth-of-Third]

That is even more confusing than the currently implemented diagonal movement calculations. I didn't think that was possible. It also makes moving over >100 movement cost terrain on a diagonal "faster" than moving over the same length of terrain on a horizontal. Moving over individual tiles would still be slower, but moving over the same "distance" worth of tiles would be faster on a diagonal than on a horizontal.

I haven't played DF in a very long time, but when I did, both adventure and fort mode had moving over diagonals be exactly the same as moving over horizontals. Has Toady really implemented trig-based movement calculations, or is the LOS just "circular"? Because it was "circular" when I last played.

[Justice-]

Let's not dismiss the long history of this discussion among roguelikes. Amazing, how very near the arguments starting pre-2003.

@i2amroy Toady has had the benefit of several years to tweak and perfect his code. (I became a Bay12 Champion in '06.) I somewhat doubt that he'd be willing to share his DF algorithm with us.

[ejseto]

@i2amroy That's sensible, windows deserve a special case because windows are thin. They're not symmetric thus proportional move costs don't make sense for them. Something like a bush or counter you would expect to "take up" all (or at least most) of the tile, thus moving diagonally over them would take longer. But in traversing a window frame, most of the traversal will be over empty space, and you wouldn't expect the time spent in the actual window to any greater at an angle than head on. Conceptually, a window frame would apply a flat penalty like a trap (which makes sense since players use them like traps, getting zombies stuck on them so they can melee them), while bushes and counters are conceptually more like homogeneous terrain.

@Izicata If devs start building around circular LOS, that means there's enough interest in it that someone is willing to put in actual work. Isn't that what motivates everything else put into the game? Certainly, it won't be perfect straight off, and you might not think it's worth the effort, but someone else thinks it's worthwhile enough to put in the work, no? Just because you don't like it personally doesn't mean it doesn't deserve a chance. Not everyone thinks of triangles as squares and squares as circles. As for breaking other parts of the game, any feature or change can do that, and that's what version control is for isn't it?

[Eighth-of-Third]

Only special-casing windows means that players who know what they're doing will now drag individual zombies over bushes diagonally, and play otherwise normally with windows. Pits are still going to be 40% better if you drag zombies over them diagonally. Again, you'll have to special-case everything with a movement cost >100, or significantly rewrite the movement code.

I am concerned that the devs may implement and build around CircleLOS without thinking about the actual gameplay consequences of CircleLOS, as has happened with DCSS. DCSS's circular LOS is actually worse than the proposal we're arguing about, because they can't/won't implement trig-based movement costs. Melee characters all want to approach ranged enemies on diagonals, and ranged characters all want to pewpew at melee enemies approaching on a horizontal or vertical. It's pretty bad and it hasn't really gotten better. For a significant period of time, spells used a "square" range while the LOS was still "circular", meaning they had longer effective range on diagonals.

Now that I mentioned it, I went and looked over the ea6fc565da931d42d775cee9c70d8b3d34e55f9c commit, and there aren't any changes to ranged.ccp. Has it actually changed the accuracy calculations, or do guns have longer effective range on diagonals now?

[Eighth-of-Third]

Okay, example time. We have a zombie trying to move one space east and one space south-east, but there's a bush in the way.

Z = Zombie • = flat ground X = bush

Z • • • X •

The zombie moves south-east, into the bush. 565.7 move cost.

• • • • Z •

The zombie moves east, out of the bush. 100 move cost.

• • • • X Z

Total move cost of 665.7, position compared to start: 1 south, 2 east.

However, if the bush is placed slightly differently, and the zombie takes a slightly different path, the move cost is significantly different.

Z X • • • •

The zombie moves east, into the bush. 400 move cost.

• Z • • • •

The zombie moves south-east, out of the bush. 141 move cost.

• X • • • Z

Total move cost of 541, position compared to start: 1 south, 2 east.

These two situations should be absolutely identical, but they're not. The zombie moves the same distance, and encounters the same obstacle, but moves faster in the latter situation. This does not make sense.

[Eighth-of-Third]

Setting everything to a flat penalty system doesn't work either, because then players will want to drag zombies over horizontally oriented trap setups rather than diagonally oriented trap setups. You will be able to fit more traps in the same distance, and zombies will trigger more traps in the same amount of time, if you put them in a horizontal line rather than a diagonal line.

[i2amroy]

A flat penalty system certainly beats the straight multiply system for cases such as above though, since with the penalty system both bush paths will cost identical amounts of movement.

As for DF, yeah, Toady has had diagonal based movement since the start AFAIK. My point was simply to illustrate that a system like that can be done well (though our problem is slightly more complex since bushes/etc. cost extra movement points).

[yobbobanana]

For bushes a good change would be to treat the zombie as "stuck" in the bush, and give it a chance of "escaping" each turn. So moving in would cost 1* or 1.41* depending on direction, then it would flounder around for an unpredictable amount of time. I think this would be a desirable change in either system.

:)

[atomicdryad]

Hiya, this brouhaha is my fault :P I'll address "fix circle los / circle range by removing it" first, then go over specific points when I have more sleep >.>

• First, this is an -option-. You can revert to previous non-euclidean roguelike geometry by disabling 'circular geometry'. I have argued -against- making it non-optional, and will continue to do so.
• "Is confusing" isn't an objective statement. I expected the top right corner of a square to be further from the center than the lefthand side (and diagonal movement to cost more time/points/etc) and was surprised when it did not.
• "Circular los is fine, movement no" With roguelike distance calculation, pretty circular LOS will squeeze your viewing range into a diamond. I suppose if enough people really want the handicap, the 'circular geometry' could be split into 'circular distance calculation' and 'circular viewing range and lights'. Or square everything / square distances, circular lights / circular everything.
• Square distance calculation has it's own form of exploit / wtf as far as long distance travel (which is obvious and doesn't need explaining)

Bugs: Yeah there's a reason I prefixed my pull request with TESTME and hoped people would test and give feedback :P Some are due to mistakes on my part, others are bugs exposed by the change.

• Oops: Diagonal movement for single tiles should be (oldcalc) + ( trigdist? 41: 0 ). That way the bush example will net a cost of 541. Working on a commit. There's other quirks with diagonal movement btw, in both max(xdist,ydist) and circlegeom; try parking sideways in your nicely armored and sealed up car.
• Firearms: Apparently there's no real range limit to a weapon, it was all policed by how far the player was allowed to target. Fix pending; to begin with, probably by sweeping it under the rug again and limiting target to circle if circlegeom is enabled, but I'll test monster gun range too.

In summary: please turn the option off if you find it too buggy or confusing. I'll be looking into the former.

[kevingranade]

To everyone debating and keeping calm, thanks for that. If you're not, well you aren't helping your argument.

As I said right off the bat, I'm changing the default to rl_dist, I meant to do that in the first place, and just haven't gotten around to it. It's both too unexpected and too new to be the default right now, this will be revisited.

Re: sapping developer time, this is a non-argument, if someone really wants to work on this, primarally AtomicDryad, that's no one else's business, and particularly as AtomicDryad is quite good about keeping changes clean and self-contained, I'm not concerned about it imposing unrelated maintenance burden (through general bugginess, need for refactoring, etc.) The branch is amazingly non-invasive for what it does.

Re balance: I really can't imagine what kind of balance issue this will introduce as long as everything is symmetric. As was mentioned, it may close kiting exploits, good.

Re "a square is actually a square", your packing argument has some validity, but really a square is whatever the game engine says it is.

[Eighth-of-Third]

Apparently there's no real range limit to a weapon, it was all policed by how far the player was allowed to target.

That, and firearms get progressively less accurate as they fire at farther-away tiles. You'll get a lot more headshots if you fire at a zombie right next to you than if you fire at a zombie 10 tiles away.

I just checked ranged.ccp, and it's always been using trig-based calculations, which means monsters on a diagonal are considered "farther away" than monsters the same distance away on a horizontal no matter if you're using the circular distances option or not.

Toady has had diagonal based movement since the start AFAIK

Toady has had diagonals cost the same amount of time as horizontals from the start, AFAIK. It's just that in adventurer mode, the LOS is circular for some reason.

[i2amroy]

Toady has had diagonals cost the same amount of time as horizontals from the start, AFAIK. It's just that in adventurer mode, the LOS is circular for some reason.

Around the 40d era Toady confirmed that moving diagonally in dwarf fortress costs sqrt(2) movement. I'd link you to the exact post right now, but at the moment my internet blocks the Bay12 site. I'll update this post with Bay12 confirmation once I am back home, for the moment you will just have to be satisfied with a quote from tvtropes' Diagonal Speed Boost page

"Averted in Dwarf Fortress for the x-y plane: diagonal movement takes 362/256 times as long as orthogonal movement, which is as close as the game engine can get to the square root of 2."