could NPC AI detect the player by textures contrast and nearby movement?

[Gussak]

1 - TEXTURES [EDIT: this idea changed because of excessive complexity, look for PGS idea at this post]

On complete darkness, only on the light of the moon, the player is a big dark mass moving around.

 

How a chameleon works? it colors itself like the place it is standing into, so looking at it you see nothing special.

 

The player should not have such power of course, but... the AI, looking at the player, could notice that behind the player there is light textures (textures with light wood color, or a light white/cyan floor) that contrast with that big dark mass. (such special textures/geometries could be marked as HaveLightTexture or something like that)

 

I think its implementation could be a ray cast from NPC head thru Player head and hitting a geometry/texture behind the player head; if such texture is light colored, even in the darkness (without light source), the NPC AI would get suspicious and move towards the player.

 

2 - MOVEMENT PERCEPTION

Even if you make no sound, or no distinguishable sound, if you move, even if you look to the sides (if too much your head have to move), they AI could get suspicious; that is how our perception works, we stare and wait something move to care; so I wonder if nearby AI could react promptly to any movement?

 

To play with it, we would be required to stay and wait the NPC go away (I actually do it sometimes, until I remember I need not ).

 

PS.: Btw, I also noticed that the AI guard stays calmly in complete dark where before was a campfire, it could try to re-lit it as fast as it can, they could have top priority on keeping some light source always on.

 

Also, excellent game and excellent music on main menu!

Edited October 30, 2014 by Gussak

[bedhead]

This would make some fan missions impossible to accomplish without getting spotted based on how theyre designed

 

But I hear ya. Sometimes im standing in a shadow thats in the middle of a bright hallway thinking this can't be right.

[Springheel]

We talked about silhouette detection early on, but decided against it. Not only would it be difficulty to implement, but more importantly it harshly penalizes the player for something they can't easily control. While in real life you can quickly glimpse the light sources behind you, that's much more difficult to do in a game with a limited field of view.

[HMart]

Realism should never get on the way of gameplay imo, and also imo it is not fun to be in a shadow and be seen just because theres a bright texture behind me.

[Gussak]

We talked about silhouette detection early on, but decided against it. Not only would it be difficulty to implement, but more importantly it harshly penalizes the player for something they can't easily control. While in real life you can quickly glimpse the light sources behind you, that's much more difficult to do in a game with a limited field of view.

 

The silhouette seems complicated.

 

But my suggestion about the ray from NPC head thru Player head til it hits a geometry/mesh marked with LightTexture seems complicated too? (it could be run once a second to not even encumber the CPU)

 

Realism should never get on the way of gameplay imo, and also imo it is not fun to be in a shadow and be seen just because theres a bright texture behind me.

I thought (but forgot to write) that this could be an option called something like "Realistic AI detection", it could be toggled while the game is running.

 

This would make some fan missions impossible to accomplish without getting spotted based on how theyre designed

 

But I hear ya. Sometimes im standing in a shadow thats in the middle of a bright hallway thinking this can't be right.

Just thought: we could be allowed to prone on ground, we would move slower, we could even move thru smaller holes on the wall , and our silhouette would be less perceivable! this would be an easy and convincing alternative.

Edited October 28, 2014 by Gussak

[Springheel]

But my suggestion about the ray from NPC head thru Player head til it hits a geometry/mesh marked with LightTexture seems complicated too? (it could be run once a second to not even encumber the CPU)

 

Well, it wouldn't be that simple. What would you do with textures that have both light and dark elements? What if the player is standing in front of a bright wall but his head is in front of a dirt stain? etc.

 

But the main factor is still the part about the player not having much control. You'd have to be able to figure out what direction the AI can see you from, and then quickly ascertain what is behind you from that direction; with a limited field of view the only way to do that is to swing your mouse 360 degrees to look behind you. And you would have to do that, theoretically, for multiple AI, or AI in motion. It's simply not practical. It's like having AI react to the player shadow...it sounds great on paper, but the more you delve into how to implement it, the more of a quagmire it becomes.

[Gussak]

Well, it wouldn't be that simple. What would you do with textures that have both light and dark elements? What if the player is standing in front of a bright wall but his head is in front of a dirt stain? etc.

Both light and dark on a texture, could provide 50% chance of NPC getting suspicious, it could be marked HalfLIghtTexture (no need to be precise).

Only the head being checked is just to not encumber the CPU (checking body on 3 points plus hands and feet could be encumbersome, but I am not sure tho, at distance, only one single point on middle of body could be checked).

Even if the head could be ignored, having a white wall behind, his body would still cause contrast tho, so NPC will get suspicious.

 

But the main factor is still the part about the player not having much control. You'd have to be able to figure out what direction the AI can see you from, and then quickly ascertain what is behind you from that direction; with a limited field of view the only way to do that is to swing your mouse 360 degrees to look behind you. And you would have to do that, theoretically, for multiple AI, or AI in motion. It's simply not practical. It's like having AI react to the player shadow...it sounds great on paper, but the more you delve into how to implement it, the more of a quagmire it becomes.

I think this is the main problem. We got used to play walking in the middle of the corridor, room or yard.

Lets think about ninjas: you will see they jump from shadow to shadow and prone on floor, they move close to walls, they "dress on grass" to disguise in the garden or hide in bushes and small trees, tall grass, and so on; it is all about being a chameleon and unseen.

 

So, with such feature implemented, how we would play with limited field of view? we look where we need to go, and check the walls, where we need to stay to not be perceived by NPCs; with that route in mind we do the timed moves! Even with several AI, you are glued to the proper wall, so they wont get suspicious. I mean, we would have to re-learn how to play . Despite I currently try to do all this just for fun hehe.

 

Interesting you pointed about the player shadow (or even multiple shadows from diff lights), such shadow can be from anyone even another NPC, so an NPC would only get suspicious if he thinks he should be alone in the area, so no one else should be there, what would make he check from whom is the shadow. Doesnt seem very good to implement it, as it will happen not often and really seems very troublesome as "a shadow can reach very far" (actually the light reaches but..)

[Airship Ballet]

Interesting you pointed about the player shadow (or even multiple shadows from diff lights), such shadow can be from anyone even another NPC, so an NPC would only get suspicious if he thinks he should be alone in the area, so no one else should be there, what would make he check from whom is the shadow.

How exactly is a guard supposed to be suspicious of a silhouette against a light texture but not the shadow of someone who clearly doesn't want to be seen?

[Gussak]

How exactly is a guard supposed to be suspicious of a silhouette against a light texture but not the shadow of someone who clearly doesn't want to be seen?

 

The "silhouette" (the whole body) blocks all the sparse light of the moon or distant candle reflected on the wall, so the wall behind cannot be seen; a shadow on the wall would be much more soft, transparent and shapeless (btw, the player is not under the effect of a light source in this case, so he is not projecting a shadow [at least not an easily visible shadow]).

The amazing shadows we see on doom3 engine arent real (despite I like it very much) if you see how shadows really are, they are smooth and shapeless "the more far they go" (the light go actually).

So the silhouette is a much better clue than a shadow that can be from an animal, from another guard, from a window opening, from a tree on wind, from a curtain, anything; mostly undistinguishable if such shadow moves fast; UNLESS... the guards are already aware of the enemy presence, then a shadow would have more value!

 

Also the guard doesnt know the player doesnt want to be seen!

In the point of view of a guard, that shadow can be from anyone, even another guard; it is not shapeless, but it does not provide detailed information to make the guard sure it is a foe shadow.

Edited October 29, 2014 by Gussak

[Airship Ballet]

a shadow on the wall would be much more soft, transparent and shapeless

Not in a dark exterior lit by the wall lamps. When it's that close, a shadow is bound to be thick, large and obvious, especially if the lamps are low on the walls.

Also the guard doesnt know the player doesnt want to be seen!

I'd like to think that if I was on guard duty and saw a crouched shadow growing at an intersection with its owner making no noise I could hear, I'd suss them out as a thief. Depends on my sobriety, really.

[OrbWeaver]

Both light and dark on a texture, could provide 50% chance of NPC getting suspicious, it could be marked HalfLIghtTexture (no need to be precise).

 

How are textures going to be "marked"? As far as I know the engine does not provide any mechanism for associating extra metadata with textures, so somebody is going to need to implement this, and also go through every texture in every map providing the necessary information, which would be immensely time-consuming.

 

Furthermore, the "lightness" of a texture isn't a static property of a particular texture but also a function of the light falling on it (which can vary in real-time based on the motion or behaviour of in-game light sources), so even if somebody spent the necessary hours implementing this feature the results would most likely be unpredictable and generally inadequate.

 

Like Springheel said, proper silhouette detection would be tricky to implement, and cheap tricks are not likely to work well enough to be worth spending time on.

[Gussak]

How are textures going to be "marked"? As far as I know the engine does not provide any mechanism for associating extra metadata with textures, so somebody is going to need to implement this, and also go through every texture in every map providing the necessary information, which would be immensely time-consuming.

This could use some algorithm to guess the average light level stored on texture pixels. I thought not store that metadata on textures but on geometries/meshes (even if the information is actually exclusively based on texture), or there could have a table saying what texture id has what light level.

 

Furthermore, the "lightness" of a texture isn't a static property of a particular texture but also a function of the light falling on it (which can vary in real-time based on the motion or behaviour of in-game light sources), so even if somebody spent the necessary hours implementing this feature the results would most likely be unpredictable and generally inadequate.

Very good point, this must be rethought...

 

From NPC view, what matters? the contour. So the player silhouette is blocking the diffuse reflected light that comes from the wall.

I dont believe the engine could provide dynamic light information based on that spot on the wall behind the player tho.

But... instead of all this mess... what about creating a small "Projected light receiver Ghost Sphere" (PGS)?

 

The PGS would work like this:

Cast a ray from NPC thru player head, where it hits the wall, the small PGS would be moved there.

That PGS, would be invisible to us, not rendered, but would still receive light. If the PGS is lighted enough to be seen (like the player would from low to high light levels), the NPC would get suspicious and walk towards the last place the PGS was last seen, not towards the player. So if the player moves away, the NPC will just go thru.

Interestingly enough, this is a completely different idea, I am putting away the texture light data idea, thanks for pointing out the complexity of dynamic light levels!

I think the algorithm that lights up the player can be almost completely reused on this. It would also require one PGS per NPC.

 

Like Springheel said, proper silhouette detection would be tricky to implement, and cheap tricks are not likely to work well enough to be worth spending time on.

I think the new PGS idea may be much more easy to implement

 

Not in a dark exterior lit by the wall lamps. When it's that close, a shadow is bound to be thick, large and obvious, especially if the lamps are low on the walls.

 

I'd like to think that if I was on guard duty and saw a crouched shadow growing at an intersection with its owner making no noise I could hear, I'd suss them out as a thief. Depends on my sobriety, really.

I just thought, the PGS idea could work with shadow projection too in some way, think about it, it would be one PGS per light source! This PGS would be special to not receive the shadow of the player so it can be lighted from the very same light source it was created, and if NPC sees it, he will get suspicious!

Edited October 29, 2014 by Gussak

[OrbWeaver]

Cast a ray from NPC thru player head, where it hits the wall, the small PGS would be moved there.

That PGS, would be invisible to us, not rendered, but would still receive light. If the PGS is lighted enough to be seen (like the player would from low to high light levels), the NPC would get suspicious and walk towards the last place the PGS was last seen, not towards the player. So if the player moves away, the NPC will just go thru.

Interestingly enough, this is a completely different idea, I am putting away the texture light data idea, thanks for pointing out the complexity of dynamic light levels!

I think the algorithm that lights up the player can be almost completely reused on this. It would also require one PGS per NPC

 

This is much closer to what you would need to do to make this work, and is in fact very similar to the current lightgem algorithm, which renders a white diamond-shaped mesh at the player position and determines the incident light based on the rendered output.

 

The problem with this approach is that it is very costly in terms of rendering performance. Each "mini-render", although at a low resolution, still requires the processing of visible geometry, shadow volumes and light textures as if you were rendering a regular frame. There are already two such additional renders for the light gem, so if you have 6 AI in an area and each of them requires a "ghost sphere" to be rendered you are going to be drawing 8 frames in total for every frame displayed to the user, which is going to produce a noticeable performance hit even on a fast GPU.

[New Horizon]

Each "mini-render", although at a low resolution, still requires the processing of visible geometry, shadow volumes and light textures as if you were rendering a regular frame.

 

The mini-renders only capture a top and bottom shot that is cropped tightly around the diamond shaped model. I believe it's a 32 x 32 square? I don't think any of the visible geometry is taken into account. Might be wrong about that though, but that's all I ever saw when I was testing years ago.

[OrbWeaver]

The mini-renders only capture a top and bottom shot that is cropped tightly around the diamond shaped model. I believe it's a 32 x 32 square? I don't think any of the visible geometry is taken into account. Might be wrong about that though, but that's all I ever saw when I was testing years ago.

 

I wouldn't expect to actually see other geometry in the lightgem render because the camera view is cropped tighly to the (opaque) diamond model, so level geometry would only be visible if it actually entered the field of view between the camera and the diamond, which is unlikely unless noclip was activated and the player was actually intersecting something. It is certainly possible that the rendering of level geometry is deactivated altogether though; I wasn't involved in writing this code so don't know all of the details.

 

However the rendering of shadows can't be disabled, because you need to know whether the player (and the "ghost spheres") are in shadow or not, which means that the calculation of shadow volumes (for dynamic lights; I believe it is pre-calculated for static lights) and the rendering of shadow volumes into the stencil buffer must be done for each render pass. I wouldn't want to imagine the performance impact that multiplying shadow calculations by the number of AI in the room would have on my fairly average graphics card, although maybe it isn't such a problem on high-end hardware.

[Gussak]

The problem with this approach is that it is very costly in terms of rendering performance. Each "mini-render", although at a low resolution, still requires the processing of visible geometry, shadow volumes and light textures as if you were rendering a regular frame. There are already two such additional renders for the light gem, so if you have 6 AI in an area and each of them requires a "ghost sphere" to be rendered you are going to be drawing 8 frames in total for every frame displayed to the user, which is going to produce a noticeable performance hit even on a fast GPU.

The AI doesnt need updated data for the projected ghost diamond (PGD ) on every frame.

What about create a background queue process to deal with it? (so the user machine will handle the queue as much as it can).

Alternatively to the queue, the NPC could receive this updated data once each 0.5s (or even 1s), so many frames could be skipped for its calculations; and the calculations could happen interpolated too (do not calc all of them on the same frame, skip some frames between each one of them being calculated).

[Springheel]

That PGS, would be invisible to us, not rendered, but would still receive light. If the PGS is lighted enough to be seen (like the player would from low to high light levels), the NPC would get suspicious and walk towards the last place the PGS was last seen, not towards the player.

 

The technical hurdles in implementing such a system aside, I have no idea what this would achieve, other than forcing the player to become aware of his surroundings in a fashion that is unrealistically awkward in an artificial 3d environment.

 

You've walked down a long hallway, slipping from shadow to shadow, when a guard at the end of the hallway turns to look your direction. Are you safe or do you have to move?

 

Our system: Check your lightgem--oh crap, you're on the edge of detection, better crouch.

 

This system: Check your lightgem, then wonder whether somewhere behind you down the hall is a lit area that happens to be directly behind your head. Swing the mouse to turn and look around behind you--there are a few bright spots, but now you can't see exactly where the guard is standing, so swing the mouse to look the other way again to try and line it up as he walks your direction....will crouching line your head up with a bright spot on the floor behind you? Better turn around and check.....etc.

[Tels]

The technical hurdles in implementing such a system aside, I have no idea what this would achieve, other than forcing the player to become aware of his surroundings in a fashion that is awkwardly unrealistic in an artificial 3d environment. You've walked down a long hallway, slipping from shadow to shadow, when a guard at the end of the hallway turns to look your direction. Are you safe or do you have to move?

 

Our system: Check your lightgem--oh crap, you're on the edge of detection, better crouch.

This system: Check your lightgem, then wonder whether somewhere behind you down the hall is a lit area that happens to be directly behind your head. Swing the mouse to turn and look around, but now you can't see where the guard is, so swing the mouse to look the other way again to try and line it up as he walks your direction....will crouching line your head up with a bright spot on the floor behind you? Better turn around and check.....etc.

 

This could only work if there was a second lightgem (or the lightgem has two sides or takes the silouette into account). Then a quick glance a the lightgem would tell you.

 

It would still be quite complicated - how do you slip from a dark room into a dark corridor, if behind that one is another one leading to abright room? Not only could you not hide in the dark corridor (breaking a lot of maps Iguess) but also the player would somehow need to know about that and take it into account.

 

I see no chance for that feature to become useful for gameplay, technical difficulties aside...

[grayman]

I'm going to weigh in against this type of "move toward reality".

 

I doubt that any of this would provide a more satisfying gaming experience for the player. It's fun to discuss the technical aspects, sure, and to debate back and forth the best way to do it, but in the end, does it really enhance the game? I don't think so. There are a thousand things we've done to make the game as realistic as possible, but there are a gazillion things we haven't, and I'd rather focus our limited development hours on what's obviously broken.

 

Whether the player is backlit or not--and thus exposed--is one of those gazillion.

[Gussak]

The technical hurdles in implementing such a system aside, I have no idea what this would achieve, other than forcing the player to become aware of his surroundings in a fashion that is unrealistically awkward in an artificial 3d environment. You've walked down a long hallway, slipping from shadow to shadow, when a guard at the end of the hallway turns to look your direction. Are you safe or do you have to move? Our system: Check your lightgem--oh crap, you're on the edge of detection, better crouch. This system: Check your lightgem, then wonder whether somewhere behind you down the hall is a lit area that happens to be directly behind your head. Swing the mouse to turn and look around behind you--there are a few bright spots, but now you can't see exactly where the guard is standing, so swing the mouse to look the other way again to try and line it up as he walks your direction....will crouching line your head up with a bright spot on the floor behind you? Better turn around and check.....etc.

 

This is a good time to ask for another move to the player: the prone on floor position. This would prevent the silhouette being perceived, considering all guards are always standing! Around the lightgem there could have a glow that indicates your silhouette was perceived, if you do not prone, on the 3rd glow (one per second), the guard that was suspicious will come to investigate, otherwise he will say "nah, that was nothing..." and continue moving the way he was before.

 

This could only work if there was a second lightgem (or the lightgem has two sides or takes the silouette into account). Then a quick glance a the lightgem would tell you. It would still be quite complicated - how do you slip from a dark room into a dark corridor, if behind that one is another one leading to abright room? Not only could you not hide in the dark corridor (breaking a lot of maps I guess) but also the player would somehow need to know about that and take it into account. I see no chance for that feature to become useful for gameplay, technical difficulties aside...

 

Go prone on floor (the new asked feature),

or (another feature) put your body against the wall, touching it, lean on the wall (having somewhat the same effect as being prone, just less effective),

and finally look around if you can crouch again to be able to move faster, or sneak slowly to a safe place, or throw something to distract them. Anyway you have 3 glows (see above) before having to prone, may be enough to go into another room and change tactics, or just move from room to room, timely.

 

I think it could be cool in gameplay (and could be disabled too, call it ultra-hardcore or something), as long the player understands how he was detected it is ok, and he will have to learn how to play on this new mode only if he wants, because it will be much more challenging! The lightgem extra glow could be called something like "silhouette detection" even if it is not perfect detection, it would be good enough.

 

I'm going to weigh in against this type of "move toward reality". I doubt that any of this would provide a more satisfying gaming experience for the player. It's fun to discuss the technical aspects, sure, and to debate back and forth the best way to do it, but in the end, does it really enhance the game? I don't think so. There are a thousand things we've done to make the game as realistic as possible, but there are a gazillion things we haven't, and I'd rather focus our limited development hours on what's obviously broken. Whether the player is backlit or not--and thus exposed--is one of those gazillion.

 

Please do focus on what is broken!!!

Just keep that idea in mind, it will make the game much more challenging! May be while you are browsing the code you find some way to put it on work easier than we are able to actually discuss about it

Edited October 30, 2014 by Gussak

[stumpy]

what happens if the guard has reduced sight, or blind, or drunk, or, it just seems to be make the game harder then real life. you couldn't even detect someone's head silhouette in real life, it would just be a slight blur darker than normal due to scattered light, does the players head actually cast a shadow, as far as I know most lights are projected lights with a shape already defined in them, does the player actually have a shadow when in these lights. Pretty sure this would make the game unplayable for low end machines.

[161803398874989]

Just keep that idea in mind, it will make the game much more challenging!

Have you actually been playing the game on the hardest difficulties? It's challenging as fuck!

[Springheel]

This is a good time to ask for another move to the player: the prone on floor position. This would prevent the silhouette being perceived, considering all guards are always standing!

 

Aside from the massive effects such a thing would have on existing gameplay, your second statement isn't even true. Guards can be sitting or lying down, and even if they're not, the player can be, in multiple examples, directly in line with a standing AI's eye level (one example is if they are crouching on top of a piece of furniture).

 

I'm not sure you're thinking through the ramifications of these suggestions.

[Gussak]

what happens if the guard has reduced sight, or blind, or drunk, or, it just seems to be make the game harder then real life. you couldn't even detect someone's head silhouette in real life, it would just be a slight blur darker than normal due to scattered light, does the players head actually cast a shadow, as far as I know most lights are projected lights with a shape already defined in them, does the player actually have a shadow when in these lights. Pretty sure this would make the game unplayable for low end machines.

 

Is there such information (reduced sight, blind and drunk) as game data that could be applied to decrease the silhouette PGS perception chance? it would work very well!

 

Only the head, is just to make the coding easier, and keep low the cpu use; my initial thought was: head, each shoulder, middle of torso, groin, hands, elbows, knees and feet. But I giveup promptly.

 

We are actually focusing on the player silhouette, in this situation there is no player shadow in game (the player is already positioned in a non illuminated area, so the lightgem is completely darkened). Just think like the player is preventing the light behind it reaching NPC's eyes, the reflected light on the wall that lights the wall, then suddenly NPC sees a silhouette, that's it. It is not a perceiveable shadow, it is more like blocking the light (irl would have an almost unperceiveable shadow tho). Well, even if the player does not project a shadow in game, it does irl, and we think that way, tho I believe it is disabled to not encumber cpu and not make player think the shadow may affect NPC detection.

 

For low end machines (mine is an almost 10 year old 4core with old gfx 512mb card, but still runs the game smoothly), I suggested to not calculate the NPC perception data on each frame, it could skip some frames, calculate each NPC PGS data on a different frame, or even make a background process with a queue if possible, so the user machine would make the calculations as much as it can.

 

Have you actually been playing the game on the hardest difficulties? It's challenging as fuck!

 

Yes, I put all game options on the hardest mode.

And each map/level/mission I usually always opt for the hardest difficulty.

Sometimes I dont have patience and just fast sneak and fight thru the mission (the mumies/zombies requires too many strikes, but it is fun ). But I usually like to go sneaking all the time , and I miss being able to collect spider poison to poison arrows .

I am not saying it is not challenging, I just want even more challenge in this specific matter: NPC detection AI.

 

Aside from the massive effects such a thing would have on existing gameplay, your second statement isn't even true. Guards can be sitting or lying down, and even if they're not, the player can be, in multiple examples, directly in line with a standing AI's eye level (one example is if they are crouching on top of a piece of furniture).

 

I'm not sure you're thinking through the ramifications of these suggestions.

 

Massive effects on gameplay is good if it will bring more fun on, if it will prevent ppl think like @bedhead said "Sometimes im standing in a shadow thats in the middle of a bright hallway thinking this can't be right."! but we move on because the game is still very cool, good looking and fun!

It if proves to provide consistent and really good gameplay improvement, all missions will have their replay value increased!

Make it as alpha option, players can enable or not! (I will!)

 

Sat guards still have their heads very high, the ray from it thru player head, would still mostly hit the floor and so does not provide detectable silhouette.

I played several missions and do not remember any guard watchfully lying on floor (mind pointing where I can find such?), but I saw many on beds, but they were slept (even if they were reading books, they would still be careless).

I actually thought we could be prone and a guard is just climbing the stairs and see us for a moment, in this case, the lightgem would have its (newly suggested) reddish outer glow flash (player silhouette detection indicator), when we would have to move before the 3rd flash. Other than that, staying prone on an unlit place is perfect to prevent silhouette detection.

 

About climbing on tables: the whole point is the light on the wall behind the player. If the table is in the dark and the wall behind has a torch, we will come exactly to the new challenging gameplay mode I am suggesting! the player will have its lightgem new suggested outer reddish glow flash til 3 times so he can move away! , he should just not be there! or... water out the torch!

 

About climbing on shelves... well... particularly I think these shelves should crumble in peaces and hurt the player. But considering they are strong and stable enough, even then, it would only be a problem if the wall behind has light on it, the new gameplay way and so on, otherwise he can stay safely there.

 

Thanks on helping me think on all the ramifications!! (even if I hadnt completely yet, just point more out)

Edited October 30, 2014 by Gussak

[stumpy]

The game doesn't even render the players head or body as a shadow, it makes shadows from other objects, but not the player. the only time you can see a shadow is when the player is looking at themselves in a mirror in game and then the reflection in the mirror casts a shadow in the mirror, but the player in the game still does not cast a shadow.

 

Edited October 31, 2014 by stumpy