Stances, Line of Sight, and Stealth

Game Talk The Drawing Board
1

I haven’t seen this specifically come up, but given that stealth is planned, I thought I’d throw this out there.

Currently there’s a lot of objects in the game that could block your line of sight if you were crouched or laying down, but currently do not because the character is presumed to be standing all the time.

Counters, sofas, tables, display racks, certain fences, certain vehicle body parts, the wall beneath most windows etc, slightly lighter smoke than normal, would all make good hiding spots, but currently serve only as movement obstacles, if that. Right now structural objects/furniture in the world either block line of sight or they do not. A third option should be available; add in a ‘cover’ tag for certain structures/furniture that blocks LOS only if the character is actively hiding.

The idea here would to have a generic stealth stance that puts the player character into a status where many objects that did not originally block line of sight, now do. This would allow characters to use the above listed objects as cover so they are not seen by enemies on the other side (and cannot see those enemies normally themselves). Obviously in this stance the character moves quite a bit more slowly (and perhaps makes a bit less noise as well). In order to give a visual cue that the player is in stealth mode, the @ symbol could be changed from white to grey.

The Peek mechanic could be used to look over objects that you are taking cover behind, by peeking in the direction of the object. So if you sneak your way up to a window you could peek inside a house without giving away your presence to enemies inside. The same goes for sneaking behind counters and display racks.

This would allow a clever player to plan a route through some locations that would let them pass undetected without even a need for an actual stealth skill/mechanic (although I am in favor of a passive stealth mechanic, as well as a revamped perception mechanic to make the detection of enemies more involved).

Notably, sleeping characters should automatically assume this stance (mechanically) so that sleeping behind a counter actually does provide some benefit.

2

Simple and (I assume) easy to implement. Good idea!

3

Anything but.

4

Huh.

I know very little about C++. Sorry!

5

Planning on implementing something like this, but it will require heavy modification to the line-of-sight code.

I like the concept of peeking at an obstacle bumping your height up to just enough to see over it, that’s a new idea, and I’ll be nabbing it when this gets implemented.

The full system gives obstacles a height value instead of just blocking or not blocking vision.
For the sake of illustration, we’ll say that each level is one foot above the ground.

standing PC eye height will be something like 5, crouching 4, crawling 2.
A counter would be 4, refrigerator 7, windowframe 2-4, a wall would be 10, or whatever the max is.
A regular zombie would also be 5, a brute, 6, hulk 7-8, dog 2, child 3-4.

To determine if a PC sees a monster (and vice versa), you’d keep track of what “slice” is visible, it would default to 0+, if an obstacle higher than the current value interposes, it bumps the number up to that, so for each square in range, you have a heightmap, and any entities (ground, furniture, monsters, items) in that square with a height above the heightmap for that square are visible. Can probably do the same with overhangs indoors. Will have to put some thought into how this interacts with multiple z-levels.

If we want to get extra, extra fancy, we might apply some kind of trig dealy so e.g. a counter right next to or close to a PC won’t block vision of everything shorter than it is.

As an example, if you have a standing PC, a counter, and a zombie dog, neither the dog nor the PC is going to see the other. A zombie next to the dog could see the PC and vice versa. If the PC drops on the ground, the zombie wouldn’t be able to see him either.

6

I am always in favor of more complex simulation, so giving objects and enemies their own heights and working from there is definitely better than simply tagging objects as being Blocking or Not Blocking based on the character’s current stance state.

As I was reading your post I was thinking about LOS being dynamic (a standing PC might not see the zombie dog on the opposite side of the counter, but if the zombie dog were to move a tile away then the PC would be able to see them). And then you pretty much described it yourself. I love that idea, and hopefully it wouldn’t be too processing-heavy to implement doing this for (presumably) every NPC/Enemy in the game.

7

There’s a trick we use to keep that manageable. Basically the player IS the center of the world, we have to enumerate everything the player can see to draw things properly anyway, and most everything needs to know if they can see the player, so we do a whole bunch of these calculations at the start of the turn and store the results. So for each tile in sight, we compile a bunch of information, like whether it’s transparent (soon HOW transparent it is and how much of it is blocked), its light level, and whether the PC has LOS to it. Then for any checks involving the PC (“can PC see X” or “can X see PC”) we can use this info instead of recalculating it.

When a monster or NPC (very rarely) needs to know if it can see another monster, NPC or item, we can do that calculation on the fly since there aren’t that many of them.

8

And what about, if the player has 5 height, and he stands over the counter, his height could change to 9?

Player height standing up (5) + counter height (4) = 9

He could see more… but…
This height idea would make some things weird, if we take the human as 1,70 m tall (Sorry, i don’t know feet) and the counter height is more or less 1,40, he could not be able to stand up if there is a roof, wich, in my house’s case, is 2,60 m (not “even” exact) because the height of the player + the counter exceeds the max height posible. I know this is very, but very complicated and maybe not important.

9

I think it could be easily assumed that the PC occupies whatever space is available above the object. There’s no reason a person can’t stand on a counter and hunch their shoulders a bit.

Just max the height out at 10. So you cannot see over walls.

10

[quote=“Hyena Grin, post:9, topic:2858”]I think it could be easily assumed that the PC occupies whatever space is available above the object. There’s no reason a person can’t stand on a counter and hunch their shoulders a bit.

Just max the height out at 10. So you cannot see over walls.[/quote]

Good point.

11

Be sure to include “Knocked over desk” when this is implemented.

Zombie school kids out OF FREAKING NOWHERE!

12

Standing on top of things would go into the stance/low roof type thing, which we want to handle anyway.
If there’s no roof in the way, your head will poke into the next z-level at some point, so you’d count as having a very small height on the next level up.

13

I was thinking about that as well, but I figured that it’d be awkward if you jumped onto an object and suddenly were seeing the next Z-level up instead of the Z-Level you are standing in. Chances are you are mostly interested in the Z-Level you are in, where there might be enemies and the like.

I do like the idea of being able to climb up and see into the next Z-Level, but probably not as a default behavior. When we have Z-Levels, a command that allows the character to ‘look up’ and ‘look down’ a Z-Level (and view whatever they can see from their current head-height) would be handy. But I think that as I am playing I will generally want to (by default) be looking at the Z-Level that the majority of my body is on, because that is probably where the information most relevant to my actions is going to be.

As an aside it would also be interesting to have a climbing mechanic where you can mount objects of a certain height in comparison to the object you are standing on. So if you are the ground you can’t reach the roof of a single-storey house or the top of, say, a van parked next to it. But if you climb onto a fence you can reach the top of the van, and from the top of the van you can climb onto the roof of the house.

14

Yea we’d definitely want to do that kind of thing. Roll your armored death-mobile up to a mall or something, climb an internal ladder, and then step onto the roof of the mall, or a fire escape.

15

If vehicles could have internal Z-levels…crow’s nest, anyone? Make a space behind the air-dam (whatever it’s supposed to be called–that aerodynamic thing on top of a Semi cab so air flows around the trailer rather than hitting it) and climb up for a better view.

16

Being higher would help accuracy?

17

[quote=“Kevin Granade, post:12, topic:2858”]Standing on top of things would go into the stance/low roof type thing, which we want to handle anyway.
If there’s no roof in the way, your head will poke into the next z-level at some point, so you’d count as having a very small height on the next level up.[/quote]
You could have items hidden in the gap between the roof and the cabinet in houses, and you would have to move a chair or something so you could grab them.

18

Accuracy no, it could extend lateral range a bit, and reduce it if firing upwards, not sure if we’ll be bothering with that…

What am I saying, we’ll definitely do something based on that, just a matter of time, heh.

19

I have limited coding knowledge, but it seems to me that a quick and dirty solution might not be so hard, just until the devs can get around to a full system for it.

Add a value to the terrain array (or whatever you store junk like furniture in) that is simply a 0, 1, or 2. A similar to the player and all creatures. The creatures don’t need to be able to intelligently crawl, it would just represent their height for the purpose of looking over things. The terrain variable would store whether the object provides: 0 - no concealment, 1 - kneeling concealment, 2 - crawling concealment. The player/monster variable would store: PLAYER 0 - standing, 1 - kneeling, 2 - crawling. MONSTER 0 - full sized, 1 - half sized, 2 - tiny.

An object providing kneeling concealment would block line of sight behind it, say, 7 tiles. A creature of full size or standing human in that is fully visible, a creature of half size or kneeling human in the first, say, 4 tiles is hidden, and a creature of tiny size or a crawling human anywhere in that is hidden.

An object providing crawling concealment would only cover tiny and crawling humans in, say, 2 tiles.

These are not actual suggested numbers, just a potentially simple implementation to get things started. I’d say the tiles in the zone would be hidden, since you cant see the ground at all in the area, but creatures and humans can potentially be revealed. If you are in the hidden zone and stance you cannot see past the object either, but possibly bypass this with the look around corners thingy? I’ve never used it so dunno how it works lol. CHAAAAARGE! Oh crap, turrets.

But yeah, like I said, limited coding knowledge. That said, this is a simple addition of one variable to two arrays and an if/then statement, and possibly a slight tweak to the LoS function if it cannot be called so easily to make the object block vision. If your code allows?

EDIT: Items on the floor would ALWAYS be hidden within the concealment range of the object. Even if they’re big. Just to simplify. Again, only until a proper system is in.

20

The problem with a “quick and dirty” system is that it’s in the rendering code, which is the most complicated and performance-critical code in the game, will be implementing this, but it has to be right to avoid slowing the whole game down.