How to design "hiding" enemy AI for horror?

I studied a lot of theory on horror games and came to conclusions that unpredictable and unknown monster is the best monsters for a game. As for unpredictable I have a few ideas (like make a few behavior patterns and switch between them randomly to confuse the player)
But I can't figure how to design the behavior itself. I want the enemy to not just patrol&chase the player, but rather be somewhere near and intimidate the player from some distance (like peeking from a corner, switching lights in other room, interacting with doors, etc)
Is it possible to design such behaviour and somewhat maintain unpredictable factor?

 

Sure!

But personally I'm not a fan of behavior trees or scripted behavior patterns... I'm a Utilitarian (at least when it comes to AI). I'd define utility for the various things a monster can do. In this case it would include: operating doors which are near (but out of sight of) the player; making noises behind the player; making noises in dark places near the player; lurking silently; etc. And probably give a higher value to things it hasn't done recently.

Then the utility AI will gather up all the possible things it could do, and pick the best one considering the value and how easily/quickly it can do it.

 

@JoeStrout: Basically everything a behaviour tree can do just without the tree?

 

A non-deterministic tree. A stochastic tree.

 

Wait, afaik any AI is fundamentally a behavior tree. Is there another technique for making AI? I don't quite understand what this or non-deterministic AI means

 

Sorry, my reply isn't exactly what they were referring to, but I think Joe was referring to something like "utility" AI.

 

No. Most AIs can be represented as a sufficiently complicated behaviour tree, but that's not the same thing. Otherwise you may as well consider them all to be arbitrary code, and just write them as straight C#.

We don't do that for complicated behaviours because it makes the implementation and iteration time too long to get good results efficiently. And that's really the benefit of a behaviour tree, state machine, utility evaluator or whatever other tool gets you: approaches and workflows which help you get results more quickly, in ways accessible to more of your team (ie: non-programmers).

Ultimately you could have coded the same thing up by hand. And in most cases you could get identical results with a different approach. But that's really not the point.

 

Got it. Stand in the same place and turn the light on and off forever

 

Thought this might be helpful:
https://amp.reddit.com/r/Unity3D/comments/nf5nff/the_shy_ball_tutorial_is_out_its_about_an/

 

@Vefery
You could probably use triggers for that sort of thing.