Top Down Stealth Toolkit

Perfect man! That did it. I’m off and running now!

Glad to hear that you got it working man.

The v1.2 update has been submitted to the marketplace. This update will add support for v4.12 of the Unreal Engine, alongside introducing new features [for v4.11 & v4.12] like Laser Security Systems, Gadget Pickups & Mission Timers.

Top Down Stealth Toolkit concepts sections are being updated to reflect the changes introduced in the v4.11 edition. Since this could potentially remove the information about the implementation in previous versions, I’ve moved those sections over to my blog so that users who continue to use v4.10 of the toolkit can still have access to those articles. Links to information about the previous implementation will also be provided at the end of these posts:

  1. Top Down Stealth Toolkit Basics #2: Vision Arcs [Updated 4.11 implementation details] - https://forums.unrealengine.com/showthread.php?97156-Top-Down-Stealth-Toolkit&p=459450&viewfull=1#post459450

  2. Top Down Stealth Toolkit Basics #3: Gadgets [Updated 4.11 implementation details] - https://forums.unrealengine.com/showthread.php?97156-Top-Down-Stealth-Toolkit&p=459460&viewfull=1#post459460

Top Down Stealth Toolkit Basics #4: Operational Cost Levels

All AI Bots in the Top Down Stealth Toolkit are equipped with the functionality to dynamically turn on/off certain parts of their core logic in order to increase performance. The Operational Cost Levels enum variable is used to keep track of this behavior & functions mainly based on two factors:

  1. Obstacles/Potential targets in the near vicinity of the AI bot.
  2. If the AI bot is on screen or off screen at any point of time.

Taking both the above factors into account, there are four Operational Cost Levels [even though there are minor differences between the impact of each of those levels on patrol & stationary bots]:

  1. High - Threat detection logic & vision arc vertex update calculations are processed. In case of the patrol bots, both direct line of sight as well as peripheral threat detection are activated, while the stationary bots use only direct line of sight based calculations.

  2. Medium - The direct line of sight based threat detection logic is deactivated, leaving only vision arc vertex updates to be processed. In case of the patrol bots, the peripheral threat detection will still remain active in this state.

  3. Low - Direct line of sight based threat detection & vision arc vertex update calculations are deactivated. In case of the patrol bots, the peripheral threat detection will still remain active in this state.

  4. Off - All forms of threat detection logic & vision arc vertex updates are deactivated. Vision Arcs are set to hidden in this state, since one of the prerequisites for this state is that the bot along with it’s vision arc are located in an off screen location.

Update II (v1.2) has gone live on the Unreal Engine Marketplace. This update adds support for v4.12 & introduces new features to both v4.11 & v4.12 editions.

New Features:

  • Laser Security Systems: Acts as a secondary layer of AI Threat Detection by alerting all nearby patrol bots upon being intercepted by the player; Easily customizable using globally exposed variables; Supports drag & drop functionality into the level.

Preview Video:

  • Gadget Pickups: Enables the designer to place gadget pickups throughout the level; Gadget type can be easily specified using a globally exposed variable in the actor; Supports drag & drop functionality into the level.

Preview Screenshot:

  • Mission Timers & Persistent High Scores: Displays Mission Time at runtime; Adds support for persistent high scores using save files.

Preview Screenshots:

  • Damage Effects Interface: Provides the means to apply damage through a single conduit, irrespective of the target; Reactions to different gadgets handled by the targets in response to the interface function calls.

Bug Fixes:

  • Fixed a bug with Alarm Targets failing to produce noise that can be perceived by Patrol Bots

All changes within the blueprints are marked with the boolean variable ‘Version1.2’ 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 Blueprints: BP_SaveGame, BP_GadgetPickup & BP_LaserSecuritySystem.

  • New Interface: BPI_DamageEffects.

  • New member ‘EffectDuration’ added to Struct_GadgetData.

Hi,

Does your pack support multi-level via stairs, elevators, etc? If not, how difficult would adding that functionality be?

Hi gooberCP, the toolkit does not come with the default features for moving between multiple floors that are part of the same mission. There are basically two approaches to this situation:

  1. We could take the Marvelous Miss Take or Hotline Miami route, where the player can move between levels through designated points like stairs or elevators, without having the enemy follow them. In Marvelous Miss Take, the developers completely denied AI movement across multiple floors. By the looks of it, Monaco probably does this as well. I have not played Hotline Miami, but after reading about it, it seems that players would have to kill all AI bots in a level before moving on to the next.

Adding such a system wouldn’t be difficult. If you’re interested, I could include it as a new feature in the next update, using level streaming based on overlap volumes to allow player transition between multiple floors in a mission.

  1. The second case would be based on allowing the AI patrol bots to chase after the player across multiple floors. I couldn’t find any example for this right away, but implementing this system would require a lot more work, especially if we use some sort of conduit like an elevator that instantly teleports units across multiple levels. I have not played any top down stealth games like these in recent times. So if this is what your query was about, it would be great if you could provide an example of a game that has implemented it. I could then do some research on it & come up with a more helpful answer.

I’ve created a tutorial that goes over the process of migrating the Patrol Bot AI from the toolkit over to a new Third Person/First Person project. Screenshots have been provided for every step along the migration process with markers & tags depicting the changes that need to be made in different parts of the associated blueprints. You can find the tutorial at:

I broke something…I was mirgtating the project over to the latest version to get the level timer and laser grid, etc. I got everything to to work but I must have done something which caused the game over screen to stop displaying the completion time. It appears during gameplay but does not show anything on the game over screen. I check the UMD’s, HUD’s and blueprints and I see all the variable hooked up and there’s no errors. The text is in the UI’ HUD files.

Because I already had a lot of work done I added (migrated) the features to the existing project by creating a new project with the new updated in the launcher. I then copied the files from the new project location and overwrote the old project files in the windows browser. Like I said everything works except for displaying the completion times.

See here the HUD
9732f25a0aeb67ba3b41d28e7dad4c82e8db17bf.jpeg

Here’s the in game win screen

Here’s the HUD blueprint showing the timers with no errors
1ac48eec17ff5428cb12f5a65e8f220d715ef7b4.jpeg

They seem to be there in the player controller

Hi Raymond, the End Game HUD is programmed to show the mission completion times only when you have completed the level. Since you seem to have done that based on your screenshot & still not getting the completion times, the code is flowing into the ‘Game Over’ logic. And that’s basically the series of nodes following the red circle you marked in the screenshot.

At the very left of that screenshot, you can see a small part of a branch node. This branch node basically checks if the mission is a success or not. Since it’s returning false and the logic moving towards the ‘Game over’ section, it might be possible that the ‘Mission Success’ variable in the Game mode is not being updated.

It’s being updated using the function ‘Handle End Game Logic’ in the Game Mode.

Could you check if you’re updating this ‘Mission Success’ variable in the Game mode? The function is called from multiple classes, both for win and fail states. But since we’re dealing with the Win condition here, that particular instance of this function call is made from the Exit Point actor as marked in the screenshot below:

Stormrage256, That was it! When I copied over the blueprint files to migrate my existing game to have the new features the little check box next to the “Mission Successful” was not checked. As soon as I checked it everything started working perfect. Thanks again my friend, your support for your product is unparalleled.

Thank you Raymond :slight_smile: Glad to hear that it’s working well for you now.

Hi, can anyone tell me step-by-step how to set the animations so they would work in newly imported mesh? I changed these 2 options in the dragg&dropped BP_PatrolAi_melee character but my character is walking/running/idling in T-POSE. Should i make anything more to make it work? I’ve migrated animations, changed Skeletal Mesh in BP_PatrolAi_Melee and it still doesnt work.

The toolkit is using the basic UE4 mannequin. Epic has already released some tutorials on how to do animation retargeting for both same as well as different type of skeletons. Since this is probably of a different type, you could check out this tutorial: https://www.youtube.com/watch?v=xy9aLbZLdeA

Update 3 (v1.3) has gone live on the Unreal Engine Marketplace. This update officially adds support for v4.13 of the Unreal Engine & introduces the following changes to the product:

  1. The Gadgets from previous iterations have now been split up into three categories based on their functions: Suit Abilities, Gadgets, & Weapons. Splitting them up into multiple categories essentially paves the way for using a component based approach, thus nullifying the need to store details about implementation of all types of gadgets within the player character or within a single component. This facilitates replacement of the default player character with custom player characters/pawns with minimal code transfer. The three new actor components introduced for this purpose are:

Suit Abilities Manager: The Suit Abilities Manager handles all instant activation abilities. As a result, the ‘EMP Blast’ function from the previous iteration will be activated through this component. The Suit Abilities can be used as many times as needed, but have a cooldown period once they’re activated.

Gadget Deployment System: The Gadget Deployment system is used in scenarios where activation of a loadout entity requires it to be deployed in the physical level space. The ‘Proximity Shockmine’ from previous iteration will be deployed through this component. The Gadgets can be used only for a limited number of times, but do have any cooldown periods.

Weapon Targeting System: The Weapon Targeting system enables usage of weapons that require manual targeting by the player. For example, the Stun Gun implementation is now handled through this component. The component takes cares care of both aim/holster logic as well as the actual firing mechanism. The Weapons can be used only for a limited number of times, but do have any cooldown periods.

All three of these components interact with the parent class through their associated interfaces only, thus allowing them to be used with different types of actors. For example, when the Stun Gun is being used, the Weapon Targeting System calls the associated interface function from the player character (owning actor), which then creates a laser particle system to accurately portray the aiming mechanics.

On the other hand, when the parent actor interacts with these components, it does not need to provide any information. A request is passed through to the component, which then handles the required functionality based on the equipped entity of it’s type. For example, if there are multiple types of possible suit abilities, with EMP Blast being the equipped one, the Suit Abilities Manager will know that it needs to activate the EMP Blast & not the other abilites.

  1. The inclusion of multiple types of entities in the player’s arsenal has been implemented through a new loadout system, which consists of one type each of Suit Abilities, Gadgets, & Weapons. Among these three entities, only one may be active at any point of time. For example, if the active loadout entity is a Gadget, the player pressing ‘F’ will deploy the selected gadget. Of course, the active loadout entity can be changed at runtime through their associated input buttons whenever required.

In the screenshot below, the three different loadout entities are marked within the green box, while the active entity marked within the red box has been scaled up to convey the aforementioned information to the player:

  1. Added a new function library BPFL_GetterFunctions to easily retrieve frequently referenced important information without compromising on the visual clarity of the code. As a result, accessing the gadget data array or enquiring about the active hud state, can be done by calling their associated getter function from this library.

  1. The BP_PlayerController class now manages all low level HUD requests [updating independent UI elements like stamina bar, mission timer, loadout button states, etc within the In Game HUD] thus acting as a single conduit through which all updates pass through.

2fff09a91994ed0bcbfd444db6be91e31f8351eb.jpeg

The BP_PlayerHUD & the BP_GameInstance classes on the other hand, handle all high level HUD state changes like transitions between the loadout HUD, In game HUD, & Mission Summary HUD.

  1. The new custom Game State class stores critical information about the mission status, while the new Player State class stores information about player activity that aren’t directly related to any of the character’s core attributes.

  2. The new Weapon Pickup class provide opportunities for the player to change their weapon loadout at runtime.

  3. The BP_GameMode now handles initialization of all core gameplay actors from a single central location, thus ensuring both improved code clarity as well as an organized workflow instead of the actors having to rely on Begin Play events or initializing each other.

f1fc1583b7ea082f8967157710098bc9cd305c24.jpeg

  1. A new Stamina Manager component has been added to move the stamina management part of the sprinting mechanic over to a separate independent module. This basically frees up the player character to primarily deal with changing the walk speed parameters, while leaving most of the remaining calculations to the component.

All changes within the blueprints are marked with the boolean variable ‘Version1.3’ 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:

  • Blueprints BP_TDSTGameInstance & BP_TDSTGameMode renamed to BP_GameInstance & BP_GameMode respectively.

  • New Game State class added: BP_GameState

  • New Player State class added: BP_PlayerState

  • New Actor components added: BPC_GadgetDeploymentSystem, BPC_StaminaManager, BPC_SuitAbilitiesManager, & BPC_WeaponTargetingSystem.

  • EGadget enum list modified.

  • New Enums added: EAbilities, EPlayerLoadoutSystems, & EWeapons.

  • New Function Library added: BPFL_GetterFunctions

  • New Gameplay Actor blueprints added: BP_WeaponPickup

  • New Interfaces added: BPI_GadgetDeployment, BPI_Stamina, BPI_SuitAbilities, & BPI_WeaponTargeting.

  • Members of struct Struct_GadgetData modified.

  • New Structs added: Struct_AbilityData & Struct_WeaponData.

  • Widget Blueprints Widget_TopDownHUD & Widget_InGameHUD renamed to Widget_InGameHUD & Widget_MissionSummary respectively.

  • New Widget Blueprint added: Widget_InventoryButton.

Hey there! I just bought the kit, super useful to learn! Everything’s great so far… except I found a small glitch.

If I enter and leave the stationary camera while sprinting, it won’t lose my track. It keeps updating the position and follow me like, no matter the distance.

I’m a bit tired now if you need I can make a video or something. I’m using 4.13

Cheers!
Luke

Hi Luke, thanks for your feedback & also for pointing out the bug. I was able to reproduce it & the fix will be submitted today to the Marketplace team.

Meanwhile if you want to continue along with your project, you can check out the screenshot below for the fix. It only involves connecting two nodes in the ‘BP_StationaryAI_Parent’ blueprint. Drag the pins for ‘Medium’ & ‘Low’ cases of the switch node right at the opening section of the ‘Vision Check’ custom event & connect it to the ‘Set Active Target’ to null node further down the event flow as marked in the screenshot.

Perfect! Thanks!

Keep up the good work!! :smiley:

Glad to hear that it’s working, Luke. The update has been submitted to the Marketplace team & should be available through the launcher in the coming days. Again thanks for pointing out the error. :slight_smile:

Edit: The v1.3.1 update has gone live on the marketplace & has fixed the aforementioned bug.