Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Line of sight behind walls parallel to a door #5668

Closed
Sheco opened this issue Jan 22, 2014 · 12 comments
Closed

Line of sight behind walls parallel to a door #5668

Sheco opened this issue Jan 22, 2014 · 12 comments
Labels
<Enhancement / Feature> New features, or enhancements on existing Game: Mechanics Change Code that changes how major features work

Comments

@Sheco
Copy link
Contributor

Sheco commented Jan 22, 2014

When peeking around corners, your character is exposed to the enemies, at the moment you exit the look around mode. There's a visual anomaly too.

How to reproduce, place an enemy turret following the friendly sample layout included here.

    +------
    |
    |@
2   '
    |
    |
    +------

Peek down, move the cursor anywhere you want. (X, down, then look around)
After pressing escape or q, your character will be placed at the look around cursor, getting damage from the turret.

The first issue is the visual glitch, where your character is placed at the look around cursor. This seems to be only a visual representation mistake, your character actually is in the location you're peeking, which is in sight and range of the turret.

It doesn't matter where your cursor is, you'll be hit by the turret.

@BevapDin
Copy link
Contributor

It doesn't matter where your cursor is, you'll be hit by the turret.

The viewing range algorithm is not symmetric. If you invert the scenario (switch positions with the turret) you'll be able to see the turret, but it does not see you.

@Sheco
Copy link
Contributor Author

Sheco commented Jan 22, 2014

Did you try the scenario?

The "doesn't matter where the cursor is" is a bug, your character will "teleport" to the location of the look around cursor, but the character will not be in that location, but it doesn't matter, even if the cursor was behind a wall that the turret could definitely not see through, the effect is the same. Your character will be hit while exiting the peek around mode if the location of "peek at" is visible to the turret.

That would mean peaking around is the same as just moving to the location for a turn and moving back. But this is definitely not the case.

@Sheco
Copy link
Contributor Author

Sheco commented Jan 22, 2014

Your patch fixes the visual glitch. (just tested it)

But doesn't address the issue that you're hit after peeking around the corner.

@Sheco
Copy link
Contributor Author

Sheco commented Jan 22, 2014

No wait, you're right, the turret sees me... I understand what you were trying to say.

@Sheco
Copy link
Contributor Author

Sheco commented Jan 22, 2014

Is this asymetric viewing range a correct representation of the world for each actor?

I would assume I'm behind the wall, but I'm actually kind of exposed?

@BevapDin
Copy link
Contributor

The problem is the asymmetric field-of-sight algorithm, see for example here:
http://www.roguebasin.com/index.php?title=Comparative_study_of_field_of_view_algorithms_for_2D_grid_based_worlds#Symmetry

@Sheco
Copy link
Contributor Author

Sheco commented Jan 22, 2014

I think the FoV should be reduced when an actor is straight pointing to an opening with a wall obstructing the view, so it only sees 1 tile straight, right now, looking straight at a window or door, the character has a FoV of 3 tiles wide to the inside.

Or something like that, I obviously don't know what I'm talking about.

@Sheco
Copy link
Contributor Author

Sheco commented Jan 31, 2014

I still think this issue should be looked into, I'll explain the scenario again.

The line of sight code should be tweaked so when an actor is looking in a straight line to an opening (surrounded by at least 1 blocking tile), some tiles inside should not be visible.

         +----
         |???? 
X.............
         |????
         +----

Currently the tiles marked as ? are visible to the actor (player or monster), giving the X actor an unfair advantage, as actors inside the building would not be able to see him, if they are in one of those ? tiles.

I've tried fiddling with the code, but it's out of my league.

Getting closer to the opening correctly broadens the line of sight cone further away, but the tiles behind the walls are still visible.

This affects hidding behind walls, because the character is clearly visible to enemies aligned with the opening.

I edited the title of this issue to reflect the twist from the original report.

@kevingranade
Copy link
Member

For reference, if you look at the page BevapDin linked, we're using "Recursive Shadowcasting".
I honestly don't see addressing this until we have some kind of partial cover type system in place, at which point you'd both be partially visible to each other.

@Sheco
Copy link
Contributor Author

Sheco commented Jun 13, 2014

Ok I see.

Shall I close this?

@KA101 KA101 added Enhancement and removed Bug labels Jun 14, 2014
@KA101
Copy link
Contributor

KA101 commented Jun 14, 2014

I've changed the tags (and struck "bug" from the title) to reflect that this is at best a long-term improvement request. With that, I'd leave it open.

@KA101 KA101 changed the title Line of sight behind walls parallel to a door bug Line of sight behind walls parallel to a door Jun 14, 2014
@kevingranade
Copy link
Member

My recent overhaul forces monster vision of the player to match the player's vision of monsters, so now you can see into the building the same way, but the monster can see you as well.
In some ways this makes monster/player vision even more asymmetric, but it makes it reciprocal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
<Enhancement / Feature> New features, or enhancements on existing Game: Mechanics Change Code that changes how major features work
Projects
None yet
Development

No branches or pull requests

4 participants