Top Down Stealth Toolkit

Hi @dresyn2k8 , it’s been quite a while since I’ve tried it out in FPS/TPS viewpoints, but at the very basic level it should work fine. There are definitely going to be certain elements like say, aiming, which is probably not going to work out of the box since they function differently in a top down scenario. As for the remaining elements like AI, I’ll have to do some tests before giving you a more clear cut answer. So let me get back to you on that.

Yea, there’s nothing stopping you from remapping the movement to a game pad.

As for the vision cones, the visualization itself is not suited to first/third person perspectives since it’s a 2D representation of what the AI can or cannot see. And turning it off is as easy removing a couple of components (and any leftover references) in the enemy parent blueprint. But since this is a 3D project, the AI’s true vision cone (what it actually sees) works the same as what you’d expect in any 3D game. So it doesn’t matter whether the player is above it or below it, or behind a waist high ledge. As long as the trace fired from the AI to the player doesn’t get blocked by something, it works as intended.

Thanks, I’ll probably be purchasing tomorrow when I get up and around. Appreciate your clarifying.

Hey, I was able to get most of the basic systems working in a third person perspective. Here’s a Dropbox link to a playable gameplay demo with the third person modifications: https://www.dropbox.com/s/3t2bg7bowp…onTest.7z?dl=0. I’d suggest you take it for a spin and see if it matches your design criteria. If you’re interested, just let me know. I’ll upload a tutorial showing how to make the necessary changes.

As mentioned, aiming weapons don’t work, but you can move and look around in third person. The 2D Line of Sight visualization for patrol guards have been removed and the AI seems to be working as intended. I’ve added an elevated position and a waist high ledge for you to check out how the AI deal with those scenarios:


Finally here are the input controls for the demo:

  • WASD: Movement
  • Mouse: Camera Control
  • Left Shift: Sprint
  • Q: Whiste to attract the attention of nearby AI guards
  • F: Activate Portable EMP to disable nearby Cameras & Turrets

Awesome man, thanks. If you could upload that tutorial it would be much appreciated. I would imagine while the aiming and shooting may not work out of the box, we could tinker and add it in.This seems much more Volume-like than MGS1, but they’re so similar thats why your kit drew my attention.

nvm you’ve posted these multiple times(re: migration)

What I am now wondering currently is finding:

The state machine, for adding more states for the player, ie: crouching, crouch walk, prone, crawling, cover

As well as: segmenting the vision cones. So may 50% of the cone, if the players finds themselves in this, immediate alert, where as if you’re in the out most parts it’s a “who or what was that?”

Also, using a dynamic camera, with full movement and camera control, imagine like using joystick 1 and 2

Well, you’re right about that. I started this project right around the time Volume was released and it was a huge inspiration for the overall design of the toolkit. But since the AI was very limited in that design, it later got an upgrade bringing it more along the lines of what was implemented in Mark of the Ninja.

I’ll upload the Third Person tutorial later today. Will share the link here. As for the aiming/shooting mechanics, I think it would mainly involve using aim offsets to control the animation. So most of the major changes would be in the animation blueprint with some relatively minor changes in the player character/controller as well.

I’m assuming that you’re referring to the animation state machine for the player. The default movement is limited to Idle/Walk/Run + Aiming in 2D, all of which can be found in the following blueprints: ABP_Parent, **ABP_PlayerChar_Basic **(only keyboard based control), & **ABP_PlayerChar_ASP **(keyboard+mouse based control. They all get the work done through basic blendspaces. But since you’re going for multiple player states, it would require adding a state machine in these blueprints. If you don’t own any animation packs, I’d suggest copying over the state machine logic from Epic’s free Animation Starter Pack.

Regarding the segmented vision cones, the AI was designed around hard segmentation (either can see or cannot see at all) since 2D line of sight zones is Top Down games are great at portraying that. So I’ll go over it and let you know what can be done to change that.

As for the dynamic camera, I’m not sure I grasped the process of using joystick 1 and 2. Did you have an example in mind?

A lot of what I’m asking I can figure out for myself if i quit putting the cart ahead of the horse haha. I know you did the TPS with the mouse controlling the camera, so I just need to go in and change the input more than likely.

The state machine is about what I had gathered as well. I’ve got the starter pack and then some with Reallusion, so I think I’ll be good on that front. Just wanted to make sure I understood where everything was. Hope the state machine wouldn’t interfere with anything already in the kit.

The TPS part involves only some minor changes here and there, but yea mostly just changing the camera settings and replacing input logic. I’ll be covering all of that in the tutorial.

As of now, I can’t think of the state machine having any adverse effect on the existing systems. The only communication between the animation blueprint and the rest of the toolkit is the animation notifies to produce footstep noises when the player feet touches the ground. But that exists in the Event Graph. So anything you do in a state machine shouldn’t affect that behavior. But if you do run into a situation where it breaks any existing systems, just let me know.

@dresyn2k8 Here is the tutorial for converting your project into Third Person: Top Down Stealth Toolkit Tutorials - Google Docs.

For the gameplay demo, there was also an additional modification that was made to the AI Behavior Trees to make their movement appear smooth in Third Person when the AI guards lose track of the player. I’ll be adding it to the toolkit as a mini update tomorrow, but since the changes are relatively minor, will be sharing the screenshots for the same. I’d suggest making those changes to your projects as well after the tutorial.

Awesome, man. Thanks again.

Hi all,

I’m very new to the Unreal Engine (done some work in Unity in the past) and I’ve loaded up the sample map for this and I can’t seem to get the player character to walk around. I figured I could be missing some input controls or adding the player controller? Any advice would be useful. Thank you.

Hi there, the Game Mode and Player Controller should be set by default, but just to make sure that it’s not the problem, could you try checking if it’s setup like this under Edit >> Project Settings >> Maps & Modes.

If everything checks out here, then add a Print String node to your **BP_PlayerCharacter_Parent **blueprint as shown here:

Could you check if it’s printing when you play the game. This will let us know if the input is working. Also the default controls are all tailored to keyboard and mouse. So if you’re using a controller, input events would have to be set up for that.

Thanks… I completely recreated the blank project and it is now working. I stupidly followed some “fixes” online for when the Unreal Editor gets stuck at 39% instead of just waiting and this must have caused the issue.

@arkanis50 Glad to hear that you got it working. :slight_smile: Yea the 39% issue is kind of a bummer. I think it happens only the first time you load a project in a new version of the engine, but it can seem like the engine just got stuck since it can sometimes take forever to get through.

Hey, I was looking in the thread and was looking at how to change the vision cone on the turetts and ai and it seems to be missing in the latest update. It would be cool for level design to have a category of public variables that control the behavior, to quickly block out the level. Is there a way to do this already? I couldn’t find the user defined category anymore.

Hi Ben, yea the vision attributes have been moved to the custom AI Perception component so that it can be easily added to all types of AI without having to create extra variables or functions to retrieve them (useful when you have multiple AI parent classes like with patrol guards and turrets). So you can open up the Turret or Patrol Guard blueprints, select AIPerception, and set the **VisionRadius **& **VisionAngle **parameters under the Visual Perception category. I would love to have these variables exposed to the editor, but using variables from a component in the construction script, seem to ignore any modifications you make to variables in the Editor (see issue here: https://answers.unrealengine.com/que…-that-are.html). The issue has been around since the beginning of UE4, so I don’t expect the situation to change in this matter.

However, if you want to expose the variables to the editor for testing, there is a workaround. Just create new variables VisionRadius & Vision Angle (both set to Instance Editable in their details panel) add the following node to the Construction Script (at the start) for **BP_PatrolGuard_Parent **& **BP_AutomatedSurveillance_Parent **blueprints:

Now when you select the actors from the level editor, you should be able to edit both of these variables to see the changes to the vision cone. Once you’re satisfied with the changes, you can then add the new values to the Visual Perception values and disconnect this node since there is a chance that it might conflict some of the AI logic.

Nice thanks, the other thing I was thinking about was on level complete, is there a way to do a load next level by name? I’m really happy with what it is atm, it seems like a complete system as in most of the game play would be in the level design without needing to add much more. I was thinking it would need an is valid to check to see if the level exists, and then maybe pull the name of the next level from an array or enum of level names, then open level. It seems well within my capabilities, but I’ve notice that most of your blueprints are really short and to the point. So I was wondering what would be the best way to go about this, like what is your philosophy on the functions naming and such? Like how do you determine what goes into what function.

I’d suggest having a **Name **type array in the **BP_GameInstance **blueprint, with element 0 containing the Main Menu map name, 1 corresponding to the 1st level map name, and so on. You can then create an **Int **variable to keep track of your current level index in the array. For example, when you finish the first level, and has clicked on the Next Level button, you increment this variable by 1, then retrieve the element at that index in the Level Array, and call Open Level on it.

As for the UI side of things, we’ll have to go to the widget Widget_MissionSummary. You can create a duplicate of its Restart Button and change its text to “Next Level”. You can then have the On Clicked event for the new button to tell the BP_Game Instance (which can be called from anywhere by Get Game Instance >> Cast to BP_GameInstance) to handle the transition logic, which includes incrementing the tracker and opening the map name at that index in the array.

Apart from that, in the Event Construct of the widget, the validation check you mentioned can be added by asking BP_GameInstance if the array has an element at the next index. If it doesn’t, hide the Next Level Button, else make it Visible. Here is a sample screenshot of the same from one of my other projects:

Also, it would be a good idea to keep all of the Level Transition logic (index validation, increment, level array access, open level, etc) within the Game Instance blueprint. This way the UI does not have to know anything about the transition logic. All it does is tell the Game Instance that a certain event has happened, and lets it handle the rest. Plus if you have to do some debugging in the future, you’ll know that all the level transition logic is within the Game Instance BP only.

I believe that should get the level transition up and running. Just let me know if you have any doubts regarding the workflow.

You’re awesome btw, just wanted to point that out. Thanks for responding! Maybe hide the button and then unhide another button to return to the main menu and start over, hmm. Also I’d like to include some puzzle blueprints, I’m think that that will be as easy as changing the game mode in a different map file. Thanks for the help! Do you have a donate button and what are the rules for working with an animator or other ppl on this project of mine? Ue4 recently released the multiuser editing and there are stuff like scene fusion I think and source control, do I need to pay a team license and how does that work exactly? I don’t mind it’s only fair, it’s just that you can only get one copy on the market place.