Wednesday, October 25, 2017

Tower Defense Starter Kit Tutorial: How to create a new level

1. First ensure that the default Game Mode & Game Instance class parameters in the Project Settings are set to BP_GameMode & BP_GameInstance classes respectively.

2. Now create a new map, open it, & lay down the navigable area for AI bots by placing instances of BP_AIPath across the level. Add a Navmesh Bounds Volume & extend it to encapsulate all the AIPath actors.

3. Add a Lightmass Importance Volume around the core game space.

4. The BP_AIPath actors that we added earlier has a secondary function apart from providing a traversal space for the AI bots. And that is to allow the deployment of Global Abilities like Airstrike. Everytime a player selects a global ability, a targeting reticule is activated to point the precise location for deployment. However if we have empty spaces in the level, this can be an issue as there will be no surfaces to block the GlobalAbilityTargeting trace channel. In order to rectify this issue, the toolkit provides a solution in the form of the BP_PlayerMovementBounds class. While it is an invisible actor, it can block all types of trace channels, & thus provide a platform for displaying the targeting reticule even when there are no underlying meshes under the cursor location.

So the next step is to add a BP_PlayerMovementBounds actor just below the lowest point along the AI path. Now set it's 'Trace Blocker Extent' parameter to cover an area larger than the maximum visible game space as seen through the player camera. With that, we have essentially added the ability to use Global Abilities.

Now onto the primary functionality of this actor. As the name suggests, this actor can be used to restrict the movement of the player camera. The movable space for the camera is determined both by the 'Tracer Blocker Extent' value as well as the 'Blocker Bounds To Movement Bounds Ratio' attributes [check screenshot below]. For example, the default ratio of 3.0 to 1.0 ensures that the player camera can move around in an area corresponding to middle one third of the space covered by the actor's trace blocker volume.

5. Since we've already laid down the paths for the AI bots, the next step is to add instances of BP_EnemySpawnPoint along the paths to act as spawning points for the enemy waves. As can be seen in the next screenshot, I've added a couple of spawn points in my level:

6. Now add a BP_ExitPoint actor somewhere along the path to provide the primary movement target for the enemy AI bots.

7. The toolkit uses modular grid generators to act as platforms for tower placement. But before adding them into the scene, first add a BP_GridManager actor. Use it's publicly exposed variable 'Grid Cell Size' to specify the size of the individual grid cells across all grid generators in the level.

8. With the grid cell size specified, it's now time to add the grid generators. Drag & drop instances of BP_GridGenerator into the level. The overall size of the generator in the X & Y (local space) directions can be specified through the 'Grid Count X' & 'Grid Count Y' variables as shown below:

9. Now add an instance each of BP_ProjectileManager & BP_ObjectPoolManager into the level. If you plan to use the pooling system, just set 'Pool Bullet Projectiles?' to true through the details section of the actor. Since this system uses a fixed size pooling system, also make sure to specify the pool size through the 'Pool Size Bullet Projectile' variable.

10. Now comes two of the most important classes required for the functioning of the toolkit: the Tower Manager & Wave Spawn Controller. Add the BP_TowerManager actor first. There's no need to make any changes to it's default parameters, but if you want to know more about the class, check out the concept overview post for the same at:

Next, add an instance of either BP_BatchedWaveSpawnController or BP_WeightedWaveSpawnController to the level. While most of the default parameters will work right out of the box without any need for customizations, you will have to add references to the enemy spawn points within the publicly exposed array 'BatchedWaveSpawnDataArray', if you're going for the former model. Just make sure to specify the 'SpawnPoint' for each wave by linking it to one of the spawn points added to the level in Step 5.

For further reading about the wave spawning systems, see:
11. Now onwards to the final step. All that's left to do is to add level bounds so that actors like projectiles that BP_LevelBounds can move across the level gets destroyed once they cross a certain threshold. Add six BP_LevelBounds actors along the outer periphery of the level, making sure that they form a cuboid shape to encapsulate the entire level.

With that, you should have a fully functional level at your disposal. If you have any queries regarding the workflow, feel free to let me know in the comments section.

If you're interested in the toolkit, you can purchase it through the Unreal Engine Marketplace:

Sunday, October 15, 2017

Top Down Stealth Toolkit Basics: Global Alert Level System

The following information is based on the v2.1 edition of Top Down Stealth Toolkit & hence may not remain entirely relevant in later versions. For more information about the toolkit, check out the official support thread in the Unreal Engine forums:

The v2.1 update for Top Down Stealth Toolkit introduced a Global Alert Level Controller (GALC) tasked with controlling high-level AI responses to the player's actions. While all AI agents still retain their individual alert level systems, the GALC acts as an autonomous outside listener that keeps track of stimulus perception events, 
with minimal coupling to existing systems within the toolkit. With every new instance of a stimulus being perceived by an AI agent, the Global Alert Meter keeps rising based on the perceived threat rating of the stimulus. As the meter crosses certain threshold values, the Global Alert Level system kicks into action by activating the designated responses associated with the new state. These could include activation of automated security devices like lasers & turrets, as well as the deployment of reinforcement patrol guards to ramp up the difficulty of the mission over time.

The Global Alert Level Controller provides the following options to control the functioning of the new alert level system:

1. ThreatRatingModifier: Controls the rate at which Global Alert Meter goes up. While the perceived threat value of a stimulus is the major deciding factor when it comes to rising global alert levels, this modifier can help control the overall growth curve without having to tune the threat value of individual stimuli.

2. GlobalAlertLevelEscalationData: Determines how the game state changes in response to an increase in the Global Alert Level, based on the following parameters:

  • AlertLevel: The Global Alert Level associated with the state.
  • AlertMeterTarget: Minimum Global Alert Meter value required to reach the associated level.
  • AlertSystemResponse: Determines the actions taken by the AI in response to an increase in the Global Alert Level. Every time the Global Alert Level reaches a new state, the 'ResponseType' associated with the same gets relayed to the AI Surveillance Controller class which processes the request & performs the necessary actions. While the default setup offers up to three types of responses (Idle, ActivateIdleAgents, & Deploy Backup agents), more customized response types can be easily integrated into the system through this parameter.
  • AlertDisplayBackgroundColor: Determines the background color of the UI element that displays the Global Alert Level.

Tuesday, October 3, 2017

Unreal Engine Experiments: Borderlands 2 Damage Display System

I recently started working on some side projects during free time to experiment with & learn about interesting gameplay systems from my favorite games. And Borderlands 2, being high up on the list, I decided to create a working model of its Damage Display system using blueprints. It's finally done & here is a video demonstration of the system:

The system uses widget components attached to dynamically spawned actors, to draw the text on screen space. Just as in the game, the floating damage texts move along a parabolic path, while the critical hit status text moves along a normal linear path in the upward direction. Both of them keep scaling up till a certain point along the path, & then start scaling down for the remainder of its journey, thus creating a sort of pop-out effect. Another factor that controls the scaling of the text display is the distance from the player character, thus increasing/decreasing its size [the text becomes less clear over long distances in the video, but is much crisper in the actual game instance] based on player movement.

The Damage Display System is being released for free [no attribution required] through Github at:
So feel free to check it out, & use in your projects if you like it.

Saturday, September 16, 2017

Thoughts on Game Design: XP Management Systems for Tower Defense Games

Two years ago, before I first started working on the Tower Defense Starter Kit, I had done some research on various games from the genre to understand the design process behind the underlying gameplay mechanics. Among the lot were popular games like Kingdom Rush & Defense Grid, as well as their lesser-known counterparts like Anomaly Defenders & Sentinel 4. Each of those games had some interesting unique feature that made them stand out & Sentinel 4 actually had quite a few of them going for it. Of special note among these, was the fact that towers leveled up on their own over time. This single design choice added a whole new layer of tactics when it came to tower placement, right from the early stages of a mission.

A couple of months ago, I finally got around to adding an experience based auto-leveling system to the toolkit. While I thoroughly enjoyed Origin8's (Sentinel 4 Developer) take on tower defense, one aspect that concerned me was the decision to use a last-hit driven XP management system. I've never been a fan of this mechanic, as it kind of negates the impact of all other entities that were crucial to taking down a target. So I ended up experimenting with alternative solutions, hoping to find something that can level out the playing field. But before delving further into that topic, I'm going to point out the different options available to us, so as to provide a better idea about the reasoning behind the final decision.

Last-Hit based XP Management System

First, we have a last-hit based XP distribution system, whereby an entity gains experience by landing the killing blow on an enemy. It works especially well in games where the player controls only one character at any point in time, as the designer does not have to worry about sharing XP with other entities. It is also easy to implement & tweak since the experience gain directly depends on the player & enemy levels. However when multiple entities are vying for experience at the same time, distributing XP based on kills could lead to balance issues.

To provide an example for such a scenario, let us consider two common types of towers in Tower Defense games: Laser towers & Sniper Towers. Laser towers do continuous damage against a single target & hence excel at clearing out waves of low HP targets with ease. Sniper towers, on the other hand, fire extremely powerful rounds at a single target with a considerably high reload time to boot. This makes them ineffective against fast moving crowds but can take down tougher opponents relatively quickly. Under normal circumstances, both seem to have their own advantages & disadvantages, & thus end up being useful under different types of scenarios.

However, upon further inspection, I noticed that the advantages conferred by the system don't always hold up. When you factor in late-game scenarios, especially in endless wave modes, the Laser towers in spite of dealing a lot of damage, might not get a lot of kills. At the same time, the Sniper towers owing to their much higher burst damage output might have a higher chance of taking down targets. Over time, this could make them level up faster, thus increasing their damage output, which ends up getting them more kills, thus rendering them capable of dealing significant damage even as tougher enemies start spawning. This could lead to the Laser towers becoming less useful over time, as the damage output fails to keep up with increasing enemy HP.

Of course, there is the option to provide XP to all towers in the vicinity of a fallen enemy, making sure to give an extra bonus to the tower that dealt the killing blow. But I did not want to go down that route unless there was no other choice.

Damage based XP Management System

Next, we have the less ubiquitous damage driven system which distributes XP for every instance of damage inflicted by a game entity. This ensures that every participant gains experience based on their individual contributions. However, it does come with its own set of problems. For one, it will increase the complexity of the process flow by a slight margin, as projectile based towers will have to listen to the impact data of every single projectile, before getting the XP returns. This extra effort might really not be worth it, since the player may not even notice its passive impact, among all the different actions that are required to be performed. The second, & more important issue is that certain AoE towers like Flamethrower towers might end up dealing huge amounts of damage against crowds, thus enabling them to level up much faster than their contemporaries. An additional side effect of this system is the possibility of not getting any XP from shots that miss. For example, Artillery towers fire slower arcing shots that can easily miss their mark, unless the target path has been anticipated before launching the projectile. All of these problems combined would entail the project requiring more amount of time dedicated to maintaining game balance. And that leads us to the third system.

Output based XP Management System

After coming to terms with the potential difficulties associated with both the aforementioned systems [when applied within the tower defense game space], I tried breaking down the issue to see if there is a way to come up with something that had the advantages of both while reducing the unnecessary side effects. The solution sprung up in the form of an output based experience gain system. In this scenario, towers gain experience at the end of every output cycle, irrespective of whether it led to the death of an enemy, or the amount of damage inflicted. In a game where the player is directly in charge of the output generation, this system, if not monitored, could be exploited easily to gain experience without actually engaging in combat. However, the towers being completely free of the player's volition are not capable of the same & can be trusted to always play a fair game.

This new system essentially combines the reduced complexity of the first system with the evenly distributed experience gains of the second. As far as the player is concerned, the tower keeps accruing more XP everytime it attacks an enemy, albeit at different rates. Moreover, it provides a high level of predictability in terms of XP growth, as it's entirely reliant on the tower's rate of fire. By comparing the total output generated by each tower in a specified amount of time, the distribution of XP can be easily balanced by the designer. Even so, one disadvantage that pops out when compared to the first system is that the amount of XP gained per cycle does not depend upon the enemy levels. However, this can also be easily taken care of, by introducing the wave number/cycle data to act as an XP multiplier.

And thus, after considering all the options, I ended up going for an output driven system for XP growth. While it may not be feasible for most types of games, it seems well-suited for use in the Tower Defense genre.

Thursday, June 22, 2017

Top Down Stealth Toolkit Tutorial: How to control the AI Perception model for AI agents

The following information is based on the v2.0 edition of Top Down Stealth Toolkit & hence may not remain entirely relevant in later versions. For more information about the toolkit, check out the official support thread in the Unreal Engine forums:

The Top Down Stealth Toolkit uses a custom Perception system to evaluate potential threats for the AI agents. It's user defined properties can all be edited through the component details panel from the owning blueprint, thus facilitating creation of different threat perception models for different types of AI agents. This tutorial will go over the basic parameters that control the working of this system.

Visual Perception Data:

1. IsVisualPerceptionEnabled?: Determines if the agent can use Visual Perception to perceive stimuli.
2. Vision Range: Determines the direct line of sight range.
3. HalfVisionAngle: Determines the half angle for the agent's cone of vision.

Aural Perception Data:

1. IsAuralPerceptionEnabled?: Determines if the agent can use Aural Perception to perceive stimuli.
2. HearingRange: Controls the maximum distance at which a sound of default loudness 1.0 (controlled through the 'PerceptionRangeModifier' parameter of interest stimuli: Breakdown of Stimulus Parameters) can be perceived by the agent.

Intuitive Perception Data:

1. IsIntuitivePerceptionEnabled?: Determines if the agent can use Intuitive Perception to perceive stimuli.

Motion Perception Data:

1. IsMotionPerceptionEnabled?: Determines if the agent can use Motion Perception to perceive a stimuli.
2. DetectionRange: Determines the maximum range at which stimuli can be sensed.
3. DetectionCounter: A counter that decides if the agent should respond to the stimulus [Used because this is an indirect form of perception]
4. CounterIncrementPerCycle: Controls the rate at which the Detection Counter increases if the stimulus is in range.
5. CounterDecrementPerCycle: Controls the rate at which the Detection Counter decreases once the stimulus goes out of range.
6. CriticalDetectionValue: Determines the threshold point for Detection Counter, at which the agent responds to the stimulus.
7. DisplayAlertnessLevel?: Determines if changes in the Detection Counter value need to be displayed in the game space.

Can Perceive Interests?: Determines if the Agent can perceive Interest Stimuli. If set to false, only Target stimuli will be perceivable.

Note: The Perception system has no awareness about it's owning actor & uses a custom interface to receive & send messages. So if you're using a custom AI agent, make sure that the owner class implements the BPI_SensorySystem interface & it's functions. For reference, check out the implementation of the interface functions in BP_PatrolGuard_Parent.

Sunday, June 18, 2017

Top Down Stealth Toolkit Tutorial: How to create a new custom Interest Stimulus

The following information is based on the v2.0 edition of Top Down Stealth Toolkit & hence may not remain entirely relevant in later versions. For more information about the toolkit, check out the official support thread in the Unreal Engine forums:]

The v2.0 update for Top Down Stealth Toolkit introduced a dedicated stimulus driven AI perception system. This tutorial will go over the process of using the aforementioned system to create a new Interest stimulus from scratch.

The base attributes for Interest stimuli are controlled through the 'InterestStimulusDataArray' in BP_AISensoryManager class. Each element of the struct array contains details about a specific type of Interest & hence provide an avenue for easily customizing it's properties. Before going into the actual process of creating a new Interest, I'll provide a brief description of the various parameters that control that control these stimuli.

1. InterestType: Determines the type of Interest associated with the array element.

2. PerceptionType: Determines the AI perception model that can detect this Interest. [For more information on the AI Perception system, check out:]

3. ThreatClass: Determines the priority level of an Interest when it comes to override requests. For example, an Interest of lower threat class will not override one of higher threat class, thus making sure that the AI retains focus on the stimuli based on their relative importance. By default, all Interests have a threat class level of 1.

4. PerceivedThreatValue: Maintains a normalized [0.0 to 1.0] value of the threat rating of an Interest as perceived by AI agents. Higher values of this parameter will make AI bots go directly into a high alert level state. Within a single cycle of sensory evaluation, Interests with higher value of this parameter within a threat class, are evaluated first to ensure that the AI responds to the most immediate threat.

5. PerceptionRangeModifier: Controls the range at which an Interest can be perceived by adding a distance modifier to the agent's perception checks. For example, Alarm & Gunshot noises have a value of 2.0, thus ensuring that an AI agent possessing a hearing range of 500 m can perceive these stimuli up to double the said distance.

6. PerformRangeTestToInterestCreator: Determines if AI perception tests should conduct distance checks against the actual Interest location, or the entity that created it. For example, perception checks for alarm noises are conducted against the actual source of the noise itself, even though the Interest location would be set as the location of the entity that triggered the alarm.

7. TrackAlertedAgents?: Determines if the Interest object should keep track of agents that have been alerted to it's presence.

8. UseInterestCreatorLocation?: Controls whether the AI agents that detected this stimulus move towards the Interest location or the actor that created it.

9. AutoDeactivate?: Controls the active lifespan of the Interest. For example, noise stimuli have this parameter turned on, thus making them relevant only for a single evaluation cycle.

10. IsInteractive?: Determines if the AI agents can interact with the Interest. If turned off, the AI bots will only investigate the source location.

11. InteractionModel: Controls the manner in which an agent interacts with an interactive Interest. For example, patrol guards will use the 'Reactivate' interaction model to wake up any incapacitated allies they may come across.

12. SortedPriorityOrder: This parameter is set automatically at the start of a game based on the threat class & perceived threat value of the Interest. Ensures that AI Sensory Manager evaluates the Interests with higher priority order before moving on to the rest.

Now in order to create a new Interest, first add a new entry to the enum 'EInterestStimulusType'. All that's left is to add an element to the InterestTypeDataArray for this new type, & assign the parameters mentioned above as per the requirements.

Friday, June 16, 2017

Top Down Stealth Toolkit Basics: AI Perception

The v2.0 update for Top Down Stealth Toolkit introduced a custom component driven AI Perception system tailored specifically for implementation in Stealth games. This system uses a combination of four different perception models to evaluate threats based on the new Stimulus model introduced in the update.

Perception Models:

1. Visual Perception: Using a combination of distance, angular, & line trace checks, the Visual Perception enables an AI agent to detect stimuli within it's direct line of sight range. It is capable for sensing Target stimuli as well as certain types of Interest stimuli like Incapacitated & Defunct allies.

2. Aural Perception: The Aural Perception enables an AI agent to perceive & track noises created in the vicinity. It factors in the Loudness of a noise while performing the distance check operation, in order to gauge the relevance of the stimulus. This ensures that louder noises can potentially be heard by an agent, even if it was created outside the default hearing threshold.

3. Intuitive Perception: The Intuitive Perception model is used by AI agents to evaluate stimuli based on their memory, thus negating the need to do any form of range checks. For example, a target that has evaded a Patrol Guard's line of sight can trigger the creation of a Missing Suspect stimulus using it's memory about the target's last seen location, which can then be perceived through this system with very minimal search costs.

4. Motion Perception: Unlike the other perception models, the Motion Perception is used to evaluate stimuli that have not been directly perceived by the agent. An example of this would be a stimulus created by an entity located in close proximity to an agent, but not necessarily within it's direct field of vision. As a result, this system uses a dedicated alert meter to make sure that the agent responds to a perceived stimulus only if it stays within range for certain period of time.

All or any of these systems can be modified or turned off from the owning class, thus facilitating creation of different types of perception behavior among two types of agents like say, a Patrol Guard & a Surveillance Camera.

Wednesday, June 14, 2017

Top Down Stealth Toolkit Basics: Stimulus Types

The v2.0 update for Top Down Stealth Toolkit introduces a new Stimulus generation system that will enable the users to easily customize & add new types of perceivable events for the AI agents. Inspired by the AI Threat Detection system used in the 2D Stealth game - Mark of the Ninja, the stimuli are primarily divided into two categories: Targets & Interests.

The Target Stimuli represent the highest level of threats that can be perceived by the enemy AI. Once an agent has acquired a target, it will focus all it's attention on the said stimulus, with complete disregard for anything else until the target actor manages to evade it's line of sight. The Player Character is an example of an entity that registers itself as a target stimulus.

The Interest Stimuli on the other hand, represent cases that require some level of preemptive investigation before an agent can make further decisions. These are more varied due to the multitude of attributes that define them (more on this to be added in a later post), & hence split into the following categories:

  1. Incapacitated Ally: AI agents that get incapacitated at any point of time will register itself as an Incapacitated Ally. These interests will continue to exist for as long as the agent remains in the said state. However, since they support interaction by other agents, the stimulus creator can be brought back to an operational level, at which point the interest will be set to a deactivated state.
  2. Defunct Ally: Created when an agent gets terminated & will remain an active stimulus till the end of the level. These interests keep track of agents that have been alerted to it's presence & hence ensures that a single agent will respond to it only once.
  3. Alarm Noise: Created whenever an alarm has been raised by any entity. Has a very short lifespan, but can put agents on a high alert state.
  4. Gunshot Noise: Created when a non-silenced weapon is fired. Works similar to the Alarm Noise interests at a functional level.
  5. Missing Suspect: Created by AI bots based on the their memory about the last seen location of a target. Can only be perceived by the agent that registered the stimulus, but requires no form of range checks.
  6. Footstep Noise: Noises created by the player character's footsteps can be perceived by AI agents through these type of interests. Has a very short lifespan, & generally perceived as a medium level threat.
  7. Whistle Noise: Functions similar to the Footstep Noise interests, but created when an entity uses the Whistle.
  8. Peripheral Motion: Represents all entities that can be perceived by AI agents based on the proximity level. Unlike other interests, this stimulus will remain active throughout the lifespan of the actor responsible for creating it. However, owing to the indirect nature of perception used to detect this form of stimulus, the AI bots will react only if the stimulus creator remains in close proximity for a certain period of time.

Monday, May 22, 2017

Tower Defense Starter Kit Tutorial: How to add custom Tower Abilities

[The following information is based on the v1.6.3 edition of Tower Defense Starter Kit & hence may not remain entirely relevant in later versions. For more information about the toolkit, check out the official support thread in the Unreal Engine forums:]

The Tower Defense Starter Kit features two Tower Abilities (Overdrive & Repair) than can be added to the towers in order to provide the player with an additional element of control over the gameplay. This tutorial will go over the steps involved in the creation of a new Tower Ability & it's integration with the existing system.

Before delving into the matter of actual implementation, I think it would be best to understand that there are generally two types of dynamically driven abilities: sustained abilities that modify the functioning of the targeted actor over a brief span of time, & momentary abilities that cause a certain change within the system for just an instant of time. Overdrive & Repair are sustained abilities & hence I would like to show the creation of a momentary Shockwave ability with this tutorial. 

1. Create a duplicate blueprint based off of the 'BPC_OverdriveAbility' class. This will provide you with a base template for the new ability without having to start from scratch. At this step of the tutorial, there is a slight difference based on which direction you want to take.

If you plan to create an ability with sustained effects, there is no need to make any changes to the default parameters right now.

On the other hand, if you want to have a momentary ability, then delete the following variables: RemainingTime, AbilityDurationDisplayUpdateTimer, AbilityDurationDisplayUpdateTimerInterval, AbilityStatusBarFillColor, & AbilityDuration. Also make sure to delete all instances of the ability duration timer within the component.

2. The next step is to modify the following text variables to suit the description of your new ability: AbilityName, AbilityNameAbrreviation, AbilityDescription, HUDStatName_CoreFunction, & HUDStatsName_LimitingFactor. These variables determine the information displayed about the ability in the HUD.

3. Now create the variables that would be required for the functioning of your Tower Ability. For example, I'm going to add a couple of float variables named 'ShockwaveDamage' & 'ShockwaveRadius' [see sample screenshot below]. For a very basic shockwave ability that does damage to all enemy units in it's range, that should be enough. For now, that's all there is do within the ability component class. We'll come back later to write down the actual implementation once the remaining factors are taken care of.

4. Open up the enum 'ETowerFunctions' & add a new entry with the name of your new Tower Ability.

5. Now that we have the new enum entry & component set up, you can add a new ability to the list maintained in the 'BP_GameInstance' blueprint. To do this, add a new element to the Tower Functions Array & make the following changes to the default values: set the 'FunctionType' as the new enum value, & the 'AbilityComponent' as the custom component; the 'AbilityCost' can be set to any arbitrary non-negative value; under the 'CompatibleTowers' list, add all towers that should be able to use the new ability; & set the 'Unlocked?' parameter to true.

Here is a sample screenshot for my Shockwave ability entry:

6. The next step is to integrate the new Tower Ability into the system through the 'BPI_TowerAbilities' interface. You will have to add new functions to handle the following cases: to add the new ability component to the tower actor, to activate the ability, & to deactivate the ability. The last two functions are only necessary of it's a sustained ability. If you check out the interface functions list, you will notice that both overdrive & repair abilities have these two functions to handle it's activation/deactivation. Since I'm creating a single fire ability, only the first function is required as shown below:

7. Now head over to the 'BP_Tower_Parent' blueprint & implement the newly created interface functions. In order to add an ability component, just copy the same code from the equivalent interface function for the overdrive ability & replace the Add Component node (check screenshot below) with the node to add the new Tower Ability component. With this function set up, you should be able to request a call to activate the ability from other classes that interact directly with the player. In case of sustained abilities, make sure to implement the Activate/Deactivate functions as well. Basically these functions are used to modify/reset any changes made to the Tower's attributes by the component. You can check out the implementation for Overdrive/Repair abilities as a reference, if there are any doubts.

8. Open the 'Widget_TowerFunctionsButton' class & call the previously added interface function for adding the custom ability component & connect it to the switch case output for the associated entry as shown below:

Also make the following changes within the 'UpdateTowerFunctionWidgetState' function:

With these connections set up, the player interactions with the tower function button for the new ability will be able to connect with the tower in order to pass on the request.

9. Before going into the implementation of the ability, there's one more thing to be taken care of & that is to add the code to display information about it through the stats UI element when the mouse hovers over the tower function button. This is handled through the 'GetTowerAbilityClassInformation' function in the 'Widget_TargetInformation' class. Just copy the nodes connected to the overdrive switch case, & paste it elsewhere. Now swap out the cast with a cast to your custom ability component & connect it to the corresponding switch case output as shown below:

10. The final step is to head back to the tower ability component & write down the actual implementation for your ability. In my case, I'm going to add an apply radial damage node & connect it to the begin play event to do damage to all enemy units around the tower.

With that, we've come to the end of the tutorial & you should have your own version of tower ability ready to go. If anyone has any doubts regarding the workflow, feel free to post in the comments section.

Saturday, April 29, 2017

Unreal Engine Diaries #12

1. Blueprint function libraries cannot be accessed from an Object class.

2. If you spawn a base 'Actor' using Spawn Actor from Class function, it's transform (or the individual sub components like location, rotation, & scale) cannot be modified.

3. The 'Get Game User Settings' node can be used to get the local machine settings like screen resolution, texture quality, etc, but this function returns the settings data from the memory & not from a permanent storage location like the hard disk. This means that if the player had used 'Save Settings' prior to this function call during the same instance of the game, it would not return the saved information.

4. The 'Load Settings' & 'Save Settings' function [accessed through the Get Game User Settings node] loads/saves settings data from/to the disk. While saving new data, it does not apply these settings parameters to the game. So it's generally used in scenarios where the player has to restart the game to see the desired effect.

5. The 'Apply Settings' function [again accessed through the Get Game User Settings node] on the other hand, takes the active game user settings from the memory, applies these to the game, & saves the information in a permanent storage location.

Tuesday, April 25, 2017

Top Down Stealth Toolkit Tutorial: How to modify the size of noise pulse emitters

The Top Down Stealth Toolkit uses pulse emitters to display various types of noises. More than just being visual effects, these emitters also provide the added benefit of displaying the audible range of noise stimuli.

The noise pulse emitter's radius is indirectly dependent on two user-defined factors: one being the AI bot's hearing sense radius, & the other factoring in the loudness of the noise itself. By default, the patrol bots have a hearing sense radius 'r' of 500 units. This basically means that a noise event with a loudness value of 'l' (default = 1.0) can be heard by the AI bot up to a maximum distance of 'r*l' units. For example, the footstep noise with a loudness value of 1.0 can be heard up to 500 units, while a different custom noise event with a loudness of 2.0 could be heard from a distance of 1000 units. This maximum distance corresponds to the maximum size of the pulse particle effect.

In order to demonstrate how to edit this value, I'm going to increase the AI hearing sense radius to 800 units & have the same loudness of 1.0 units for the noise event. So first we have to edit the hearing sense radius from the AI Perception component of the Patrol Bot parent class as shown below:

Since the footstep noise loudness is 1.0, I'm not going to edit it. So now we open up the 'P_FootStepPulse' particle system asset & make the following changes:

1. Within the 'Initial Size' module, set the Start Size value to be (1.0, 1.0, 1.0) [the already existing value works as well, but this is easier to understand]

2. Now within the 'Size by Life' module, set the Life Multiplier out value for point 1 to (1600.0, 1600.0, 1.0). This value is basically a multiplier for the initial size value. Point 0 corresponds to the starting value & hence we multiply it's size with the default (1.0, 1.0, 1.0) & while point 1 (which corresponds to final moment of the particle lifespan) multiplies the x & y values by 1600 units thus forming a circular ring of radius 800 units.

With that, you should be able to control the radius of the noise pulse. You can check more learning content at:

Friday, April 21, 2017

FPS Tower Defense Toolkit Basics: Holographic Tower Constructor

[The following information is based on the v2.1 edition of FPS Tower Defense Toolkit & hence may not remain entirely relevant in later versions. For more information about the toolkit, check out the official support thread in the Unreal Engine forums:]

The Holographic Tower Constructor represents the part of the Holographic Tower Display system that displays Holographic models of the tower designated by the player for construction. The Holograms are created & updated at run time through the 'BPC_HolographicTowerDisplay' component (attached to the player character) using information specified in the 'Holo Constructor Data' array, located within the Tower Manager. Listed below is a brief explanation of the different parameters that drive the Tower Constructor:

- The 'TowerType' enum identifies the data associated with the tower model selected by the player for construction.

- The 'Tower' parameter determines the base mesh (same as the mesh model for the actual tower) used to create the tower hologram.

- The 'LocationOffset_GridCellToTower' controls the translational offset of the tower hologram relative to the location of the focused grid cell.

- The 'UsesGridCellOrientation?' flag decides if the hologram will be partially or fully aligned with the grid generator. For example, the Trap holograms have this value set to true, since their spatial orientation completely match that of the underlying grid generators. The remaining towers (including the Tower Base) on the other hand, have this value set to false, since they only partially align (along the XY plane) with the grid generator.

- The 'HasTurretAttachment?' flag determines if the tower has a turret attached to it.

- The 'TurretAttachment' determines the mesh (same as the turret mesh model for the actual tower) for holographic display of the Turret (if any).

- The 'LocationOffset_TowerToTurretAttachment' controls the translational offset of the turret mesh hologram relative to the tower mesh hologram.

- The 'RotationOffset_TowerToTurretAttachment' controls the rotational offset of the turret mesh hologram relative to the tower mesh hologram.

- The 'DisplayTowerRange?' flag determines if the constructor needs to display the effective range of the tower.

- The 'LocationOffset_TowerToTowerCenter' stores the offset between the tower location & the central point of the tower mesh (specified based on the said offset in the actual tower class).

- The 'AffectsNavMesh?' determines if the placement of the tower affects the navigation mesh. This flag is set to true for the Tower Bases since the AI bots will have to path around them. As a result, the holograms for Tower Bases keep updating their color to convey the availability of valid navigational paths based on the tower placement location.

The Hologram itself will be displayed as long as the selected tower model can be created at the focused location. However, based on the construction pre-requisites like availability of tower resources & valid navigational paths, the hologram may change it's color to reflect the feasibility of constructing a tower of the selected variety under the given conditions.

Wednesday, March 29, 2017

Tower Defense Starter Kit Tutorial: How to create custom Towers

The following information is based on the v1.6 edition of Tower Defense Starter Kit & hence may not remain entirely relevant in later versions. For more information about the toolkit, check out the official support thread in the Unreal Engine forums:]

The Tower Defense Starter Kit comes equipped with seven types of Tower classes that all derive from the parent blueprint 'BP_Tower_Parent'. As the name suggests, this tutorial goes over the process of adding your own new customized Towers into the mix.

1. First we're going to have to create a new Tower class. To keep things simple, I'm just going to duplicate one of the existing Tower classes named 'BP_ShockwaveTower' & name it 'BP_CustomShockwaveTower'.

If you want to create a tower from scratch, you can do so by creating a child class derived from the 'BP_Tower_Parent' class. The only extra step involved is the setting of static mesh/materials for the 'Tower' static mesh component as shown below:

2. Now we need to make an entry for the same in the 'ETowerType' enumeration. I'm just going to name it Custom Shockwave.

3. The next step in the process is to provide the default stats for our new Tower. Since the toolkit uses a data driven approach to Tower creation, all default user defined attributes for the Towers are specified within the Tower Data Array (in BP_GameInstance class). Again I'm going to duplicate the array element for Shockwave Tower, & change it's 'SpawnClass' & 'TowerType' attributes to 'BP_CustomShockwaveTower' & 'Custom Shockwave' respectively.

The remaining attributes can all be changed based on the specific requirements for the tower & tooltips have been provided to specify the modifications that each attribute brings to the table. Here is a sample screenshot for the custom Shockwave Tower:

4. Now that the default attributes are set up, we need to register the new Tower for Tower Functions which includes Upgrades, Abilities, etc. The 'Tower Functions Array' in the'BP_GameInstance' class determines the functions that are available to the different towers.

To avail all the functions for our new Tower, we just add the associated enum value to the 'Compatible Towers' list for each function as shown below:

5. All that's left now is to make the necessary node connections that rely on the ETowerType enum. I've marked all of them in the screenshots below. Just connect the output nodes from the Custom Shockwave switch case to the designated input nodes as shown in the screenshots & the new tower should be good to go.




With that, we have covered the basic steps involved in creating a basic Tower class. If you have any queries about the procedure, feel free to contact me through the comments section or the aforementioned forum support thread for the Tower Defense Starter Kit.