Let�s develop: Monster Sight Calculation

[Sphagne]

Let’s develop: Monster Sight Calculation

-------------------------------------------------------

Preface:

As this is the first post of its kind, I would like to add some info here:

Here is a test, to see if this kind of approach would fare better than my last approaches.

In this kind of threads, we can suggest our features as a cooperative event in which, we want to develop a feature ourselves (as teamwork) and when done, offer it to Randy to see if he would accept them.

It would require a volunteer programmer that has enough time to spend on it and likes the idea enough to decide to join in, and other people can join in with their ideas, solutions, or any other comments, but please let’s keep them organized enough to be able to complete the features.

I know at first, it may look a bit daunting, but after that, it would find its pace, and hopefully would become promising enough for Randy to decide to join in and help us along.

Oh, yes, I will update this first post to include our progression of ideas and actions.

-------------------------------------------------------

Info:

With this feature, we want to infuse some stealth factor into our levels, i.e. if you stay in the dark areas it would be harder for monsters to see you than light places, and the nearer you go to them the more likely it is that you would be seen.

-------------------------------------------------------

Result:

If this feature is fully implemented:

There would be no change in the gameplay for current available levels, unless the player specifies in an options menu to activate it for all the levels.

There would be a MAPINFO entry, which would let us activate the stealth factor for our levels.

When activated for a level, monsters would see other actors depending on their distance and the light level of the target actor’s sector, and their “Sight” power, and the target’s “Visibility” factor.

There would be two additional DECORATE parameters for each actor: Sight and Visibility.

Finally, Adding two additional actor properties to help us manage this feature, like decreasing the player’s visibility factor as he uses the cloaking device.

Optional: When a monster is still unaware, its sight power is decreased by a factor.

Optional: When an actor is moving, its visibility factor is increased, depending on the movement speed.

Optional: When an actor is in its “Full Bright” frames, its visibility factor is temporarily doubled, like lost souls or firing frames of normal actors.

Optional: When an actor is shown fuzzily, its visibility factor is temporarily halved, like specters, or blur-spheres.

Optional: When an actor is shown transparent, its visibility factor is decreased accordingly.

Optional: Stealth monsters, are totally hidden, when not shown, (I don’t know if it is hard to implement, or if it is such a good idea)

Optional: Try to include Caligari_87’s suggested chance percent in the visibility formula.

Complexity: low to moderate, but with each optional feature, a bit more complex.

P.S. Any suggestions for additional features?

-------------------------------------------------------

Detail:

Thanks Graf for the info:

We need to change the function "P_CheckSight", which is the place that all the LOS (Line of Sight) calculations are done.

It is called before the actors “See” their target and wake up, and before they attempt an attack on the target, and before “A_Refire” would decide to cease fire for chain gunners and the like, and when we want to search for an actor.

The LOS check would decide if the actor can see it’s target, i.e. whether it is blocked from the sight by the geometry or not, and would give the result of TRUE if the target can be seen.

Our task would be to add the Visibility check after the LOS check to decide if the target is close enough to the actor to be seen.

For this reason we can add the visibility check inside the “P_CheckSight” function but would only check it if the target is not already blocked from the actor’s sight.

Thus, if the function’s result is already FLASE, then the target is already blocked from the view, so there is nothing to do, thus we would branch out of the function.

But if the target is not blocked, i.e. function result is TRUE, we should perform the visibility check, and after that if we decide that the target should not be seen, then we change the function’s result back to FALSE, and that would do the job.

The end result would be that, if the target is further than the visible range, it is hidden from the actor’s sight, just as if it is blocked by a wall or something.

This means that the monster would not be awakened, or would not start an attack toward you, or the chain gunner would stop shooting toward you as you back away into the darkness.

However, at first, we would have to prepare the required parameters for the formula.

-------------------------------------------------------

Step 1:

We need to add two integer fields to our actors for their Sight power, and Visibility factor.

They would by default initialize to 100, unless defined differently in the DECORATE lumps, which as Graf says, is an easy task, so no problem here.

We would also need to add a global boolean variable that would toggle this feature ON or OFF. This variable should be defined from within the MAPINFO lump, but for now, we can initialize it to TRUE for the development’s sake.

-------------------------------------------------------

Step 2:

As Graf says, the “P_CheckSight” function is called from any place that the code wants a LOS calculation, and some of these calls may need the additional visibility check.

Thus, we can change the function and add another boolean parameter to it, to trigger the additional visibility check inside it, and it would automatically force the compiler to give an error on all the calls to the function, so it would be easy for us to find their places.

After that we can check the place to decide if it needs the additional check and if so we pass the function a TRUE, and otherwise a FALSE.

Inside the function, and after the original LOS check, we can check this boolean value to decide if the additional visibility check is required, and if so then we need another check as well, to see if the visibility check is actually enabled for the level or not.

For this reason, we need to check the variable initialized in the MAPINFO, and (or) it with the CVAR that would be defined in the option menus, and if the result is FALSE we branch out of the function.

After that, we can calculate this formula:

D = ( Sqrt(L*L*L) * S * V )/DF

D: maximum visible distance (in map grid units)
L: target sector light value (0-255)
S: actor sight factor
V: target visibility factor
DF: distance factor

DF should by default be probably something around 25000 for this formula, but the level designers should be able to change it via the MAPINFO command, (more on that later), thus, we can initialize it to 25000 by default, but it might change later via MAPINFO.

After calculating the maximum visible distance of the target actor, we can calculate the distance between the two actors, (in map grid units), and check if it is more than the maximum visible distance, and if so then the target is not visible to the monster, so we would change the result back to FALSE.

P.S. Any suggestion for a better formula is gladly accepted.

-------------------------------------------------------

Step 3:

The next step would be:

Add a new CVAR to trigger this check for all the current maps.

Add the options menu-item to let the users toggle this CVAR.

Add this CVAR to list of CVARs that are saved to the configuration file, if it is not automatically done.

After this stage, we can test our newborn feature in any current level.

-------------------------------------------------------

Step 4:

Add two new actor properties to the current list, like: APROP_Sight and APROP_Visibility.

-------------------------------------------------------

The next steps are currently under construction.

-------------------------------------------------------

Action log:

OK, now is the critical part:

Is there any volunteer programmer who likes to join in, so that we can develop this new feature?

I am sure that it is worth the effort, and the time spent on it, would not be a wasted time.

I know at first, it may look a bit daunting, but after that, it would find its pace, and hopefully would become promising enough for Randy to decide to join in and help us along.

Hey pals, this is not that complicated, and would not take a lot of your time. Don’t you want to say “I added stealth factor to ZDoom.”?

Thanks in advance.

[Graf Zahl]

Don't worry, I won't post any negative comment. This approach is definitely better and might even lead to results.
But I'd like to issue one warning: You are aware that all of this might be affected by Randy's float rewrite, aren't you?

Result:

If this feature is fully implemented:

There would be no change in the gameplay for current available levels, unless the player specifies in an options menu to activate it for all the levels.

There would be a MAPINFO entry, which would let us activate the stealth factor for our levels.

When activated for a level, monsters would see other actors depending on their distance and the light level of the target actor’s sector, and their “Sight” power, and the target’s “Visibility” factor.

There would be two additional DECORATE parameters for each actor: Sight and Visibility.

Finally, Some additional ACS functions to help us with managing this feature, like decreasing the player’s visibility factor as he uses the cloaking device.

Optional: When a monster is still unaware, its sight power is decreased by a factor.

Optional: When an actor is moving, its visibility factor is increased, depending on the movement speed.

Optional: When an actor is in its “Full Bright” frames, its visibility factor is temporarily doubled, like lost souls or firing frames of normal actors.

Optional: When an actor is shown fuzzily, its visibility factor is temporarily halved, like specters, or blur spheres.

Optional: When an actor is shown transparent, its visibility factor is decreased accordingly.

Optional: Stealth monsters, are totally hidden, when not shown, (I don’t know if it is hard to implement, or if it is such a good idea)

Complexity: low to medium, but with each optional feature, a bit more complex.

P.S. any suggestion for additional features?

-------------------------------------------------------

Detail:

My guess is: when the engine wants to decide if a monster can see an actor, it would check the BSP geometry or something like that to see if the target is blocked from the view of the monster.

The function is called P_CheckSight, located in p_sight.cpp and returns true when the monster can see the target and false when not.

This would happen before the monster jumps to the “See” state, before it jumps to “Missile Attack” state, and before deciding to cease fire for chain gunners and the like, and I do not know if all these checks are done in the same place or in their own different places. Hopefully, in the same place.

We can add another check after the geometry check, to add our sight calculation formula, and if the result were that the monster should not see the actor, we would behave exactly as if the actor is blocked by the geometry, i.e. as if a wall is blocking the actor.

All checks are in different functions but all call the same P_CheckSight function. Logically P_CheckSight is the point where you should hook in your code. But you should be aware that this function is also used for other LOS calculations so you'd have to add more flags to the existing flag parameter.

That means, that in the code, we should branch to the exact place that the failed geometry check would have branched away.

The result would be that the monster would not be awaken, or would not start to shoot at you, or the chain gunner would stop shooting toward you as you back away into the darkness.

If done in P_CheckSight and some flag use that will happen automatically. I don't think you need to modify anything but the calls themselves (it aren't that many but make sure you get all of them. Some are in code pointer functions - not only Doom but from the other games as well.)

Step 1:

We need to add two integer fields to our actors for their Sight power, and Visibility factor.

They would by default initialize to 100, unless defined differently in the DECORATE lumps, which would come later.

Why later? Adding new properties to DECORATE is the smallest issue of all.

We would also need to add a global boolean that would toggle this feature ON or OFF, and in the current state we initialize it as ON, for the development.

Best use a CVAR or a MAPINFO option which are or'd. If one is true the feature is active, otherwise not.

We would search for and find all the places that the level geometry is checked to see if the target is blocked away from the monster’s sight, and if they are in separate places and are exactly the same, then we can extract them and place them in a separate function, and use that function in their place.

Here's the list of functions:

p_enemy.cpp
bool AActor::CheckMeleeRange ()
bool P_CheckMeleeRange2 (AActor *actor)
BOOL P_CheckMissileRange (AActor *actor) // this is the most important one!
AActor *LookForTIDinBlock (AActor *lookee, int index)
BOOL P_LookForTID (AActor *actor, BOOL allaround)
AActor *LookForEnemiesInBlock (AActor *lookee, int index)
BOOL P_LookForPlayers (AActor *actor, BOOL allaround)
void A_Look (AActor *actor)
void A_Look2 (AActor *self)
void A_Chase (AActor *actor)
void A_FastChase (AActor *actor)

p_interaction.cpp
bool AActor::OkayToSwitchTarget (AActor *other)

p_mobj.cpp
bool AActor::IsOkayToAttack (AActor *link) // only used by friendly Minotaur in Hexen

g_doom/a_archvile.cpp
void A_Fire (AActor *self)
void A_VileAttack (AActor *actor)

g_doom/a_possessed.cpp
void A_CPosRefire (AActor *self)

g_doom/a_scriptedmarine.cpp
void A_M_Refire (AActor *self)

g_doom/a_spidermaster.cpp
void A_SpidRefire (AActor *self)

g_Hexen/a_serpent.cpp
void A_SerpentChase (AActor *actor)
void A_SerpentWalk (AActor *actor)

g_Raven/a_minotaur.cpp
bool AMinotaur::IsOkayToAttack (AActor *link)

g_Strife/a_crusader.cpp
bool Sys_1ed64 (AActor *self)
void A_CrusaderRefire (AActor *self)

g_Strife/a_inquisitor.cpp
bool Sys1ED64 (AActor *self) // no idea why this is duplicated...

g_Strife/a_sentinel.cpp
void A_SentinelRefire (AActor *self)

g_Strife/a_stalker.cpp
bool AStalker::CheckMeleeRange ()

g_Strife/a_strifestuff.cpp
void A_TurretLook (AActor *self)

g_Strife/a_strifeweapons.cpp
void P_DaggerAlert (AActor *target, AActor *emitter)




-------------------------------------------------------

Step 3:

The next step would be adding the Menu item in the options menu to toggle this feature for any current map, and adding the means for this configuration option to be saved with other options, and initialize our global toggle variable depending on the option.

After this stage, we can test our newborn feature in any current level.

-------------------------------------------------------

No need to delay this. Just add one line of data to the menu you want this in.

[Tormentor667]

Great, this really seems to lead to a very useful result

[Sphagne]

Hey, Graf thanks for the help, it seems that it was only my previous style and atitude, that you disliked, sorry that I misjudged you.

As for the floting point problem, I do not think that would chenge the logic so much that would affect this part of the code, but the final reintegration of the new logic to the new code might require a bit more of work.

As for the list, well, none of "Look for" codes would require it, but all the attack initialization codes would need this, and all the chases and walkes, if they want to decide for an attack on the target (or heal it in the case of ArchVile), and also all the refire codes.

We can add another bool parameter to the P_CheckSight function that would trigger the additional stealth check, and this would automatically force the compiler to show us all the places that the function is used.

We can check the place and decide if we want the additional sight check at that place or not, and if not then we would pass the function a "False" value.

But if we want the check, then we would pass the new CVar or'ed with the bool value initialized via MAPINFO, and that would do the job.

OK, that's great, but the important question is, "Who would decide to do the job?", any volunteers?

P.S. Tormentor667, Maybe you are not a programmer, but you are definitely a good level designer, so you may have some good ideas, to add to the bunch, so don't leave us.

[Caligari87]

I posted a thread about this kind of thing a little while back. Graf has already said this would require a major re-write, but then again so would everything you proposed.

This is my personal idea for monster AI, and most of it duplicates your ideas. It's a little more fleshed out with numbers and examples, so if there's anything you like, go ahead and take it (with due credit, of course ).

BTW, I can't program C++ worth crap, so I couldn't really help with this. Hope it wouldn't be too much extra work.

(copied from my other thread...)

---

Proposal for Better Monster A.I. capabilities in DECORATE:

These modifiers for DECORATE would allow the creator greater control over his monsters.
For example, in a tactical mod, this would allow a smart player to draw enemies to one end
of a level, while circling back and coming in from behind. It would also make "stealth" mods
possible, as the monsters can be configured to ignore enemies that are in darker areas of the
level. The same applies to hearing. This can also be configured to make monsters that look
for the player, or monsters that forget about the player when they can't find him. I hope all
of these make sense.

NOTE:
lu = Light Units
mu = Map Units
au = Angle Units

Vision Modifiers: The monster would see the exact same as the player, and objects
not clipped to fadecolor would be visible, with these modifiers.
If none of these modifers are set, monsters see as normal. Setting one will set undefined modifiers to default values.

/ vision_amplifier x \ //x = Amount lightlevel is increased/decreased for monster's sight
\ vision_damper x / //example: *vision_amplifier 24* //Monster treats lightlevel of 160lu like 184lu.
//example: *vision_damper 24* //Monster treats lightlevel of 160lu like 136lu
//Default x=0

vision_threshold x //x=How visible enemy must be to be sighted, above color clipping.
//example: *vision_threshold 25* //enemy will be seen if it's brightness is at least
//25 percent above fadecolor clipping.
//Default x=0

vision_chance x //x=chance out of 100 of seeing enemy if above conditions are met.
//Default x=100


Hearing Modifiers: Fairly self-explainatory. Setting +AMBUSH makes these values useless.
If none of these modifers are set, monsters hear as normal. Setting one will set undefined modifiers to default values.

hearing_range x //x=maximum Range in mu that monster will hear sounds (weapons, falls, etc).
//Default x=512

hearing_falloff x //x=Range in mu below *hearing_range* that is subject to hearing_chance
//Default x=128

hearing_chance x //x=Chance out of 100 that sounds in *hearing_falloff* range will be heard
//Default x=50


Behavior Modifiers: These flags define how a monster will behave towards enemies and others.
The chase flags are mutually exclusive.
If none of these modifiers are set, monsters behave as normal.

persistence x //x=How many *A_Chase* steps monster will iterate through with anything
//other than *CHASE_STUPID*

look_change x //x=angle to change by when using *CHASE_RANDOM

search_raduis x //x=Radius to move around in when using *CHASE_SEARCH*

+CHASE_STUPID //If enemy is lost, monster will go to last place enemy was seen/heard, then
//go back into SPAWN state.

+CHASE_RANDOM //Monster will go to last place enemy was seen/heard, then
//continue on for *persistence* steps, changing direction by *look_change*
//degrees every SEE state. After *persistence* time is up, monster
//reverts to SPAWN state.

+CHASE_SEARCH //Monster will move in *search_radius* area for *persistence* iterations.
//Zero point is where the player was last seen.

+EMPTY_AVOID //Prevents monster from going into an area where it can see the whole room.
//For example, a bright dead-end hall with no alcoves and no enemies.
//If the hall has an opening, though, the enemy will continue down because it
//cannot see everything.

+REMEMBER //Doesn't pass over one area many times while searching.


---------------
EXAMPLES
---------------

ACTOR Realistic_Imp : DoomImp 10500 //Behaves intelligently and can see a bit better than player
{
Vision_Amplifier 16 //Sees 16lu above room lightlevel
Vision_Threshold 30 //Will see player if at 30% or more brightness above clipping
Vision_Chance 75 //A 75% chance of seeing player when above conditions met

Hearing Range 512 //Will hear sounds up to 512mu away
Hearing_Falloff 256 //Begins loosing clarity at 50% of hearing range
Hearing_Chance 80 //80% chance of hearing player if range > falloff distance

Persistence //Will iterate SEE state this many times while searching
Search_Radius 256 //Will randomly patrol a circle with a 256mu radius from zero
+CHASE_SEARCH //Initiates smart search behavior as described above
+WALL_AVOID //Only looks if it cannot see the whole area.
+REMEMBER
}

ACTOR Blind_Imp : DoomImp 10501 //Good hearing, but can't see jack. Wanders around a bit.
{
Vision_Damper 64
Vision_Threshold 95
Vision_Chance 25

Hearing Range 1024
Hearing_Falloff 768
Hearing_Chance 95

Persistence 5
Look_Change 8
+CHASE_RANDOM
}

ACTOR Deaf_Imp : DoomImp 10502 //Slightly better sight than Realistic_Imp, but can't hear anything
{
Vision_Amplifier 32
Vision_Threshold 20
Vision_Chance 90

Hearing Range 64
Hearing_Falloff 0
Hearing_Chance 25

Persistence 30
Search_Radius 128
+CHASE_SEARCH
+WALL_AVOID
}

ACTOR Realistic_Zombie : ZombieMan 10503 //Realistic means bad eyes, poor hearing, and pathetic intelligence
{
Vision_Damper 48
Vision_Threshold 60
Vision_Chance 75

Hearing Range 256
Hearing_Falloff 128
Hearing_Chance 50

+CHASE_STUPID
}

ACTOR Smarter_Zombie : ZombieMan 10504 //Searches around more, sees and hears slightly better
{
Vision_Damper 40
Vision_Threshold 55
Vision_Chance 80

Hearing Range 270
Hearing_Falloff 136
Hearing_Chance 55

Persistence 12
Look_Change 48
+CHASE_RANDOM
}

[Sphagne]

Hey, you have exactly my problem: "Some good ideas that you can not develop them yourself.", so why not start another "Let's develop" thread and try to persuade a programmer here to do them for you?

I want to start small, so I would try to do only the sight calculation fo rthe monsters, in this thread, but maybe when it is completed, we would figure out how to do the rest of your ideas, in other threads, after that. OK for you?

And your definitions for the sight calculation are more complex than mine, so I would wait to see if my formula is accepted, or not, then if it was implemented, and before it was official, we may try to change it to something like your suggestions.

Thanks for your suggestions.

[Sphagne]

So, no C programmer present, or interested, OK, another failure, I guess.

[Graf Zahl]

Patience!

There aren't that many programmers and most simply don't have the time to spend on something like this. But that can change.

[Hirogen2]

Let’s develop: Monster Sight Calculation
...lot of text...
Thanks in advance.

May I remind you that I think that you already have posted this. (I think it ended in "zombies see in the dark anyway" )

[Sphagne]

Remember it? That was about two year ago, but now I have decided to retry it with another method.

If an interested programmer would help me to finish this feature, we could offer it to Randy to see if he would include it in the next ZDoom.

By the way, as I remember, you were a programmer yourself. Dont you want to give it a try?

I dont think that it would waste more that two or tree weekends, to finish the first stages, to complete the feature, (without the optional features).

The guidelines at the first of this post are quite clear by now, and I do not foresee much problem there.

Please think about it.

[Cutmanmike]

If I was a programmer I probably would. However, code is still in the back of my brain.

[Hirogen2]

Remember it? That was about two year ago

Either I have a good memory, or two years pass fly-by. I still remember the NEURONS thing heh.

[Sphagne]

Please, dont remind me of that.

By the way, if I can persuade Randy to add "Use Specials" and also seperate "Hate Target" from "Destination Target" and give us the power to force monsters to "Use" other items, then all those "Neuron" thingies could be done right away.

Hey man, are you still enthusiastic about developing new features? This stealthy one is real practical, and ready for action.

[Hirogen2]

Enthusiastic? Not quite. A working linux port is missing to get me going. (Really, I do seem to start on everything I get. Last thing was openttd, wuftpd, and...things.)

I would not wonder if Sphagne would even propose the binary details of a new map format... sigh.

[Jim]

There is an unofficial patch by Chris that makes it work on Linux just fine.