Silhouette Contrast

[BoilerDunce]

First, I understand that changes to stealth mechanics can be a tough decision, since it will affect Ghost runs, old records will have the caveat of their version, some missions may become outdated and impossible to ghost.

They can however be great fun if they are optional.

While playing the Thief games, I thought about what I would look like from the perspective of the guards and realized,
"I should not really be hidden! I look very obvious!"
Not because I thought the light was calculated wrong in the world or anything,
but because the shadow I was hiding in would only hide me against the dark wall that was also in shadow.
Down the hallway was brightly lit, so anyone approaching from down the hall instead of across would see me due to the contrast of Garrett's dark silhouette and the light behind him.

So, there is just something epistemically wrong with the light gem system. There is no "one amount of hiddenness" that a thing can have, but an amount of hiddenness for every perspective.

I couldn't find anything about this, but maybe it's because I only checked here. Feel free to indict my ability to search for things if I overlooked a predecessor's topic on the same thing.

What came to my imagination about a light gem that would really represent how visible the player is to multiple perspectives was this:
Like the original, the gem is dark in darkness, and faintly bright when brightly lit. But, if the player is in a guards line of sight, the number of guards who have him in line of sight will be the number of sparkles that appear inside the gem. If the player has a very low contrast from a guards perspective, that guard's sparkle will remain very small and still. But, if one of the guards sees a high contrast between the player and what is behind him at any distance from that guard's perspective, that guards sparkle will be very large and shimmer.

On the side, I think that player movement should definitely provide a penalty to how hidden the player is even in fairly low contrast, and this penalty will apply more to closer guards than to very far ones, but when standing up, even very far ones should be able to ignore the "fully illuminated" requirement to see you at long distance if you move any faster than a casual walk.

[stgatilov]

This was suggested many times.

I believe there is technical problem in implement lightgem the way you suggest on GPU.
Maybe I can try to make a prototype with new CPU implementation and see how it goes.

However, most of the people believe it would be confusing for the player, and that's a typical case where realism should be sacrificed.

[OrbWeaver]

Yes, this has been discussed many, many times, and the "simple solutions" suggested are very rarely all that simple.

Switching from a single visibility value, affected only by incident light, to a per-guard visibility value is not a small change. It has both performance implications — every single guard needs to render a line of sight to the player, every frame, with full lighting and texturing in order to calculate the visible silhouette — and player UI implications, because each of those individual per-guard visibilities needs to be communicated to the player in a useful way.

Sparkles around the light gem is an interesting idea, but how meaningful will those sparkles be in practice? When a player is surrounded by many patrolling guards, will they be able to map each sparkle to a particular guard, and conclude "Oh yes, the helmeted guard to my left must be able to see my silhouette against the bright wall to my right"? It also raises believability questions of its own, since it's effectively providing the player with an automatic "guard radar" that communicates information about what others can see, which is not information that people would normally have access to.

Still, if somebody can get a prototype working which is performant, intuitive and fun to play, I'm sure many players would be interested in trying it out.

[wesp5]

11 hours ago, OrbWeaver said:

It also raises believability questions of its own, since it's effectively providing the player with an automatic "guard radar" that communicates information about what others can see, which is not information that people would normally have access to.

That is a very important point! The light gem right now is what the player can judge themselves about the lighting.

Edited July 29, 2024 by wesp5

[BoilerDunce]

On 7/28/2024 at 9:56 AM, stgatilov said:

Maybe I can try to make a prototype with new CPU implementation and see how it goes.

I commend you for this.

On 7/28/2024 at 12:41 PM, OrbWeaver said:

Switching from a single visibility value, affected only by incident light, to a per-guard visibility value is not a small change. It has both performance implications — every single guard needs to render a line of sight to the player, every frame, with full lighting and texturing in order to calculate the visible silhouette — and player UI implications, because each of those individual per-guard visibilities needs to be communicated to the player in a useful way.
Sparkles around the light gem is an interesting idea, but how meaningful will those sparkles be in practice? When a player is surrounded by many patrolling guards, will they be able to map each sparkle to a particular guard?

I am happy to answer this, but I also have a thought about those additional renders. I think renders may not even be needed if we take advantage of some inferences. But if these non-render ideas fail, maybe it would still pretty much work to use very low resolution renders, like maybe 114x64.

It may be able to be done more simply if the contrast isn't calculated by comparing the color of the player and the wall, but by information we can infer from the light levels of the area behind the player.

I would like that you can tell whether this won't work as soon as possible, 
So let me get out of the way that if the guards cannot "look" at 2 entities at once, this next idea is impossible.

Maybe when a guard has line of sight to a player, it spawns an invisible player-like object at the farthest wall behind the player, and compares the light level of that dummy player and the real player. Or, maybe a comparison isn't needed. Maybe because the player is blocking the light, we can just assume that any bright area behind the player will contrast badly, and the only value needed to determine visibility is the value of the dummy player. So standing with a well lit area behind you would roughly be exactly the same situation as far as the guard will know as standing in the well lit area. When he sees the dummy player in a well lit area, he passes on its visibility level to the real player and treats the real player as inheriting the visibility value of the dummy player.

About the sparkles:
The sparkles are really only meaningful as a warning to look around and hide yourself as best you can according to what you can see. I would not intend them to correspond to a guard like a compass, they just account for guard's current perception of the player. Without the silhouette change, it is fairly meaningless because it's just a tally of guard visual acquisition. The sparkles would mostly be big when a guard gets close, and by then you probably already are aware of them. If a player is listening intently, they will be able to mentally map a unique approaching footsteps with the sudden appearance of a sparkle and then rely on their memory to associate that sparkle's random position with the area they heard the guard approaching from, giving them a slightly quicker idea of who is suddenly seeing them. 

It mostly serves as a learning tool for players who started moving and did not realize that they wouldn't have time to make it to another fully hidden place before the approaching footsteps would be within line of sight to them.

But, it does also serve as a quick warning that you may have a chance if you can change course to a closer hiding spot along the way to your original destination. It wouldn't have any explanation other than magic or just a contrived UI tool for learners, which, if either of those are excluded from the Dark Mod's official project design, I completely understand and I won't bring it up again. If I may ask, would you offer me directions to the project's guidelines so I can avoid spilling any more of the team's inkwells?

[OrbWeaver]

14 hours ago, BoilerDunce said:

But if these non-render ideas fail, maybe it would still pretty much work to use very low resolution renders, like maybe 114x64.

I believe the light gem is already using a much lower image size than that (possibly 16x16 if I recall correctly). But note that on modern graphics hardware, resolution only makes a modest difference to render time. The engine still has to calculate all of the renderable geometry, do culling to determine what is in view, send it to the graphics card, which then has to map textures onto surfaces and run the shaders to calculate lighting, etc, etc. So doing extra renders is not free, even if the output is a 1x1 image.

14 hours ago, BoilerDunce said:

Maybe when a guard has line of sight to a player, it spawns an invisible player-like object at the farthest wall behind the player, and compares the light level of that dummy player and the real player.

I wonder how the "light level" of an object or area can be calculated without doing either a render, or something that is computationally equivalent to a render. This isn't a basic 1990s engine where you can just calculate distances to lights — we have fully animated, textured and projected lights with (possibly moving) shadows, where every pixel can vary its illumination from frame to frame. It might not even be an actual light entity providing the silhouette at all: the player could be standing in front of a bright part of the skybox, or a glowing particle effect, or a self-illuminated texture like a window or lava.

Either you need to do a complete render to account for all of these (followed by an image processing step to calculate the silhouette), or you're going to end up with an extremely weak approximation which breaks down in so many situations that it actually feels less realistic than what we have at the moment.

[BoilerDunce]

11 hours ago, OrbWeaver said:

Either you need to do a complete render to account for all of these (followed by an image processing step to calculate the silhouette), or you're going to end up with an extremely weak approximation which breaks down in so many situations that it actually feels less realistic than what we have at the moment.

That settles it. You have my thanks for making it completely clear.

Now what's on my mind would be a pinned "already suggested and/or impossible" thread. I feel bad for whoever left the first page because of me. 

If you think it would be best, I'll go to moderation myself to get my own thread deleted so that no one else has to be the one to bother them

[OrbWeaver]

There's nothing wrong with suggesting an idea, and nothing needs to be deleted. Your idea isn't impossible, just more complicated than it might originally sound. It's entirely possible that someone else will come along with a different perspective, or a completely new possibility for implementing it that none of us have considered.