Jump to content
The Dark Mod Forums

Hiding behind a bush


RPGista

Recommended Posts

I was taking a look at a gameplay video yesterday and saw something that caught my eye, how the player could hide behind bushes and stay hidden. I would assume its a more vulnerable hiding spot, because of all the open spaces between leaves and branches, but a dense bush should work quite well as cover.

 

Is that accounted for in TDM? Do alpha images hide the player from AI vision behind its opaque areas? Because if they dont, wouldnt hiding behind bushes support be a cool addition to the game? I was thinking that maybe we could use a simple trick - use an entity exactly like a omni light box, that instead of lighting the area, will block the AI vision the closer it is to the center. This means you would be harder to see the closer you are to the center of the bush (either inside the brush, or behind it), less so toward the edges. You could place this entity on any brush big enough to hide the player (hes pretty small when crouching), and now players would be able to use them, or a tree top, as efficient cover.

 

It would also be lovely to have those little leave sounds you make when walking inside the branches, alert close by AI...

  • Like 2
Link to comment
Share on other sites

The AI doesn't see through alpha images, so technically you can hide in a bush if it is large enough. Unfortunately it's not dependent on how thick the leaves are, just the size of the polygons.

Link to comment
Share on other sites

I thought about that idea, too. My imagination was that one one side the bushes would provide you cover, one the other side though they would cause noises if you move through them. So they are good when trying to hide from guards who are relatively far away, but are bad if the ai is close and you have to move.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I was taking a look at a gameplay video yesterday and saw something that caught my eye, how the player could hide behind bushes and stay hidden. I would assume its a more vulnerable hiding spot, because of all the open spaces between leaves and branches, but a dense bush should work quite well as cover.

 

Is that accounted for in TDM? Do alpha images hide the player from AI vision behind its opaque areas? Because if they dont, wouldnt hiding behind bushes support be a cool addition to the game? I was thinking that maybe we could use a simple trick - use an entity exactly like a omni light box, that instead of lighting the area, will block the AI vision the closer it is to the center. This means you would be harder to see the closer you are to the center of the bush (either inside the brush, or behind it), less so toward the edges. You could place this entity on any brush big enough to hide the player (hes pretty small when crouching), and now players would be able to use them, or a tree top, as efficient cover.

 

It would also be lovely to have those little leave sounds you make when walking inside the branches, alert close by AI...

Like Springheel said the AI doesn't see trough alpha textures, even if the player would be obviously visible behind or inside a alpha tested object, for rustling sounds is just a matter of detecting if the player is touching the object, and then triggering a sound.

 

There's plenty of ways you can do that, for example using a trigger on the editor, using a script with $entity.distanceTo($player1) or even with $entity.touches($player1), etc.

The AI doesn't see through alpha images, so technically you can hide in a bush if it is large enough. Unfortunately it's not dependent on how thick the leaves are, just the size of the polygons.

This could be solved, if the AI vision was capable of per pixel testing instead of per-polygon, so they could discard invisible pixels from the vision calculations, but i'm sure this would be really really bad for performance.

 

If some day someone does a game where the AI is calculated "in the cloud" instead of the client PC, using a neural-net then this would be perfectly possible. ;D

Edited by HMart
  • Like 1
Link to comment
Share on other sites

I want to say that after playing through MGS 3 and Crysis I feel like bushes just don't feel right, along with tall grass, unless you have some sort of prone and crawl function to pair them up with.

This deep into the mission list I don't feel like a prone or crawl would be practical to add in, to say the least, but I wouldn't mind it either.

I like to record difficult stealth games, and right now you wonderful people are the only ones delivering on that front.

Click here for the crappy channel where that happens.

Link to comment
Share on other sites

Another approach would be to handle alpha-tested surfaces as semi-opaque. So if the player would be visible through them the amount of alert added to the ai gets halfed for example, or the lightgem value taken into account gets reduced by a specific value. This way ai could see the player hiding in bushes, but after a much longer time and probably only at a certain distance and if it is bright enough.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Would it be possible to make the bushes invisible for AI and then adding some sort of "shadow light", that reduces the lightgem-value, but is not visible for the player? This would adjust the lightgem value, giving a visual clue to the player how well the bush hides him, and would enable the mapper to choose how well a bush hides the player, by adjusting the value of the "shadow light". This in turn can be adjusted to the visisble density of the bush.

Link to comment
Share on other sites

Would it be possible to make the bushes invisible for AI and then adding some sort of "shadow light", that reduces the lightgem-value, but is not visible for the player? This would adjust the lightgem value, giving a visual clue to the player how well the bush hides him, and would enable the mapper to choose how well a bush hides the player, by adjusting the value of the "shadow light". This in turn can be adjusted to the visisble density of the bush.

I don't see why it would not be possible but a "shadow light" is really not on the engine so anyone would need to implement one at the engine code level, perhaps using a blend light could work?

 

Btw thinking about this subject of hiding on bush's, i have a idea for a script, don't know how feasible it is tho.

 

Like was said you can already hide in a large enough bush, but is all or nothing, so if I wanted to simulate bush density or hiding amount, this probably would work:

 

First i would define a special bush entity (using a entity def file), where i would put all the necessary variables that i needed, for example a bush density value.

 

Second i would make a script to control it, warning, you or anyone reading this needs to know basic scripting/coding to understand this, ok lets go on, on that script i would define a new game object ( object specialBush{...}; ) then write code to detect if the player is inside it:

 

I think this calc would demand a loop running every frame, so to save on performance i would instead use a trigger that i would bind to the bush entity on the editor:

 

pseudo code ahead:

 

if player triggers the trigger do
  if self.distanceTo(&player1) == 0 and self.distanceTo(&player1) < self.getsize() do // zero means you are exactly at the center of the bush model, getsize() gets the size of the Bounding Box of the model so we don't waist time running the code if the player origin is outside the model
     bush_density = self.getfloatKey("density");
     if bush_density > 0 and bush_density < 100 do
         // if possible
         lightGem.addValue(bush_density);
         // else
         if bush_density == 50 and nearest enemy is looking at bush 
            enemy.raiseAlert
         end
         else if bush_density < 50 and nearest enemy is looking at bush 
            enemy.canSee(player);
         end
         else player is totally hidden end
     end
     else if bush_density <= 0 or bush_density > 100 do
         error density should never be 0 or more than 100 // for example
     end
  end
  else do nothing and wait end
end

I'm sure the logic could be improved but this is what i can think of at the moment, hope it makes some sense and helps someone. :)

Edited by HMart
Link to comment
Share on other sites

Shouln't it be "lightGem.addValue(-bush_density)"? The way you wrote it, a denser bush would add to the light gem brightness and, consequently, increase visibility. Also, I would not add/subtract a value from the lightgem, but rather multiply it with it. So, you would have clampVal = clampVal * (bush_density/100). That way a density of 50 would automatically half the chance of being spotted while in the bush. clampVal is the probability of being seen, see the Visual scan Wiki article. The only thing, I am not sure about is, if it is possible to directly manipulate the clampVal via script.

Link to comment
Share on other sites

If you have a lot of brushes you would have a lot of triggers, too, which isn't very good in regards to performance (triggers perform a distance check to the player every frame).

 

Messing with calculated values afterwards might be a messy approach. In addition, you will most often have the situation of the player standing behind a bush, so that he is partially disguised seen from the front, but not from the back. Or there may be a varying amount of bushes between the player and ai in different directions. In addition, abush should not only block the view if you are standing inside it. It should also block the view if you are a few meters behind you, as long as the bush is in line of sight it will disguise you.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

The best way to do this would be my dream of multiple, random traces from the AI, that would allow for the player benefiting from partial cover. But that's not a very realistic thing to expect.

Link to comment
Share on other sites

You could set it so that a special mtr for these bushes would have a keyword that would notify the ai code that when doing a trace for the player, to ignore the polys painted with this texture, and have a reduction in player visibility due to being in the bushes.

So due the normal visibility check, and just reduce the value by a certain amount. Hackish for sure, but it could work.

  • Like 1

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

Shouln't it be "lightGem.addValue(-bush_density)"? The way you wrote it, a denser bush would add to the light gem brightness and, consequently, increase visibility. Also, I would not add/subtract a value from the lightgem, but rather multiply it with it. So, you would have clampVal = clampVal * (bush_density/100). That way a density of 50 would automatically half the chance of being spotted while in the bush. clampVal is the probability of being seen, see the Visual scan Wiki article. The only thing, I am not sure about is, if it is possible to directly manipulate the clampVal via script.

 

You are right, my pseudo code was something i wrote in the moment and was not really well thought out, was just a direction to follow nothing more. :)

 

If you have a lot of brushes you would have a lot of triggers, too, which isn't very good in regards to performance (triggers perform a distance check to the player every frame).

 

Messing with calculated values afterwards might be a messy approach. In addition, you will most often have the situation of the player standing behind a bush, so that he is partially disguised seen from the front, but not from the back. Or there may be a varying amount of bushes between the player and ai in different directions. In addition, abush should not only block the view if you are standing inside it. It should also block the view if you are a few meters behind you, as long as the bush is in line of sight it will disguise you.

 

Hum didn't knew triggers performed a distance check every frame? Are you sure about that? I always thought they just checked for collision.

 

Yes the player behind the bush is a problem in that case, but i can also think of a solution to that problem, just do a visual check by the AI, if a bush or various are on the line of sight, check if player is inside any of them, if it is, disable polygon checking for that bush and permit the usage of something like i said above if not use the normal view check, of course all of this will make the AI visual system more complicated and demanding not sure if the custe /benefit is good.

Link to comment
Share on other sites

Its always interesting to see how a simple idea can generate so many problems that you had no idea at first. You just go "yeah, this would be cool!". :) I guess most of our problems are solved already - as springs says, the models themselves hide the player, so a denser bush or tree top will hide the player better than a sparse one. As it is, this will work most of the times. Still, you can have a case where you have a dense model that is actually depicting a few twigs, a very bare, dried bush, say, and that wouldnt hide you visually at all, but the geometry would still keep you invisible to the AI. So yes, I agree that if we could have a new arg where in DR you could say, this model will be from 0 to 1 transparent to AI (no visual change for the player), that would be awesome, you could set it up yourself, and not change anything in earlier maps. Or, if it could be aplied to the material alone, the leave alpha textures, even better, more accurate. This would be very interesting for any garden, forest map sections out there. But again, no idea how much work this means... Just something for our bright coders to munch over.

Edited by RPGista
Link to comment
Share on other sites

Another idea just came to my mind. Guessing we would use a spawnarg that determines how 'transparent' a brush is, as suggested by RPGista, we could let the bush only be taken into account as an visual obstacle every few frames. So if the value is 0.5 for example, the bush would be ignored every second frame. So in one frame the bush is there and hides the player, in the next frame the bush gets ignored and the ai get a visual stim by the player (increasing his alert level). And so one and so forth. If the transparency value is 0.25 the bush would be ignored every forth frame etc...

 

Might be simple enough to be implemented.

  • Like 2

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Yeah, I think transparent surfaces are skipped when performing the visibility check. At least I know that ai can see you through glass. Might be worthwhile to checkout anyways.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
    • Ansome

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 4 replies
×
×
  • Create New...