• Top-Down Camera perspective.
• A custom-built AI Perception system tailored specifically for developing Stealth games enable the AI agents to perceive stimuli through four different types of perception models: Visual, Aural, Intuitive, & Motion perception.
• A Stimulus generation system that will enable the users to easily customize & add new types of perceivable events for the AI agents.
• Patrol Guards that can respond to a wide variety of stimuli including the player character, incapacitated teammates, alarms, footstep & gunshot noises, & more.
• Automated security devices like Cameras, Motion Sensors, Laser Security Systems, & Turrets function provide auxiliary support systems to assist the Patrol Guards & provide additional layers of challenge to the player.
• Use Whistle, Gadgets, Suit Abilities, & Weapons to distract or disable AI Bots.
• A Global Alert Level system that controls the activation of automated security devices like lasers & turrets, as well as the deployment of reinforcement patrol guards.
• A Mission Stats Display system that tracks & updates high score information for every level.
Technical Details:
• Modular components are employed throughout the toolkit to handle special functionalities & aid in the creation of new variations to existing entities with minimal coupling.
• The Global Alert Level system controls the Global Alert Meter by employing event dispatchers to continuously listen in new stimuli being perceived by AI agents across the level.
• The AI Surveillance Controller directs the activation of all AI agents within the level. This system can be leveraged to create different starting conditions for each level, choosing to activate all security measures by default or have them activated in a modular fashion based on the overall threat perceived by the AI.
• The AI Sensory Manager continuously evaluates all stimuli against various agents & assigns new objectives to the AI agents based on the results.
• The Patrol Guard AI uses Behavior Trees to respond to the various objectives assigned by the AI Sensory Manager.
I noticed that the turrets are disabled when I start a new game. But then they sometimes get activated over the course of a game. Why is it behaving this way, and how can it be enabled right at the start of a mission?
A: The turret AI in Top Down Stealth Toolkit is set to a deactivated state by default. This is an intended feature designed to showcase the use of automated security devices as a form of backup system for the AI. The default behavior is to activate them once the Global Alert Level escalates to Stage I, which is why they seem to get turned on sometimes during the mission. For more details on how to control this behavior, check out: https://unrealpossibilities.blogspot…kit-faq-1.html
I want to change the size of the vision arcs. Where can I find the variables that control it? Is there a way to do it from the editor window?
A: You can customize the radius & angle of vision arcs for all types of AI through their perception components. For detailed information on how to go about doing it, check out the FAQ reply section at: https://unrealpossibilities.blogspot…kit-faq-2.html
Does the vision cones update their shape based on the obstacles in their path?
A: Yes the vision cones continuously gets updated based on any obstacles it encounters in its path.
How can I turn off the Gadget Selection Menu that pops up at the start of a level?
A: The BP_GameMode blueprint has a boolean variable named ‘SelectGadgetsAtLevelStart’. It determines if the Gadget Selection Menu will be displayed or not. So to turn off the menu, just set this variable to false.
Top Down Stealth Toolkit Basics #1: Patrol Bot Movement System
The Patrol bots in Top Down Stealth Toolkit are equipped with three different types of patrol movement system: Stationary, FixedWaypoints, & RandomWaypoints. This setting can be changed from the ‘PatrolMovementType’ enum variable listed under the ‘User Defined’ category for Patrol Bots as shown:
Stationary Movement Type: The Stationary movement type setting is used for patrol bots that are assigned to guard a particular location without actual patrol movement. They will however move out to investigate any suspicious activity in their vicinity. Upon failing to find the player under any circumstances, these bots will always return to their original guard location.
FixedWaypoints Movement Type: The Fixed Waypoints system is used to create well defined paths for patrol bots. This is accomplished using a combination of custom Waypoint actors as well as an array to store references to these waypoints in a fixed order. In order to create a patrol path using this system, drag in the BP_WayPointNode actors into the level to create a set of path points. Now under the ‘User Defined’ category of the patrol bot actor, add new elements to the ‘FixedWaypointsArray’, and then select the Waypoint actors [screenshot below] from the dropdown in the order in which the bots are required to traverse them. Bots that have been interrupted from this behavior by the player will always return to this designated path once they lose track of the player.
RandomWaypoints Movement Type: Patrol bots assigned with this movement type will keep moving between randomly selected destinations at run time. Adjust the value of the ‘RandomWaypointRadius’ variable within the BP_PatrolEnemyAI_Parent blueprint to change the radius of search for the new waypoints.
Check out 0:54 of the Top Down Stealth Toolkit preview video to see all three patrol movement systems in action:
Hi Daltone, if you select any of the bots in the level, you’ll be able to find two attributes ‘VisionRange’ & ‘HalfVisionAngle’ under the ‘User Defined’ category [see attached image]. You can adjust these values to change the size of the vision cone.
Alternatively, you can change it within the AI blueprints class itself to have it affect all AI units of that particular type.
I’ve been working on the first update over the past few weeks. The main focus of this update since the beginning was to find ways to make the vision arc rendering less expensive. While the actual line trace based calculations doesn’t offer much leeway in terms of cost reduction, I’ve found other ways to greatly optimize the vision arcs. These include checks to identify if the vision arcs are within visible screen space as well as less expensive obstacle checks to set the operation cost levels of enemy AI dynamically. Based on the operation cost level, the bots may turn off the line trace calculations for vision arc, player search logic, or both, thus essentially turning on/off expensive features based on the requirements.
Apart from this, I had been kind of troubled with the class hierarchy for the enemy AI. The Top Down Stealth Toolkit v1.0 comes with the following level of hierarchies:
At the highest level, we have the Enemy AI Parent class derived from the character class.
At the second level, we have two classes: Patrol AI Parent & Stationary AI Parent class, both derived from the Enemy AI Parent class.
At the final level, we have two classes derived from Patrol & Stationary AI Parent classes each.
The problem with this approach was that the Stationary AI class inherit unnecessary components like character movement component & skeletal mesh component from the Enemy AI parent class. I could have made them into separate entities but since I wanted both types to be able to use vision arcs, I decided to derive them from the same class & implement the vision arc logic in the Enemy AI Parent class. So I started searching for more cleaner & alternative approaches & came upon the concept of composition, thanks to zoombapup mentioning it in an old forum post. After doing some research on component based workflow, I decided to use the Vision Arcs as custom components that can be added to any class. This modular approach along with the use of interfaces have helped to remove the unnecessary Enemy AI Parent class & instead have Patrol AI Parent & Stationary AI Parent as two separate entities, each containing only what is required of them. The vision arcs are now added as components to both the classes.
The other major changes that have been made so far include a new Turret bot AI, the use of Setter functions instead of setting exposed variables of a class from another class directly, more optimized AI threat detection logic, etc. I’m also planning to implement an optional gadget selection screen at level start, as well as looking into the prospects of implementing the gadgets as components.
I hope to finish work on this update by sometime next week & in time for the official Unreal Engine v4.11 release. There hasn’t been any updates about what’s happening with the updates for this toolkit, so I just wanted to give a heads up about that.
Here’s a short preview of a couple of new features that is coming in the v1.1 update.
The Automated Laser Component can be added to any of the bots that require a target lock-on system. Just activate the tracking system when necessary & it will use the associated interface functions to lock-on to the active target.
The new Turret bot acts as the offensive counterpart of the camera bot. While it offers a very limited static range of vision, its quick lock-on timer enables it to take down targets with ease.
This is great, one idea to enhance the AI would be to add a state so that once the player is detected, the enemy will look around and occasionally follow the same path/area of the player for a while, even if the player has escaped from view. I think this would make the AI more intelligent and less predictable, otherwise as with most games the AI basically has the memory of a gold fish :P. Another idea is once you’ve been spotted, the AI could then alert nearby AI. These are just some idea that I think would enhance the stealth aspects, but I’m pleased with the template and you will see how I get on using it in the UE4 G+ community.
Hi Owen, glad to hear that you’re pleased with the toolkit. I agree with what you mentioned about memory of AI bots in stealth games. I noticed that in every game that I played through to collect references while working on this toolkit. What almost all of them does is it to have the AI go towards the last seen position to check it out. The AI does that in the toolkit as well, but I was not really pleased with the implementation in the vanilla version of the toolkit. So I’ve added a couple of new bot states for the upcoming update [will be submitted this coming monday]: a suspicious state when the AI first detects a player, & an alarmed state when it either hears an alarm or when it loses direct line of sight to player. The alarmed state lets the AI sprint towards the last seen position instead of the currently implemented investigation mode, which abruptly slows down the AI speed to normal patrol level. Once the AI reaches the last seen location, it will just do a stationary search at that location. The problem with letting the AI follow the player instead of going towards the last seen location is that I haven’t found a way to convey that to the player. At the moment, the vision arcs along with the strictly defined bot states provide accurate information about how far the AI can see, thus enabling the players to make decisions while understanding the rules. Unlike third person or first person stealth games where the player has a much better idea of whether the AI can see them, in top down games, I feel that we kind of need to let the player know about it. One possibility is to use a timer UI element to depict that the AI would follow the player until this timer finishes. I will definitely do some thinking about that while working on future updates, but if you have any other ideas, please do let me know.
As for the AI alerts, yes that would definitely be a neat little addition to the toolkit. I will try to include it in the second update.
Hi Namesis, well it depends on the current state of the AI. Here’s how it’s going to work once the v4.11 update goes live on the marketplace [assuming here that the AI bot doesn’t get distracted by any alarm or footstep sounds]:
The AI bot is chasing the player character [Threat Detected state] >> The player manages to get outside it’s vision range >> The AI bot goes toward the last seen player position & does a stationary search, which is basically looking around towards right & left a certain number of times [Alarmed state] >> If it cannot see the player during this search, it will revert back to patrol state. Now based on the patrol movement type, it would do one of the following things:
Random waypoint patrol: It will choose a random location within a specified radius & start patrol movement towards it.
Fixed waypoint patrol: It will go to the next position that it was supposed to go before it went on chasing the player.
Stationary patrol: It will go back to it’s original guarding position & stay there.
Update I (v1.1) [Compatible with Unreal Engine v4.11] project files are now available in the Marketplace. Since this update brings about a lot of changes, both in terms of new features as well as the improvements over the previous v1.0 implementation, the update has been released only for Unreal Engine v4.11. This ensures that anyone who wants to keep using the v1.0 implementation can still download the v4.10 project files from the Marketplace. Listed below is a brief overview of the code changes in the update:
Dynamic Vision Arcs & Laser Tracking system are now implemented through the use of custom components & interfaces. The component based design provides improved modularity & enables easy attachment to different classes.
Gadget Selection menu at level start enable players to select custom loadouts. Gadgets populated as HUD elements dynamically based on information specified in the Gadget Data Array. [Preview Video: https://www.youtube.com/watch?v=1FJeg6V7iek]
The new Gadget Data Array controls the important parameters of all available gadgets from a central location.
The Camera Bot now triggers timed alarm loops instead of single alarm as long as player character is within vision range.
Replaced Camera Jammer with an EMP that can temporarily deactivate both camera & turret bots.
Laser Tracking component added to Ranged Patrol bot to improve over the existing targeting system.
Improved aesthetic feedback for peripheral range display. The peripheral range display changes color from white (default) to red based on peripheral alert level, replacing the text render that displayed peripheral threat counter.
The patrol bots can now distinguish between different types of noises & handle decision priorities accordingly. Alarm sounds receive higher priority compared to footstep & whistle sounds.
Added new suspicious & alarmed states for the patrol bots to create a more realistic design for state changes.
The new Vision Arc Optimizer actor provides performance boost by removing rendering calculations for arcs outside the screenspace.
Added dynamic operational cost levels enable AI to turn on/off expensive calculations like vision arc updates & threat detection logic on the move based on the requirements.
Setter functions implemented to enable variables changes to occur only from within their parent objects.
Improved code standardization & optimization implemented across all classes.
All changes within the blueprints are marked with the boolean variable ‘Version1.1’ in order to easily identify the workflow changes introduced with this update. Comments are also written to describe the major changes. The new variables as well as functions added to existing blueprints are also marked in the event graph as shown below:
Changes in the Content Browser:
New default HUD class added: BP_PlayerHUD.
New default Game Instance class added: BP_TDSTGameInstance.
Removed BP_EnemyAI_Parent class.
Added new stationary enemy AI class: BP_StationaryAI_Turret.
BT_PatrolEnemyAI, & BTT_SearchCurrentLocation renamed to ‘BT_PatrolAI’, BTT_SetNewPatrolLocation & BTT_InspectCurrentLocation respectively.
Hey,
Great template and I’m hoping to migrate the Ai to my top down (point & click game). I want to place the PatrolAi into my map so that they wonder around, attacking the top down character units (& eventually buildings) in the game. If I place the patrolAi straight into the new game they don’t move, so obviously I need to re-configure the BP’s. Do you have any suggestions? Even placing the Patrol Ai into the default top down doesn’t work out so I would like to pinpoint which BP’s I can migrate>adapt to create the movement and default actions as per the demo.
I have tried a bunch of tutorials and even looked into other Ai systems documentation but there doesn’t seem to be any info on migrating characters beyond simply retargeting animations of characters. If I do get this working I will definitely make a tutorial because there should be more info for migrating(merging) marketplace content into a game with a mix BP assets.
Hi Owen, thanks for your feedback. : ) I tried migrating the assets to the Top Down Template as well & as you said, the patrol bot does not move. This is because it’s doing a couple of casts to the default toolkit game mode and player character [see attached screenshot] to hold references to these objects for later use without further casts.
If you replace both those casts with your new Top Down Game Mode & Player Character, the bot will start doing it’s patrol when you start the game. You won’t have to do any sort or retargeting unless you’re using a different skeletal mesh. All the changes that would need to be made will be centered around using replacements classes for the existing classes in the toolkit like Game Mode, Player Character, etc.
Also make sure that you’re migrating all files including the Behavior Trees & tasks in the ‘PatrolEnemyAI’ folder. You might notice that the Engine asks you whether you want to transfer a whole bunch of other classes & enums apart from the ones you selected. Some of them are actually necessary, while others are getting dragged along for the ride just because a class like Game Mode gets imported which in turn might have references to the said classes. Just press ok for now. Once you have them all in the new project, you can replace the classes with your own classes & delete the ones that are not required. You can check out the list below to get started in that direction:
Among the migrated folders, Keep the ‘Animations’, ‘Character’, ‘Material’, ‘Meshes’ & ‘Particles’ folder as they are. There’s no blueprint logic in any of those folders. Keep all the classes in the folder ‘PatrolEnemyAI’ as well. These are the ones that you actually require.
If you want to use your own game mode & player character class, replace all references to the ‘existing toolkit gamemode, player character & player controller classes’ within all Patrol AI blueprints with the ones that you created for your new project. Delete all three classes once you’ve made the replacements.
[The following classes are all unnecessary; They were migrated because of links from player controller, character or game mode classes]
3. Remove all references to the enums ‘EGadgets’, ‘EHUDState’ & ‘EStationaryAIState’ & then delete these enums as well.
4. Remove all references to the blueprints ‘BP_StationaryAI_Parent’, ‘BP_PlayerHUD’, ‘BP_SaveGame’, ‘BP_TDSTGameInstance’, ‘Widget_GadgetSelectionButton’, ‘Widget_GadgetsGridPanel’, ‘Widget_GameOverHUD’, ‘Widget_LoadoutMenu’, ‘Widget_TopDownHUD’, ‘BP_ProximityShockMine’, ‘BP_AimPlane’, ‘BP_ExitPoint’ & ‘BP_Gems’ & delete these classes.
5. Remove all references to the struct ‘Struct_GadgetData’ & delete it.
If you have more doubts about the migration process, let me know. And thanks for pointing this out. I’ve added this post to the FAQ section so that it can help others who might want to do the same. I’ll try to make some structural changes to the toolkit in the v4.12 update so that the migration process becomes a smoother experience.
Hey, I love this kit. Got it today and have made some good progress learning it. I have my own player character and melee character working “mostly”. They all walk, follow paths, react to camera and foot step sounds, but there are a couple things I can’t figure out:
The custom melee characters do not see the player in the view cone at all. The do sense the player in the small white circle around the enemy. I have made the cone small and large and have no change.
Even when detected in the small white circle and touching the player, nothing happens. If I walk out of the small white circle they go back on patrol without damaging the player or ending the level.
EDIT: I should have stated I created the customer character by creating a child of the BP_AI_Patrol_Parent class (Hope i spelled that right).
EDIT2: I feel like an idiot. I was extending the wrong class. Sorry. Everything is working good now. I just have to figure out why one of my guys has a blue chest and the other doesn’t but that’s my issue I think.
Thanks in advance,
Hi Raymond, very glad to hear that you’re having fun. I think I understand what’s been causing the issue. If you take a look at the Patrol AI Parent class, you would see a component named ‘VisionArcBounds’.
It’s basically a box collision component to identify obstacles in the close vicinity of the bot. Now normally we wouldn’t require an overlap check to detect obstacles, since the AI already has the functionalities to search for player and identify if it’s within range. But since we’re using vision arcs in this scenario, which runs on really expensive calculations, I decided to use the VisionArcBounds box to turn on/off vision arc calculations on the move. This makes sure that unless an AI Bot has detected any obstacles within the box, it will not do any expensive calculations.
Now if you take a look at the Melee bot blueprint, you would find that the VisionArcBounds has been adjusted to be a bit larger than the vision arc range. For all units using the vision arc, I’ve made sure that the box component extends 20 units longer in all directions from the vision arc. So with the melee bot having a vision range of 300, the length of the box will be 300 + 20x2=340 units. Hence the box extent will be 340/2 = 170 units in the local x axis.
Right now, you would have to manually change the size of this VisionArcBounds box everytime you change the vision arc radius or angle. I’m working on the v1.2 update for the toolkit & it will include the feature to automatically adjust the box size based on the vision arc that you set. So you would only have to make a single change & the bot will take care of the rest.
Thank you very much for the explanation. This will help when I start to create other types of entities as well. Like droids and ROV’s.
This may not be related to your pack, but any chance you may know what is causing one out of three of my characters to have either a red or blue trans parent material? Almost like a team material index is in the blueprint but I can’t find one anywhere. The other two blueprints I created children for, player and ranged character work with no problem at all. I have also tried a few other materials to see if that was the issue but no matter what it comes up either blue or red on the chest and see through.
Here is what the skeletal mesh looks like:
And here is what the same character looks like in the blueprint:
I don’t have access to my computer right now, but I believe that it’s happening because the melee and ranged bot classes contain some logic to display blue and red colors at the center of their upper torso. It was made that way to distinguish between them. You can remove this logic from the construction scripts of the melee and ranged bot. It’s just a couple of nodes that set the color using a material instance.
