bugblatter LOS

[PowerDiver]

I know how I would like to do symmetric LOS, but I fear it is too big an undertaking ever to go after directly. I think it will be necessary to have at least one, and probably several, intermediate steps. I would like to suggest a first step with some obvious problems.

The basic idea is to keep the current system of sending a bolt from the player to the monster, and use that to define LOS, and then define the path from the monster to the player to be the same, just in reverse order.

All LOS is square to square, so if you can see a wall you can target a monster in it.

#####
 M   
## ##
##@##

Above, @ and M see each other, and fire bolts through the gap.
Below, @ and M do *not* see each other. This proposal is not fully symmetric.

#####
 @   
## ##
##M##

This also means

#####
#   G
#   #
#   #
#  @#
#####

the @ cannot see the G above, and cannot see the wall it is in either.
Below, the @ can see and target the G, and the G can target the @ too.

#####
#   G
#   #
#  @#
#   #
#####

This is a suggested interim approach, hopefully to be further improved at some future point in some possibly alternate universe, but reality is that sometimes "interim" fixes last effectively forever despite one's best intentions.

I don't think it would be helpful to suggest modifications. We had that thread already. I chose this due to hoped-for ease of implementation, which is the key to intermediate steps. Please at least give thumbs up or thumbs down *before* digressing.

Would this be playable? Would it be an improvement?

[Marble Dice]

I don't like that it isn't symmetric wrt player vs monster. It would possibly train people to make mistakes - if they assume two-way visibility in all knight's moves because they have it when they are standing on the long side, they might assume there is no enemy around a corner when they are standing on the short side, which might not be the case.

Specifically, this would be an issue with death molds around corners, wouldn't it?

##m##
##.##
.@.##
#####

Moving north-east would be a mistake, but @ doesn't know that because @ and the m cannot see each other.

DIGRESSION: I think DFOV is still my favorite alternative LOS system.

[PowerDiver]

That's why running uses corners. Players would not have to adapt to corners or T intersections, because that is the current behavior.

DFOV isn't feasible at this time IMO. It is beyond what I consider a reasonable chunk size from an implementation perspective. Also, I think players would have to adapt to it more than to this one, so you shouldn't do it unless you are positive that will be the final choice.

Anyway, do I understand correctly that you are thumbs down?

[Derakon]

I also think that it's a bad idea to have LOS depend on the player. It makes intuitive sense that monsters are identical to the player, except AI-controlled; thus, if the player in position A can shoot a monster in position B, then a monster in position A should be able to shoot the player in position B.

Some variants (c.f. UnAngband) have LOS algorithms where the hockeystick lets you see, but not shoot, your target. Of course, I suspect that trick shots still break that, but given the nature of raycasting in a tile-based system, I frankly don't see how you can do away with trick shots.

[Magnate]

Cautious thumbs up from me, but I'd like to know what your preferred symmetric implementation is before taking your word for it being too big to do in one go. My view is that any LOS change is going to be far-reaching and difficult, so I'd MUCH rather we did the whole thing in one version.

[Marble Dice]

That's why running uses corners. Players would not have to adapt to corners or T intersections, because that is the current behavior.

DFOV isn't feasible at this time IMO. It is beyond what I consider a reasonable chunk size from an implementation perspective. Also, I think players would have to adapt to it more than to this one, so you shouldn't do it unless you are positive that will be the final choice.

Anyway, do I understand correctly that you are thumbs down?

I agree with Magnate that pretty much any change to LOS will be far-reaching and difficult. Thus, I think any problems with the LOS system should be fixed in one more or less one go. At the very least, all intermediate steps to the final goal should be taken in the span of one release. That's why I'd rather fix all the problems - symmetry, seeing around corners, projectability, etc at the same time.

I would say I'm a hesitant thumbs down. I could be won over, but I think such a system wouldn't fix enough of the current problems (and without introducing its own idiosyncrasies) to be worthwhile.

[PowerDiver]

I have my own model that is somewhat equivalent to DFOV, but based on center-to-center instead of diamond-to-diamond and it would require changing most rooms. I wouldn't be opposed to DFOV per se. I just think mine is better. Someone called it like dwarf fortress in the other thread, at least regarding their understanding of what I could manage to convey of my understanding at the time.

I just think that rearchitecting poorly written code is really hard. This suggestion is supposed to be the minimal change to allow all new hooks to be implemented and tested in a familiar format where bugs will be apparent, and also to eliminate hockeysticks. If someone could suggest even less of a change, I'd be even happier. Bigger change IMO is insane.

Once the hooks are in place and well tested, then one could experiment with multiple different LOS/POV stuff, but I really think the first change should be as minimal as possible.

I might or might not be willing to implement this. I would not consider implementing DFOV at this time, and would suggest to others that it would be a mistake to do so.

There is also the question of no hockeysticks. I don't think most people realize how often they abuse those. Some playtesting without hockeysticks may change viewpoints about whether DFOV is in fact a good idea.

[d_m]

I don't love this proposal. I think I prefer your suggestion of removing hockey-sticks if we're going to make small changes to the current scheme.

My (potentially bad) plan was to try to refactor the existing LOS implementation(s) into a sensible and modular structure, which would allow us to test (or potentially even plug-in) various LOS implementations and try them out. I agree with you that play testing will be difficult.

The biggest problem right now is that the code uses many different LOS-esque calculations that are only loosely related.

[Magnate]

I don't love this proposal. I think I prefer your suggestion of removing hockey-sticks if we're going to make small changes to the current scheme.

My (potentially bad) plan was to try to refactor the existing LOS implementation(s) into a sensible and modular structure, which would allow us to test (or potentially even plug-in) various LOS implementations and try them out. I agree with you that play testing will be difficult.

The biggest problem right now is that the code uses many different LOS-esque calculations that are only loosely related.

Yes. This is the big problem IMO. I think the solution is to rewrite the code to be much more coherent, improving LOS as we go. So it is critical that we have an agreed end goal - personally I'd be very keen for something like Eddie's centre-to-centre version of DFOV (which IMO is unnecessarily "realistic"). I disagree that big change is insane, and I disagree with Eddie's implied assertion that bad code should be left alone and worked around. We should aim for the big change, of course doing it in manageable chunks as dictated by the necessary code refactoring.

Of course this is easy for me to say: I have carefully avoided taking any LOS-related tickets!

[andrewdoull]

The other approach is to realize that asymmetrical LOS is fine and treat the problems that it creates as AI problems instead of necessarily having to radically redesign the LOS code.

Consider a game play related case where the player can target a grid that will hit a monster with a ball spell, when the monster is not capable of doing so in return. You'll always get this issue regardless of the LOS algorithm used - because it is genuinely asymmetrical.

While I'm happy with the Unangband LOS code (which additionally separates LOS from LOF - a feature no one has considered), it has taken a long time to get out all the quirks. It is btw mostly based on the excellent work done in the Sangband LOS code.

I understand there's a lot of LOS discussion on rec.games.roguelike.development which seems to have compared a variety of algorithms and decided that there is a superior choice - it might be worth linking to and summarizing that discussion here.

Andrew

[PowerDiver]

The biggest problem right now is that the code uses many different LOS-esque calculations that are only loosely related.

Exactly. Getting that fixed is going to be hard. It gets an order of magnitude worse if you try to do it at the same time as you make substantial other changes, because you are never sure which bugs come from which part.

[zaimoni]

I don't love this proposal. I think I prefer your suggestion of removing hockey-sticks if we're going to make small changes to the current scheme.

If you don't care about @ being able to target squares @ can't see, Hockey sticks are trivial to remove, and actually simplify the projection code. [Cf. Zaiband. The base algorithm should backport fine to V, other than reverting C++ to C. Zaiband handles the visibility cache problem by ditching it outright; the automatic trick shot calculation that is too radical for V also handles visibility.]

[d_m]

Exactly. Getting that fixed is going to be hard. It gets an order of magnitude worse if you try to do it at the same time as you make substantial other changes, because you are never sure which bugs come from which part.

Like I said, my hope was to refactor the way the current algorithm is implemented so that it would (in principle) be possible to switch between old and new line of sight algorithms with (relatively) small changes in the code (essentially having different versions of a small number of LOS functions).

So I guess I'm agreeing with you, except that I am not so interested in making medium-sized changes to LOS. Fixing tiny issues (e.g. knight's move) is maybe OK, and once the code is refactored it would be fun to try your algorithm, DFOV, etc, etc.

But I'd rather not spend time on one of these hacky "monsters can see you if you can see them" suggestions.

[PowerDiver]

The problem is that I do not believe there is a current algorithm or model. There is just ad hoc coding that leads to whatever behavior it leads to. It would probably be counterproductive to match the current behavior exactly.

In order to get the hooks right, I think it would be easier to have a few models in mind and to implement one while making sure the hooks support the others. My suggestion was the simplest model closest to current behavior I can think of.

Also, I would never have the patience to do the refactoring work without some specific short term gameplay improvement goal. I'd give up partway through for sure.