How should I make followers AI in the FPS game?

[UnderRaBi]

(The context might be a little strange because I'm using a translator. If you don't understand what I'm saying, ask me right away.)

I'm going to make a single survival FPS game with Unity.

What I want is a followers in the form of L4D.
It's a very simple AI that follows the player and attacks when it finds an enemy.
There's no problem following the player, but I don't know how to script an attack.

1.Target the first found, that is, the nearest enemy.
2.If a targeted enemy dies, find the nearest enemy again.
3.If an enemy reaches (a certain distance) or is attacked in that state, it will replace the target with an enemy that has reached it immediately, even if it has not been targeted.
4.If you fall more than a certain distance from the player during a battle, ignore the enemy and head for the player.
I think this is the function of the battle.

The concern is how to measure the distance from the enemy and how to aim and shoot at the enemy.
I don't know how to implement AI's hit rate.
I don't know how to deal with this because simply setting the gunpoint direction to the enemy will get the gun's reaction perfectly.
The first thing that came to mind was the Burst.
I think slowing down the attack will avoid a mishap that will kill all of my colleagues, but it will make them seem too useless.
The second is to set the time for the enemy to face the gun.
Instead of keeping the order to aim at the enemy, it's a method of giving it over and over again every half a second.
If you shoot, it'll be shaken by the reaction, and I thought maybe we could make Am face the enemy again in half a second. Of course, half a second is an example. It can be 0.1 second or 1 second.
If you know the answer or any place to refer to, please let me know.

 

[Rich]

There's no generic solution to this, AFAIK, because it depends a lot on your specific game's needs. The four numbered items all sound reasonable.

how to measure the distance from the enemy

Not knowing your game, it seems there are actually two issues. How far away is the enemy? Well Cartesian distance is probably a good start. More important, can your AI see the enemy? Maybe it's around a corner. Trickier.

I don't know how to implement AI's hit rate.

Having the AI have a high hit percentage might not be a bad thing. After all, that's why you'd have an automated AI assistant, right? Because they'd be awesomely perfect? Instead of worrying about adjusting hit rate to deal with enemy survival, maybe adjust the impact damage. The MC might be carrying an inaccurate BFG, while the AI might be firing a much lighter gauge weapon. High hit probability, but not the same class of damage. Also, the AI might have a limited traverse rate, so there might be time between an enemy became visible and the AI could actually engage it.

Having weapon recoil take the AI off target and then having to re-acquire is, of course, another solution. But big recoil tends to imply big damage to me, so that might or might not work well.

Also, your AI might not be able to fire continuously. Three-round burst, delay, three-round burst, delay - something like that. (Maybe it doesn't reload quickly.)

At the end of the day, the key is not to have the AI be too god-like. The exact mechanism that you use to prevent this may not be all that important as long as there's some way you can justify it in the game. ("It's an early prototype, and has bugs. Sometimes it gets confused." Whatever. Basically, it's a game - you can suspend reality somewhat whenever you want to.)

 

[anne O'nymous]

More important, can your AI see the enemy? Maybe it's around a corner. Trickier.

Seeing will probably not be enough, there's also the question of accessibility, and the question of the effective range for the weapon.
If the enemy is beyond an unbreakable glass, or beyond wire mesh, it will be seen by the AI, but still can not been hit. Therefore the map could probably also carry some information regarding the this.
Same it the enemy is beyond a small wall or a small barricade. There will be times where it will be too far for a melee weapon, while being too near for a long range weapon.
And finally the enemy can be seen beyond the 5th floor window, but it will imply a really difficult angle.

Since the game is a survival one, those three cases will probably happen often.

Instead of worrying about adjusting hit rate to deal with enemy survival, maybe adjust the impact damage.

I would see something like RPG's rules, with both critical hit and critical fail values. The AI hit by default, because like you said it's why the player have a companion, and the accuracy is reflected by the inflicted damages that are lower. But there's still risk to miss, and chances to have a good accuracy :

if D20 <= 4: it's a miss
else if D20 >= 19: regular damage for the weapon
else: half the damage of the weapon

There's 1/5 risk to miss and 1/10 chance to deal regular damage. To be more accurate, it's probably better to not have something as simple as "half the damage". Adding a "damage for the AI" value to each weapon would probably be better.

Then a bunch of benchmark run to adjust the values :

for( i=0 ; i < 10000 ; i++ )
    result, damage = AIhit()
    if result == 0:
        miss++
        if previousWasMiss :
            actualConsecutiveMiss++
        previousWasMiss = 1
    else if result == 2: 
        crit++
        if previousWasCrit :
            actualConsecutiveCrit++
        previousWasCrit = 1
    else:
        previousWasMiss = 0
        previousWasCrit = 0

    if actualConsecutiveMiss > maxConsecutiveMiss:
        maxConsecutiveMiss = actualConsecutiveMiss

    if actualConsecutiveCrit > maxConsecutiveCrit:
        maxConsecutiveCrit = actualConsecutiveCrit

    totalDamage += damage

print ( ( miss * 100 ) / 10 000 ) " % miss - Maximal consecutive " maxConsecutiveMiss
print ( ( crit * 100 ) / 10 000 ) " % regular hit - Maximal consecutive " maxConsecutiveCrit
print "Average damage " ( totalDamage / 10 000 )

The best way to interpret those values being to have play with the MC and the average number of hit needed to kill a given enemy with a given weapon. The average damage dealt by the AI should be a little below "enemy life / average hit for the player to kill it".
How much is this "little" depending of how efficient the AI should be. If it's role is to protect the MC, then it should be as near as possible to the expected value. But it it's role is just to just delay the enemy, then the AI needing twice the number of hits seem to be a good compromise.

 

[UnderRaBi]

There's no generic solution to this, AFAIK, because it depends a lot on your specific game's needs. The four numbered items all sound reasonable.

Seeing will probably not be enough, there's also the question of accessibility, and the question of the effective range for the weapon.

Sorry for the late reply. I was late thinking about your opinions.
First, I've worked a little bit more on the enemy and allies' behavior routines.
And I thought about how to implement vision.
The first thing I thought about was to send the laser off in the direction of view.
I thought I could stop reaching out to something and check what it was, but I wasn't sure how to implement it, so the method was discarded.

The next thing I thought of was a box collider.
I thought that if we put the box collider this way, we could tell if it was an enemy or a structure.
You can use one big box collider, not three, but to make it more realistic, I thought we could place three box colliders like this.
If you come into contact with a collider, you can immediately fire a transparent bullet in that direction, and if it touches the enemy, you can conclude that you found it.

However, due to lack of programming knowledge in many ways, I don't know whether this is a good method, whether there is a better way, or what the problem is, so I hope you can tell me anything.

 

[Rich]

However, due to lack of programming knowledge in many ways, I don't know whether this is a good method, whether there is a better way, or what the problem is, so I hope you can tell me anything.

You're getting outside my comfort zone with Unity - I haven't used it in a while, and most of my use of it was 2D. This is probably best posted on the Unity forums.

 

[anne O'nymous]

The next thing I thought of was a box collider.

Well, it's usually how it's made when there's no way to directly detect the presence of an entity. But like Rich I can't really help you on this. I know the theory, but never had to effectively implement it, and never had to personally use Unity.