Tactical Shooter AI - Asset Store Pack

So, you don't see anything new, not even the demo scene? First I'd make sure you actually downloaded the new version instead of just reimporting an old one, and then re-import the package.

 

I'm interested in using this package for bots in a magical combat game. I'm not really interested in using this package's animation features or bullet creation. I'm most interested in having a higher level movement controller/API. Will this asset work for these purposes?

 

You could probably get it to work, but it would take some tweaking- the exact amount being dependent on your use case. For instance, cover is tied to the gun firing- when the GunScript decides to fire, it leans out to get a clear shot. This is in contrast to a centralized AI brain giving orders to other components (the brain decides to shoot, so it moves to get a clear shot and then tells the GunScript to fire), which is what I imagine you're looking for.

Also, if you are using spells that do more than make the enemy stumble backwards or flinch while still keeping them alive/active (for example, changing them into a flying shark), you'd also run into problems if it causes them to leave the navmesh.

To be honest, while you could probably get it to work, I'm not sure if the time saved would be worth it in your case if your game can't just be reskinned into a shooter.

 

Thanks for the response.
Do you have any links to learning materials that helped you implement Tactical Shooter AI?

I've considered using deep q-learning to control the bots, but this seems difficult given that the current state of the art is having the AI learn to play Doom.

 

Can anyone say how well TSAI works on terrain? I am thinking of using it in a lot of outdoor areas and want to know how it performs before buying it.

 

My project using TSAI and RFPS is going well, the integration is working nicely and I've ironed out almost all of the niggles that come from running the two packages side by side.

I still have one issue that I haven't been able to resolve and I wondered if anyone else who is using both packages could chip in.

I've got all the various grenade and explosion assets from both packages working so they damage both the AI and the player but one RFPS asset is still troubling me.

It's the mine explosion.cs script in RFPS. It seems to be set up differently to the explosive object.cs script and, despite editing the sections under NPC damage in a similar way to the bits changed on explosive object.cs, I can't seem to get it to work.

I'm no scripting expert so I wondered if anyone else who is using both packages has got this to work and how you did it.

No biggie if it can't be done as I can just leave the mines out but I do like their functionality to scale up difficulty in later parts of the map.

Cheers and thanks for a great asset, really enjoying using it!

 

I have a similar issue where my AIController is on the the 1st main scene, and Agents are in the additive scene loaded. Everything is fine except static Covers on the 2nd additive scene doesn't seem to work. When I move those in the 1st mainscene everything works as exected and agents on the 2nd can find the covers.

Are my covers objects need to be under the AIController ? Am i missing something somewhere in the setup ?

thanks !!

 

Hi everyone, sorry for the late responses.

Assuming that you can bake navmeshes on terrain, I think it will work fine. However, you might get some issues with feet hovering on uneven surfaces, and you may also need to modify some settings for performance reasons on large maps.

I can look into this, In the meantime, maybe you could just spawn an AI explosion at the same time as the RFPS one?

Hmm. You shouldn't need to make the covers children of the AI Controller.

You may want to try recalling the Awake/Star functions on the AI Controller/Cover Nodes when you load in your new scene, though.

 

Thanks Squared, yes, I reckon that will be a good hack for now. If you get chance to have a further look, do let me know and many thanks for your continued input!

 

This is top 10 worst assets I've ever seen. It has a lot of great ideas, all of which are very poorly implemented. While running an i5 7500, GTX 1060 6GB I lose 30fps by putting in ONLY 20 AI. After looking through the code I can see why!

There are multiple instances where the author overwrites variables without using them wasting cpu cycles, coroutines everywhere, every single variable type (public, field, accessor, local) are all camelCase, multiple references to the same object made in the same scripts under different variable names. This asset is held together by a thread. I can't recommend buying it what so ever.

 

Well, I'm sorry to hear that. Have you tried disabling dynamic cover (especially the Navmesh Scan method)? That can really take down your framerate on large maps.

In any case, if you would like a refund, please send me your invoice number and I'd be happy to get you one!

EDIT: Addressing some points specifically:

How many frames per second were you getting before/after spawning these 20 agents? 500, or 50?

For example, on my PC, spawning 100 agents into a very simple scene with 7 others does bring me down by a few hundred FPS, but I'm still at ~60 FPS, so it doesn't matter all that much. Then, to get ~30 FPS in this scene, I need to have a total of about 175 agents. At 20 agents total, I'm sitting at ~350 FPS. While I wouldn't be able to get those numbers in a more complex scene, proportionally each agent would likely be a smaller hit to the frame-rate when compared to everything else going on.

The point being, losing 30 FPS is a reason for major concern you started with 60 FPS, but less so if you started with 600.

Do you happen to have any sources on the performance of Unity's coroutines vs. other timer methods? Not trying to pull a "gotcha" or anything, I'm genuinely curious. I was under the impression that the difference (especially when you're not calling them every frame) was negligible.

Either way, they make the code more readable for me!

I admit it has been a while since I've gone back and cleaned up the code. But, unless I stuck one of these inside of a particularly massive loop, I don't think this would effect performance to a great degree.

I'm under the impression that this is standard practice for Unity scripts.

Again, I'm sorry that TSAI didn't meet your expectations, and I'd be more than happy to offer you a refund.

 

Hello, I appreciate the quick response but there is nothing that can be done to resolve the issue except a huge re-write of the asset. I don't drop down to 30fps, I lose 30fps by only placing 20 units. It's not the projectile spawning, or the poly count either as I've disabled rendering and the projectile spawning resulting in only about 5fps saved. I tested on the demo maps, and a near empty map.

There is more backend work with coroutines than manually managing a timer. It would be far more efficient to check a boolean and float than use a coroutine; this efficiency increases when negating many coroutines.

There really is no standard practice for any type of language. Many would like to think so but that's simply not true. Readability is more important than any believed practice. The most widely used practice(though not explicitly) by professionals is typically seen at this:

Code (csharp):

1.  
2. internal class MyClass
3. {
4.    public string PlayerName;
5.    private int m_playerHealth;
6.    
7.    private void Awake()
8.    {
9.        int healthModifier = 10;
10.        m_playerHealth += healthModifier;
11.    }
12. }
13.  

Notice the clear distinction between scopes. If I were to see Variable I would immediately know it's public. When seeing m_variable it's a private field, and when variable I know its local.

A refund won't be necessary. I'm working on another project which utilizes this asset and I'm fairly sure they don't want me to build an AI from scratch as that would be very time consuming. Your ideas are excellent, the asset is loaded with features. But the poor execution makes this asset impractical if not impossible for larger games.

 

Likewise, thank you for your quick answer to my answer.

In my experience, one of the biggest CPU performance killers isn't necessarily the rendering, but moving the transforms of the giant character hierarchy, which still happens after you've disabled the renderer. Once for moving the agent, and again from the chest up for aiming. Unfortunately, I've yet to find a way to significantly improve in that regard without losing functionality.

There's also spawning excessive amounts of bullets, but you've already got that one identified. And, of course, there's also simply decreasing the frequency of the AI cycles.

Can't argue with that. I suppose it's a toss-up between readability on my end, and performance on yours. Customer's always right and all that. I'll have to run a test to find the exact performance hit one of these days.

Well, I can't really argue with that either. What I suppose would be more accurate would be saying that the Unity Scripting Reference uses the camelCaseEverything method. And I agree, seeing which variables are private and which are public at a glance is certainly useful for anyone who has to maintain the code... or get it anonymously from an asset store.

Thank you for your helpful response.

 

Can't chip in on the technical stuff as it's beyond my pay grade but I can offer some thoughts on my own implementations and testing.

Dynamic cover with navmesh scan is the most resource intensive.

Dynamic cover with raycast offers significant improvements if you must use dynamic cover.

By far the best option is manually placed cover nodes (this is pointed out in the documentation) both for performance and the realism of agent behavior.

I'm breaking my levels into small parts and using area spawners to only spawn the agents that I need when the player is in the correct proximity. This seems to be the most efficient way to use the asset.

I did accidently spawn in excess of a hundred agents recently. The FPS did halve but all agents were still shooting, throwing grenades and running through their behaviours. It did not break the game, which was very reassuring.

If you lack the skills (ME!) or the time to code your own solution then I still think TSAI represents by far the best option for genuinely realistic and exciting AI response. Like all 'off the shelf' tools there are some limitations that you have to be aware of and plan to work around. It still brings a smile to my face when I'm creeping up on a pair of patrolling agents only to get blasted by another pair that have outflanked me on the blind side! That's worth the admission price in itself.

 

I'm really glad the asset has worked out for you. It has some good applications for smaller projects.

As a seasoned programmer though I simply cannot recommend this asset, and I'd like others to be aware that it suffers from some very serious performance issues. It's not okay to lose 30fps in a process that should consume perhaps only 1-2fps at most.

I realize it's generally not the programmers that purchase such assets thus most people which buy assets don't even look at the profiler. With that said, this is more of an eye-opener for anyone which plans to use this asset for either medium to large engagements, networking, paid projects; if your game meets any of those criteria, look elsewhere.

 

30 FPS out of how many? I don't feel as though FPS is the best way to measure this- rather, we should be using ms/frame.

For instance, on my computer, I go from ~0.8ms/frame to ~2.0ms/frame after spawning 20 agents into a scene with 2. If I'm targeting 60 FPS (~16.7 ms/frame), then those 20 agents are only using up about 7% (1.2ms) of my CPU's "budget." On the other hand, saying that hundreds of frames were lost gives quite a different impression, despite also being true.

On a related note, if I disable the animation, renderer, and projectiles, then I add an additional ~0.3-0.4 ms/frame for 20 agents. This indicates that the AI logic alone is approximately 2% of my 16.7ms "budget".

But of course, your mileage may vary based on your hardware. How does your ms/frame change when spawning these agents on your computer?

 

Apparently the performance impact is way worse than I originally had assessed. Here's the profile difference between 10 and 30 units. By adding 20 units FPS had dropped from about 75 to 25. Milliseconds/frame had increased roughly from 9 to 42.

I mentioned my specs above but for anyone new I'm running an i5 7500, with a GTX 1060 6GB.

That's a tragic amount of performance loss.

 

Thanks for the report.

So, I decided to do my own test, to see if I could replicate your results. I went from from 2 to 52 agents on a 1070 and i7 7700.



While part of the better absolute performance value can be attributed to higher specs, the ratios are very different. Only a tiny fraction of your performance is going to rendering, physics, and "others" compared to the scripts, while mine is more balanced.

However, I was able to get pretty much the same results as you by reducing the time between AI cycles to zero (from 0.2 seconds). Performance dropped like a rock.

But I did learn something rather interesting by doing this. Turns out that the biggest performance killer was the StopSprinting() and StartSprinting() functions, of all things.

Specifically, when I tried to get a parameter (I haven't checked which one yet), it absolutely wreaks havoc on the garbage collection system. How much performance are we talking about for these two functions? 95% of the entire AI cycle.

So yeah, that needs fixing. I'll let you guys know when I figure it out. In the meantime, I recommend decreasing the frequency of the AI cycles. I didn't even notice this when they were spaced further apart, and hopefully you won't either!

EDIT:

My quick hack fix is to replace the Start/StopSprinting methods in the animation script with:

Code (CSharp):

1.         public void StartSprinting()
2.         {
3.             if (!sprinting)
4.             {
5.                 sprinting = true;
6.  
7.                 //Make sure the animation in question exists.
8.                 //If the trigger is not found, no animation is played, but no error is thrown.
9.                 for (int i = 0; i < animator.parameters.Length; i++)
10.                 {
11.                     if (animator.parameters[i].name == "Sprinting")
12.                     {
13.                         animator.SetBool(sprintingHash, true);
14.                     }
15.                 }
16.             }
17.         }
18.  
19.         public void StopSprinting()
20.         {
21.             if (sprinting)
22.             {
23.                 sprinting = false;
24.  
25.                 //Make sure the animation in question exists.
26.                 //If the trigger is not found, no animation is played, but no error is thrown.
27.                 for (int i = 0; i < animator.parameters.Length; i++)
28.                 {
29.                     if (animator.parameters[i].name == "Sprinting")
30.                     {
31.                         animator.SetBool(sprintingHash, false);
32.                     }
33.                 }
34.             }
35.         }

All I did was add a check to make sure that the loop there is only called when the sprinting state changes.

In case anyone's wondering why this hit so hard, the loop where I look for the sprinting animation (to check for compatibility) does not play well with the Garbage Collector. But, looking back on it, I should probably just do this check once when the agent spawns, and then never again, seeing as the animation controller never changes. Another thing to add to the to-do list.

@Distul

Does this solve your performance issues? In any case, thank you for bringing this to my attention!

 

Very interesting. As you know I'm an enthusiastic amateur using free unity so no access to profiler. I did however notice some problems with 'sprint' in my tests. I have 'Can Sprint' unticked in all my edited prefabs as I experienced performance problems with this enabled and also 'skating' with it enabled. Perhaps that's why my performance was much better - did this bypass the troublesome code? Funnily enough, all my agents do still sprint.

Totally unscientific I know, but just a result of trial and error. Great to see everyone working together to streamline the asset -squared55, your ongoing support and effort is much appreciated!

 

I haven't had a chance to mess with the AI performance lately.

The free Unity has a profiler now.

 

Cheers! I didn't know that, I'm holding off upgrading to the latest version until I complete my current project but I'm half tempted to upgrade now if I can get access to the profiler.

 

If I remember correctly, there is a profiler included in every version of 5.x and above.

 

Thanks Squared - I'm finding new things everyday! I see that you have updated the package with the performance fixes. Can I just download the new animation script to take advantage of these fixes? I've made changes to a lot of stuff and got what I consider to be a 'stable' version running with all my customisations and I don't want to re-import the whole package if I can avoid that. Cheers!

 

It would probably be possible to just import the new animation script, but I haven't tested it myself.

Best to make a back-up, just in case.

 

Roger that - need to do a back up anyway so I'll get on that - thanks Squared!

 

I'm glad you worked that out! I .. unfortunately already wrote a new AI so I won't be updating yours. Have a deadline to make and all that. Plus I needed network integration in my AI which was proving troublesome with the controllers yours used.

 

How to implement enemy muzzle flash?

 

Hey there Squared. I've been having my eye on this ever since it first came out, and am currently working on a project that has a need for something quite like it.
However, I'm doing procedurally generated levels (interiors only, i.e exclusively consisting of "tiles" of prefabs), and I'd like to make sure that this framework could work with that. I'd like some more details about that, if you would: how does the Tactical Shooter AI operate in terms of navigation?

 

Create a muzzle flash prefab (containing particles, sounds, lights, etc), and then set it as the "muzzle flash" in the agent's Gun Script (under the Muzzle Flash Parameters) dropdown. You can set the Muzzle Flash Spawn to the same as the bullet spawn if you want.

Out of the box, it uses the default Unity pathfinding system. However, I recall reading that this will be (or maybe already has been) upgraded to allow runtime navmesh baking which sounds like it could work for your game.

If this doesn't satisfy your needs, though, TSAI has a "NavmeshInterface" script/class which acts as an intermediary between the scripts and the navmesh API. You can modify/extend this to work with pathfinding systems besides the Unity default.

 

Hi I first want my enemies to patrol and then in combat position if the target(player ) comes into their line of sight.What do u think I must do?Set them to custom behavior?

 

Cheers, this sounds good. I'll give it a shot.

 

You mean you want them to go to one position and then stay there? Setting the combat behaviour to Berserker and then setting the base script's Key Transform to an empty game object marking this position may work.

 

Hi Squared,

Is there anyway to enforce a TSAI agent to keep spacing on another TSAI agent if they are spawned from the same prefab?

In a real combat situation, a patrol will keep their spacing on each other to decrease the odds that an explosive or single enemy with a machine gun could decimate the whole patrol.

Spawning agents with the "Search" behaviour (my preferred default for my levels), they move toward the player position in a group or what could be considered a tight column formation. They behave fine when alerted but before that, it's possible for the player to get the drop on a group of agents and knock them all out in one go.

I'm hacking this by using different prefabs with varied 'idle' speeds which does spread them out but I wondered if there is a parameter I can tweak so that I can prevent an agent from being in too close proximity to another agent while in the 'idle' behaviour - cheers!

p.s. It isn't practical for me to 'stagger' their spawn rate (which would fix the issue) as my levels are small and I need to get the agents spawned quickly out of sight of the player when the player triggers the spawn.

 

Hey Squared,

Did a bit more testing tonight and found that even a 0.5 second delay in spawning individual agents has a MASSIVELY positive effect to the agent 'spread' without any detriment to my levels or gameplay - so all is good. If there is a specific proximity value that can be adjusted, I would still be very interested in hearing where it lives but for now things are looking very good indeed. Many thanks!

 

Hi i have been trying to get this working with Realistic FPS Prefab but nothing seems to work. Tactical shooter AI works find in the demos without importing Realistic FPS Prefab but once its imported it just beaks everything. In the integration.txt for this it says
For whatever reason, upon import, Unity removes any animation called "run" from all of the RFPS animators which causes a chain reaction and basically causes the whole game to fall apart.
You'll need to manually replace these upon import.
But all the run animations are there so i don't understand what it is asking so can someone please make an integration video for this i found the ufps integration video but was unable to find one for Realistic FPS Prefab although i know this asset is lacking any tutorials at all which is quite disappointing.

 

Hello,

It looks like RFPS recently updated last week, which means I need to revise the instructions (again). And, not only have they changed the scripts, but they appear to be using mecanim instead of the legacy animation system now.

You'll need to open the Animation Controllers (if any are giving you issues) and add in any missing animations there. No new mecanim nodes, just check the existing ones and if the animation slot is empty, fill it in with the appropriate animation. You'll also want to press "Update Reference Clips" for the RFPS models with animation avatars to fix any distorted animations. As for the scripts, it seems as though you'll now want to paste the WeaponBehaviour bit on line 2134, in the "HitObject" function. For ExplosiveObject, line 123 (in "Detonate").

The rest of the instructions seem OK (make sure you change the TimeScale back to 1!), but I'll try and go over it all to be sure as soon as I get the chance.

 

So I'm having a great deal of trouble getting the animation controller to work on a Generic Rig [rather than a humanoid one], with a Custom Ragdoll. I tried to mimic the setup of the DemoAgents. I'll be happy to export the thing and send it to you so see if you could tell me what I was doing wrong.

But I'm at my wits end on this particular enemy.
The idea was for the small 4 legged spider thingy to turn its small head to face the player and fire from it as well. As so far everything except the animations are working.

Here are what I'm using. If you need any other info please let me know.
Unity 2017.1.0f3
UFPS as base
Most recent version of TacAI (no modifications)




**edit** Nvm found my Problem. Stupid Avatar isn't regenerating. Mecanims fault not the AI controllers

 

Hey there, Squared. Me again. The documentation seems to lack what I seek. Is there a suggested workflow when operating with procedural scenes? After all, I instantiate the entire level (consisting of tiles, as mentioned before) and its navmesh dynamically, as well as all AI agent spawning positions. Attempting to run the scene throws an error about an invalid navmesh.
Furthermore, I will need to "re-instantiate" all AI agents at some point, without reloading the scene.
So, is there a suggested workflow about this sort of approach? Some centralised init function that's automatically called on Start which I could possibly delay after the level/navmesh generation has been completed? (Do apologise if something like that is rather obvious once one's looked at the code, but I find myself a little pressed for time right now...)

 

Hello,

So, I've never actually tried making a procedural level before, so this is just me making an educated guess. With that in mind, I would recommend first spawning in your AI Controller Game Object, after building your scene and baking your navmesh, then spawning the cover nodes (if any), and finally agents and targets such as players. If you need to spawn a player earlier, then I would recommend attaching the TargetScript to an empty game object prrefab instead of the player, and then spawning in the prefab and parenting/moving it to the player at runtime.

As for re-instantiating the agents, I'd recommend doing just that- killing off/destroying the old ones if necessary and then spawning in new ones..

 

Hello Squared,
I have problem with spawning agents in unity 2017.1.2f1 with last version of TSAI.
When spawn the agent i get error like this :


""GetRemainingDistance" can only be called on an active agent that has been placed on a NavMesh.
UnityEngine.AI.NavMeshAgent:get_remainingDistance()
TacticalAI.NavmeshInterface:GetRemainingDistance() (at Assets/Tactical Shooter AI/Tactical AI/Csharp/Helper Scripts/NavmeshInterface.cs:125)"
But when i put the agent in the scene without any spawner its works fine.
How i can solve this error ?
Thanks

 

Hello,

Make sure that you are spawning the agent on or above the navmesh.

 

Just wrote a basic enemy item dropper script. Your welcome to use it. I posted it on the UFPS forums.
http://www.opsive.com/assets/UFPS/f.../3879/enemy-drop-script-for-paragon-ai#latest

I may or may not update it. But its there if you need a basic one.

V1.02
- Just added an array to it. With a range setting for scattering

 

Thanks for this great Script Paul-Swanson!!! You rock!!!
Wonder if there is possibility to upgrade spawner so it would have spawn enemies by trigger?
Did anybody acheived this functionality yet? If so could you share?
Cheers!!!

 

Are you referring to the Spawner Script in the most recent version of the package?

That script has a "spawnerActive" variable. The spawner script will not spawn any agents while this variable is false. If you start the game with it set to false and then set it to true when your player interacts with the trigger, you can delay the spawning until after the player has reached a certain part in your level.

I will also look into adding an option to set a "trigger object" for the spawner script. Then, when the trigger object gets close enough to the spawner object, the spawner script will activate automatically.

 

Hey Squared. Me again. Cheers for the tips - your suggested method works. I had some issues with UFPS layers and agents not seeing the target, but that was rather easy to fix.

A little issue I'm having is that agents set to wander or patrol move in and out of rooms, I'm assuming because the navmesh for the entire level is contiguous. Is there an easy way to limit their patrol to a collider's bound, or a pre-defined route of some sort?

EDIT: Also something I wanted to ask: agents currently can't see through "semi-transparent" level geometry, as all geometry is currently placed on layers that block LoS. Do you have any recommendations about how to best implement see-through (but not shoot-through) objects?

 

Setting a key transform in the base script should keep the agent within a set radius of said transform when wandering.

Patrols can be given more precise routes by simply adding more waypoints to the array.

As for translucent elements, like windows, I would put them on a separate physics layer to the rest of the level parts. Make them invisible to the AI Controller's layermask (and thus the agents), but visible to everything else, like bullet prefabs and cover nodes.

 

Hi @squared55

I wonder if the package got some improvments about code modularity ?
And about avoiding friendly fire ?

 

Modularity is pretty much the same as before. Any specific components you want to replace/remove?

I'm working on some additional friendly fire fixes as we speak.

 

Any chance you could make that a toggle. Rather than a total fix?
I actually like the friendly fire. I'm using it specifically as a design choice for the AI's.

 

I was meaning AI able to avoid firing if another AI is in front of it.

I was meaning it is easy to use our own player controller ? adding a script only ? or adding some functions to our player controller ?
If we add our own AI characters and scripts , is the plugin AI able to navigate and not be stuck on other characters ?