Superior RPG Kit

Documentation

Features

Main features:
  • Single and Multiplayer Ready!
  • Third Person or Top-Down mode
  • Main Menu (with offline, host and join options)
  • Game Settings
  • Keymappings
  • Save and Load
  • Inventory
  • Equipment
  • Storage
  • Crafting
  • Skill Tree
  • Skills System
  • Quick Access Bar (for Skills and Items)
  • Level and XP
  • Stats
  • Attributes
  • Buffs
  • Effects
  • Quests (with Collectable Objects and Trigger Areas)
  • Achievements
  • Notifications
  • Dialogues
  • NPCs
  • Vendors
  • Interaction System
  • Enemies
  • Respawn Points
  • Targeting System (Third Person exclusive)
  • Player Hero AI (Top-Down exclusive)
  • Extensive AI System (update 1.1)
  • Enhanced Enemy Spawner (update 1.1)
  • Duel System - 1v1 PvP (update 1.2)
  • Three base classes - warrior, hunter, mage (update 1.2)
  • Professions and Gathering (update 1.3)
  • Pets/Companions (update 1.4)

Changelog

UPDATE 1.1

NEW EXTENSIVE AI SYSTEM

New AI system to create various behaviors for enemies and NPCs. This system replaced old "Primitive enemy AI".

Main features:
  • Several behaviors: follow, patrol, roam, interact, fight.
  • Melee or ranged combat (or both adjustable by distance to target)
  • Ally supporting
  • Hostile and friendly characters
  • Weapon equipping, unequipping and switching depending on combat mode
  • Aggressive, passive and neutral behavior toward hostile character
  • Calling nearby allies when engaged in combat
  • User-friendly AI management with commands, actions and events system

ENHANCED ENEMY SPAWNER

New enemy spawner gives more control over it where enemies spawn. It automatically generates spawn points in a certain radius and then lets the user manually adjust or delete existing points or add new ones. New spawner also supports random, weight-based enemies spawning so certain enemies can spawn rarely (previously all enemies had the same chance to be spawned). It also activates and deactivates depending on a number of heroes in its range.

UNIFIED BLUEPRINT INTERFACES

  • BPI_RPG_Interaction (used only by hero blueprints) interface has been replaced with BPI_RPG_Interactable. The new unified interface is used by player heroes, enemies, and NPCs.
  • BPI_RPG_Combat interface has been slightly improved and is also now used by player heroes, enemies, and NPCs.

REMOVED FUNCTIONALITY

  • ThreatManager component has been removed and threat functionality is now handled in the new AI system.

UPDATE 1.2

DUEL SYSTEM
Duel system let two players fight each other till death (or till duel time runs off).
  • 1v1 PvP, with the possibility to be turned into global PvP (so ALL players can damage and kill each other all the time)
  • Send and receive duel invitations
  • Accept or reject duel (with the auto-reject feature if a challenged player doesn't answer)
  • Limited space to fight (duel area).

NEW CLASSES EXAMPLES

  • Mage - has its own skill tree, uses AoE skills, and homing projectiles.
  • Hunter - has its own skill tree, uses arrow projectiles and buff that enhances arrows.

Both simple demo and advanced demo (downloaded separately) have all the example skills and basic attack set up. Since advanced demo also contains third-person mode everything has been set for that mode as well. Additionally, the advanced demo has fancy Paragon VFX.

REFACTORED TOP-DOWN MODE

Whole BP_RPG_PC_InGame_TopDown has been redone so its controls are more intuitive, especially attacking. Now you can click on the enemy, hold the button and hero will continue attacking the enemy (even if you move the mouse!). Hero AI also required improvements, so a couple of them were implemented to BP_RPG_AI_Hero_TopDown.

HERO BLUEPRINT IMPROVEMENTS

A few small improvements were added to BP_RPG_Hero:
  • Tracking "In-Combat" State - allows tracking whether a hero is in combat or not. The In-Combat state will be activated when the hero receives or deals damage.
  • AutoAttackRange variable - (used mainly by top-down mode), determine a range of basic attack or skill. In the simple demo autoattack range gets updated every time you equip different weapons.

UPDATE 1.3

PROFESSIONS AND GATHERING SYSTEM

Players can pick up various resources located all around the world.
  • Professions Manager actor component handles professions leveling
  • Configurable resource actor (adjust requirements, loot, respawn time, etc.)
  • Resources can be gathered by multiple players at once
  • Gathered resources go straight to player inventory or lands on the ground if there is no space in the inventory

UPDATE 1.4

PETS/COMPANIONS SYSTEM

  • Pets Manager actor component handles acquiring and releasing pets, it also tracks their level and experience
  • Pets can be summoned to assist a hero in battle (one pet at the time)
  • Pets use the AI system implemented in update 1.1, which makes it possible to implement basic attacks, skills, and supportive abilities to them
  • Pets stats are based on stats manager, so they can have various stats just like heroes or enemies

IMPROVED TOP-DOWN CAMERA CONTROLS

Smooth camera zooming and rotation have been implemented in top-down mode.

MAIN MENU EQUIPMENT

Heroes starting equipment will be visible right away when a character was created and even during the creation process (previously it was only visible after the player at least once entered the world with the character).

Roadmap

UPDATE 1.1 (implemented)
  • extensive AI system
  • enhanced enemy spawner
  • unified combat and interaction functionality
Note: Here you can find a small guide on how to implement the update to existing projects: LINK

UPDATE 1.2 (implemented)
  • hero ranged class
  • hero magic class
  • projectile system to support both ranged and magic classes
  • more demo skills (to present  ranged and magic classes)
  • duel system - 1v1 PvP (changeable to global PvP if needed)
  • refactored top-down player controller and AI (more intuitive controls)
Note: Here you can find a small guide on how to implement the update to existing projects: LINK

UPDATE 1.3 (implemented)
  • gathering system
  • professions system
  • enhanced crafting to suit professions

UPDATE 1.4 (implemented)
  • pets/companions system
  • improved camera controls for top-down mode
  • improved equipment displaying during the character creation process

Other planned features*:
  • world events
  • navigation and points of interest
  • enhanced quests collectables system
  • in-game chat
  • advanced dialogues with multichoice
  • voiceover for dialogues
  • enhanced item loot formula (quality, amount, etc.)
  • enhanced vendor items formula (quality, amount, probability, etc.)
  • random loot generation for chests
  • improved multiplayer possibilities (built-in sessions and/or advanced sessions)

*These features are just rough ideas and may or may not be implemented to the Kit. I reckon they will eventually make it but the order of appearing strongly depends on the community needs.


Demo

There is a simple demo that presents how everything works together. This demo works in top-down mode. There are available two advanced demos for both top-down and third-person modes. More info about the advanced demo at the end of this section.
To properly play the demo in editor start in Map_Demo_MainMenu level and create or select your character. Then proceed to a single player game. Once you do it you will be able to start directly in a game level. The last selected hero will be always be loaded when the game starts (optionally you can skip hero load, more info Player Controller section).

BASIC BLUEPRINTS

There are a few blueprints that extend the main blueprints functionality:
  • BP_Demo_GM_InGame – custom game mode blueprint that inherits from BP_RPG_GM_InGame. It doesn’t contain any changes besides the default player controller class.
  • BP_Demo_GM_MainMenu – custom main menu game mode blueprint that inherits from BP_RPG_GM_MainMenu. It also doesn’t contain any changes besides the default player controller class.
  • BP_Demo_PC_InGame – controller that inherits from BP_RPG_PC_InGame_TopDown. It doesn’t contain any custom logic only a few configured variables.
  • BP_Demo_PC_MainMenu – inherits from BP_RPG_PC_MainMenu_TopDown, also contains only a few configured variables (available heroes, starting map, spawn point, etc.)
  • BP_Demo_Hero – inherits from BP_RPG_Hero_TopDown. Base blueprint for all demo hero blueprints. Demo Hero has extended Death, Resurrection and Spawn events, so proper animation can be played when either of these happens.
    Additionally, this blueprint implements example functionality of how equipped items can be actually attached to heroes (OnEquipmentMeshChanged) and how to play different animations when weapon changes (Most of the setup is in animation blueprint).


ENEMY BLUEPRINTS

There are 3 custom enemies that inherit from the main BP_RPG_Enemy blueprint. Each of them contains simple attack logic, death, and hit events.


HERO BLUEPRINTS

There are 3 heroes that inherit from the demo hero blueprint (BP_Demo_Hero). Although, only one game-ready (warrior). Warrior contains combat logic that handles basic attacks and 3 skills. He also can use items. Use this blueprint whenever you need to check how certain things can be implemented. Warrior attacks, skills, and items utilize animation montage notifies.


NPC BLUEPRINTS

There are several NPC that inherit from BP_RPG_NPC. Basically, they don’t do anything specific, simply are placed in level and play an animation. Players can interact with them to buy stuff or get quests.


QUEST COLLECTABLE BLUEPRINTS

There are 4 quest collectables that inherit from BP_RPG_QuestCollectable. Besides custom meshes, they just increase the progress of different quest objectives.


OTHER BLUEPRINTS

BP_Demo_HeroRespawn – inherits from BP_RPG_HeroRespawa n. It has a different color than the original respawn blueprint and text added on top of it.
BP_Demo_StorageChest – inherits from BP_RPG_Stash. As above, the only thing that differs from the original blueprint is mesh added to make chest visible in the game.



ADVANCED DEMO

The advanced demo uses characters from Paragon and objects from Infinity Blade. Due to the size of these assets, Advanced Demo has to be downloaded separately and manually pasted to the project’s content folder. You can download it here: LINK
Close the project, unpack it and paste AdvancedDemo directly to the project’s content folder. The engine will need to compile all shaders and this will take A LOT of time. Depending on your computer specs it may even take an hour or two. Also, when you open the project it will start compiling shaders before the project properly loads so it may look like it is stuck.
The advanced demo offers fully working the third-person and top-down demos. They use the same map so whenever you want to switch between these two just change game modes to either third-person or top-down. You have to do it for the in-game level (Map_WorldA_Advanced) and the main menu level (Map_MainMenu_Advanced).

Player Controller (In Game)

Player Controller (BP_RPG_PC_InGame) is the main player blueprint that contains and handles most of the player functionality. It has all of the systems: stats, items, crafting, quests, achievements, skills, options, notification and save. Of course, all these systems are spread between various components.

The Player Controller blueprint has two children blueprints: BP_RPG_PC_InGame_TopDown and BP_RPG_PC_InGame_ThirdPerson. These player controllers contain functionality which is unique to their corresponding game modes.


PLAYER INITIALIZATION GRAPH

  1. Initialization starts with loading up a selected hero from General save the file. That means if you haven’t selected a hero through the main menu previously it won’t be able to load up and proceed to the next step. The game won’t be playable. During development, starting the game through the main menu can be tedious. So to test different levels without the necessity of loading a hero you can check SkipHeroLoad variable. When it is checked in, the game won’t attempt to load selected hero and spawn test one. Of course, the test hero needs to be defined as well, but it is just a matter of entering a hero ID in TestHeroID variable. This way you can test all characters on different maps.
    Both mentioned variables are in Player Controller variables (Development category).
  2. The game spawns proper character blueprint according to the selected hero class. If the hero is spawned on the same map where he finished playing the game will put him at the last activated respawn point or default one (usually invisible) if a player didn’t manage to activate any respawn points. However, if the hero is spawned on a different map (yes, it is possible if you join another player game), the game will put him at last known global respawn point. Global respawn is simply the last point activated by any of the players. Thanks to this player that joins the game will usually spawn relatively close to other players (at least in theory). 
  3. The game will create player HUD and assign references to all game components and load player options.  It’s the part that determines what widgets are updated by each component. If you have more widgets that should be created when a map loads up, you can do it there. You can also assign created widgets to components so they will have the possibility to reflect changes that happen in components (ie. display stats, gold, quests, etc.). You can find more info about what widgets should be assigned to what components in individual components sections.
  4. All player components (stats, items, quests, etc.) get initialized. So they are filled with default data.
  5. Player data is loaded at this point, default values are replaced (or adjusted) with the ones from the hero file. Player data won’t be loaded if we decided to check SkipHeroLoad variable.
  6. This will call the post-load event. Mainly to update changes that may happen to the world after hero data is loaded. Currently, it just reset hero collision so it can reset all overlaps (it is needed to update quest indicators displayed over NPC heads).

The whole initialization process works for both single and multiplayer games. In multiplayer games, it will take a while before events bounce a few times between server and client. This is covered with a fake loading screen.
RPG Kit allows to play alone and at any point join other player game. To achieve this save files are stored on the client (player) computer. When a player joins a multiplayer game, his save file will be uploaded to the server during the load phase. During the multiplayer game, everything happens on the server, so players can’t cheat (besides the host of course). However, players can cheat in single player games (as always) and then join a multiplayer game. There is no way around it unless you use dedicated servers.

If you plan to use dedicated servers, whole save functionality can be easily moved to server-side only – simply remove replication from LoadPlayerData_CLIENT and SavePlayerData_CLIENT events (or use SaveHero and LoadHero functions directly from Saves Manager). Both are initiated by the server thus they will happen on the server-side when replication is off. Remember that to make the game work with dedicated servers it will need more than just changing two events. Authorization needs to go through proper login server, players data needs to be stored, loaded and saved on external servers and so on.


NON BINDABLE CONTROLS GRAPH

Most of the controls can be remapped, however, there are few that are not bindable. These are universal ones but if needed, they could be easily added to the pool of rebindable controls as well.
  • Right Mouse Button is used to cancel all active dragging operations (skill or item dragging).
  • Mouse Wheel Up and Down are used to zoom in and out skill tree widgets.
  • Left Shift activates items stack splitting. When the left shift is held and the player clicks with the left mouse button on the item stack-splitting window will pop up.
  • Left Ctrl activates so-called Quick Actions. When left ctrl is held and the player clicks with left mouse button it will instantly move items between containers, sell or buy an item, equip or unequip the item.


USER INTERFACE CONTROLS GRAPH

There you will find all events related to toggling player windows (quest log, inventory, etc.).


QUICK SLOTS CONTROLS GRAPH

There you will find all events related to activating Quick Access Bar objects.


ITEMS MANAGEMENT GRAPH

This graph contains a few events that react to Items Manager behavior:
  • Shows or hides Stash window when storage is accessed or left.
  • Shows or hides the Vendor window when a vendor is accessed or left.
  • OnItemUsed connects Items Manager and player hero, so whenever an item is used hero can properly react to it (usually play “use item” animation).


INTERACTION MANAGEMENT GRAPH

This graph contains only two events that react to the dialogue system, they either show or hide the dialogue window.


SKILLS MANAGEMENT GRAPH

There is only one event that passes info about the used skill to hero blueprint, so hero properly react to it (play an animation, spawn particles effect, etc.)


DAMAGE HANDLING GRAPH

You will find 3 events there:
  • OnDamageReceived – executes whenever a player hero takes damage. It simply passes data to Floating Text Manager so it can spawn damage pop up.
  • OnKilled – executes when the player hero reaches 0 health points. It triggers a player death logic sequence.
  • Respawn – executes when a player hero is restored to the game. It triggers respawn sequence: health is replenished, the hero is moved to respawn point, etc.


GAME LEAVING GRAPH

Contains 2 simple events:
  • ReturnToMainMenu – performs additional save operation and opens the main menu map.
  • QuitToDesktop – performs additional save operation and closes the game.


Third-Person Controller


Third-Person Controller (BP_RPG_PC_InGame_ThirdPerson) is the extension of Player Controller blueprint. it contains a few changes and improvements implemented to handle third-person mode better. Additionally, it has a unique targeting system implemented.


PLAYER INITIALIZATION GRAPH

Part 3 of player initialization is expanded by two event bindings. Bound events react to UI toggling. More in Interaction Management below.


CHARACTER CONTROLS GRAPH

There are all inputs that control a player hero in third person mode: movement, attack, interaction, and targeting. All inputs (besides interaction) are locked when UI is open.


INTERACTION MANAGEMENT GRAPH

This graph is further expanded from the original Player Controller blueprint.
InteractWithActor_SERVER – asks the server to trace for interactable actor and if one is found – interact with it. TraceForInteractableActor can be adjusted to your needs.
This is worth mentioning that the “Interaction” trace channel has been added especially for interaction. Use it for objects that are meant to be interactable with a player.
OnDialogueStarted/OnDialogueEnded are basically the ones from the original Player Controller, the only additional thing is that they Toggle UI Mode (which is unique for third-person mode).
EnableUI/DisableUI – sets proper input mode and mouse visibility.


TARGETING MANAGEMENT GRAPH

The targeting system has been created especially for the third-person mode to enhance combat. Targeting can be toggled using ToggleTargeting_SERVER event. By default tied to TAB key.
While targeting is active, player hero and camera will automatically rotate to face the locked-on target. You can swap between nearby targets using NextTarget_SERVER (by default E key) and PreviousTarget_SERVER (by default Q key).
When the locked-on target dies, the system will automatically swap to the best target in radius or deactivate targeting when no proper targets were found.
Under the variables section you will find to configurable values:
  • TargetingRadius – determines how far from player hero potential targets can be. Actors beyond this value won’t be considered as targetable.
  • TargetingAngleRange – determines how much to the left or right potential targets can be. Basically, considering targets only is a specific cone.


Top-Down Controller

Top-Down Controller (BP_RPG_PC_InGame_TopDown) is the extension of the Player Controller blueprint. it contains a few changes and improvements implemented to handle top-down mode better. In top-down mode, a player doesn't possess his hero, AI does. That's why additional blueprint has been made (BP_RPG_AI_Hero_TopDown) which mainly handles hero movement and commands (attack, interact, etc.)


CHARACTER CONTROLS GRAPH

In top-down mode, most of the actions are performed using mouse clicks. If the left mouse button is held system will automatically send clicks in a given frequency. This can be adjusted by changing the value of HitResultUpdateFrequency in controller variables.
Keep in mind that in multiplayer games each time click happens it is will be sent from client to server. To reduce bandwidth usage keep it relatively high (by default it is 0,2s but anything above 0 should be fine).


QUICK SLOTS CONTROLS GRAPH

Quick slots functionality is slightly enhanced in top-down mode. Whenever an object in quick slots is used it searches for a target under the cursor, so the object can be used on it (ie. skill or potion). If no target was found certain objects still can be used, like skills that can be cast directly on the ground.

In addition to Top-Down Player Controller, there is also Hero AI blueprint (BP_RPG_AI_Hero_TopDown) which mainly handles hero movement and commands (attack, interact, etc.).

Main Menu Controller


Main Menu Controller (BP_RPG_PC_MainMenu) is responsible for creating and selecting a hero. It also allows you to host or join a game.
Currently, you can join other player game by entering his computer IP. In the future, it will be possible to join games by browsing all available online sessions.
Important Note: Main Menu level plays locally on a player computer, there is no multiplayer involved at this stage. That’s why in editor it should be played with multiplayer options turned off (set Number of Players to 1 and tick off Run Dedicated Server).

Main Menu Controller requires a few variables to be configured:
  • AvailableHeroes – stores IDs of all available heroes that player can see during hero creation. IDs must match chosen rows in DT_RPG_Heroes data table.
  • LockedHeroes – stores IDs of all available heroes that player can’t use during hero creation. He will still see them but won’t be able to use them.
  • DefaultMap – the name of the default (starting) map. Newly created heroes will start there.
  • DefaultSpawnPoint - ID of specific Spawn Point in default map. Used to specify where exactly the hero will spawn.

There are two children blueprints: BP_RPG_PC_MainMenu_ThirdPerson and BP_RPG_PC_MainMenu_TopDown.
Again, they were created to keep consistency but they have few different values in configurable variables. Mainly because third-person and top-down modes use different hero blueprints.

Video below shows how to set up new map from the scratch.

Player Hero

Player Hero (BP_RPG_Hero) is the second most important player blueprint because it is a character that player controls in the game. It contains only three gameplay components: inventory container, stash container, and equipment. While these components could easily be added to Player Controller, they seem to fit Player Hero blueprint better. The main reason is that the Player Controller has all “managers”, while these components are only “containers” that Items Manager operates on.

Why does Player Hero contain a stash container?
It acts like personal storage, there is a special blueprint (BP_RPG_Stash), which enables interaction with player storage. Since it is unique for each hero it sticks to that blueprint. It also makes it easier to get access to player storage on demand, ie. by using some kind of magic item or skill that grants immediate one-time access to storage.

Each hero requires a few variables to be configured:
  • HeroID – the name of the row from DT_RPG_Heroes data table which contains all data related to certain heroes.
  • SkillsDatatable – data table with a list of the skills related to certain heroes.
  • SkillsTreeWidget – determines what skill tree widget should be used in association with a certain hero (each hero has a unique skill tree widget).


COMBAT GRAPH

Most of these events are meant to be overridden by children hero blueprints because heroes act differently in various situations. More about overridden events in certain hero blueprints.


ANIMATION REPLICATION GRAPH

Used to play or stop animation montages on all clients.


DEATH GRAPH

Two events that are overridden or extended in children blueprints:
  • DeathEffect_MULTICAST – a special event that is executed during player death sequence (which starts in Player Controller). Usually extended in children hero blueprints with some unique functionality.
  • ResurrectionEffect_MULTICAST – a special event that is executed during player respawn sequence (which also starts in Player Controller). Usually extended in children hero blueprints with some unique functionality.


SPAWN GRAPH

It contains only MainMenuSpawnEffect which is meant to be overridden by children hero blueprints. Generally, it was made for and used only in Main Menu map.


Player Hero blueprints have two direct children blueprints: BP_RPG_Hero_ThirdPerson and BP_RPG_Hero_TopDown. These two blueprints don’t contain any logic and do not really expand parent functionality by themselves (only their children do it). However, they have been created to keep consistency and just in case if someone would like to implement logic common for all third-person or all top-down heroes.

To add a new playable hero to the game you need to create a blueprint that inherits from either BP_RPG_Hero_ThirdPerson or BP_RPG_Hero_TopDown. Now, go to DT_RPG_Heroes data table and add a new row with data for the created hero. Detailed info about each variable can be found below in the Data Tables section. Once you fulfill hero default data go back to its blueprint and in HeroID variable enter name of the row from Heroes data table. Then assign Skills data table and Skill Tree widget that the hero will use. To check how to make hero selectable in-game go to Main Menu Controller section.

Player Storage

Player Storage can be accessed through BP_RPG_Stash. It is a simple actor blueprint that only implements Interaction interface. To add new storage to the game (ie. different chests) just create a blueprint that inherits from BP_RPG_Stash and adjusts its InteractionBox component extents.

Pickable Item

Pickable (BP_RPG_Item) is an actor blueprint that contains item data. Thanks to this it can be picked up when the player interacts with it. The same blueprint is spawned when the player throws an item away from his inventory.
Item Data can be assigned manually to spawn a specific item (ItemData variable). However, it is also possible to spawn a random item (GenerateRandomItem variable). Item will be randomized on its BeginPlay event.

By default, all items use simple box mesh, but you can create as many children blueprints as you need to properly show an item in the world. Change mesh, add particle emitters, create a special indicator for item quality.

Player Respawn

Hero Respawn (BP_RPG_HeroRespawn) is an actor blueprint that provides “checkpoints” where a player can respawn at when he dies.
To add more unique respawn points (different meshes, particle emitter, etc.) to the game create actor blueprint that inherits from BP_RPG_HeroRespawn.
When you place Hero Respawn in the level you will need to edit two variables:
  • RespawnID – unique ID used to distinguish respawns across the whole level. All respawns (especially in the scope of one level) should have unique IDs.
  • InvisibileInGame – determines whether respawn should be visible to the player or not. Usually, players cannot interact with invisible respawn points.


Active Respawn Point is stored in SavesManager, which also handles Respawn Point activation.
Activate and Deactivate events can be used by children blueprints to implement new behavior for respawn activation/deactivation (ie. play particles when respawn is activated).

HUD (In-Game)

Most of the player widgets are spawned through BP_RPG_HUD, which is the default HUD blueprint used in both third person and top-down modes. It creates and stores references to player windows (stats, skills, inventory, etc.), dialogue window and pause menu. If you want to add more widgets to HUD it is probably the place where you want to do it.

Quest Area, Collectables and Spawner

QUEST AREA

Quest Area (BP_RPG_QuestArea) is a simple actor only with sphere collision. It is used to mark regions in the game that can progress certain quests objectives progress. (Ie. there is a quest that wants a player to investigate specific part of town, we can put Quest Area there and once it is triggered it will complete the objective).
Once you place Quest Area blueprint in the level, configure its two variables:
  • Radius – determines the size of the collision sphere.
  • QuestObjective – ID of the objective that should be progressed when a player triggers Quest Area.

Quest Area is invisible during the game so there is no need to create children blueprints to mark different areas. However, you can do it if you wish to indicate the area for players (ie. with a circle made of particles).


QUEST COLLECTABLE

Quest Collectable (BP_RPG_QuestCollectable) is a simple actor that can be interacted by a player to increase certain quests objectives progress. To add new Quest Collectable just create a new blueprint that inherits from BP_RPG_QuestCollectable. There are only 2 variables to configure:
  • DisplayName – a name that will be displayed to the player, when he is near the collectable.
  • QuestObjective – ID of the objective that should be progressed when Collectable is picked up.


QUEST COLLECTABLES SPAWNER

Collectables Spawner (BP_RPG_Spawner_Collectable) that handles quest collectables spawning during the game. It is a simple actor with sphere collision to indicate the spawn radius. Once you place it in the level you can configure several variables:
  • CollectableToSpawn – collectable blueprint that will be spawned.
  • MaxNumberOfCollectables – how many collectables can be spawned by this spawner. When the max number is reached spawner will be paused. It will resume once the number of collectables decreases.
  • SpawnRadius – how far from the center of the spawner collectables can spawn.
  • SpawnOnBeginPlay - determines whether spawner should be activated on BeginPlay and start spawning collectables or needs to be activated manually at some point. To activate it manually later just call SpawnCollectables function.
  • SpawnAllAtOnce - determines whether spawner should spawn collectables one by one in given time intervals until the maximum number is reached or should always spawn all missing collectables at the nearest opportunity.
  • MinRespawnTime - Minimum time interval between spawning attempts. (Final interval is random time between Min and Max Respawn Times).
  • MaxRespawnTime - Maximum time interval between spawning attempts. (Final interval is random time between Min and Max Respawn Times).

NPC Character

NPC (BP_RPG_NPC) is a character blueprint meant to represent world characters. Currently, they can be used as vendors and quest targets.
To create new NPC create a new blueprint that will inherit from BP_RPG_NPC. Open it and in config variables section enter a unique ID and AI Configuration which consists of a data table and data table row of the AI initial configuration. Then in the DT_RPG_NPC data table create a row with the same ID. Set up all needed fields. Detailed info about each variable can be found below in the Data Tables section.


VENDOR

If vendor option was checked in it will generate random items when a player interacts with the NPC for the first time. Items are generated with GenerateVendorItems event. Items generation is pretty basic so you can expand it here to suit your needs.


INTERACTION

Interaction with a vendor is possible because it has BPI_Interaction interface implemented (more about it in the Blueprint Interfaces section).
There are two events that handle what happens when the player starts and finishes interacting with the NPC. Mainly it constructs the dialogue window and toggles its visibility. Additionally, as mentioned above, it will generate vendor items at this stage.


QUEST INDICATOR

There is an Indicator static mesh floating over the NPC. Whenever NPC has a quest that can be accepted, finished or progressed Indicator will adjust its mesh and color to reflect quest current state. There is also IndicatorUpdateRadius component attached to NPC, it determines the range in which the Indicator will react to quest changes. When a player was outside the range and enters into the Indicator radius it will immediately update its state to reflect quest current state.

Enemy Character and Spawner


ENEMY BLUEPRINT

BP_RPG_Enemy is the main enemy blueprint that contains common logic for all enemies. The enemy is initialized on begin play event. Right there it has stats recalculated to reflect its level.

DAMAGE HANDLING GRAPH
Works the same as for player. There are 3 events:
OnDamageReceived – executes whenever the enemy takes damage. It is overridden by enemy children blueprints so each of them can play unique “OnHit” animation, spawn different particle emitters, etc.
OnKilled – executes when the enemy reaches 0 health points. It triggers the enemy death logic sequence.
DeathEffect_MULTICAST – a special event that is executed when the enemy is killed. Used to play the death effect on all clients. Usually extended in children's enemy blueprints with some unique functionality.

AI GRAPH

It contains a few very simple events that support AI.

ANIMATION REPLICATION GRAPH

Used to play or stop animation montages on all clients.

EFFECTS GRAPH

Here are implemented all the effects that enemies can be affected with.

To add a new enemy to the game you need to create a blueprint that inherits from BP_RPG_Enemy. In the DT_RPG_Enemies data table you can create a new row and set up default data for the enemy. Detailed info about each variable can be found below in the Data Tables section. When default data for the enemy is ready, get back to your enemy blueprint. In Class Defaults you will need to set up a few things:
  • EnemyID – here you should enter the name of the row from the Enemies data table.
  • AIConfiguration - consists of a data table and data table row of the AI initial configuration.
  • RewardRadius – determines how far from killed enemy players can be to receive the reward (experience points, quest and achievements objectives, etc.).


ENEMY SPAWNER BLUEPRINT

Enemies are spawned in the world through a special spawner blueprint (BP_RPG_Spawner_Enemy). Once you place enemy spawner in the level there are few variables that need to be configured:
  • EnemiesToSpawn – list of enemies that will be spawned when spawner is triggered. To randomize the number of spawned enemies adjust MinSpawnAmount and MaxSpawnAmount values.
  • SpawnRadius – how far from the center of spawner enemies can spawn.
  • SpawnOnBeginPlay – should enemies spawn right on begin play? Otherwise, enemies will spawn when the spawner is triggered.
  • ActivationRadius – determines the radius in which spawner gets triggered by the player.
  • RequiredQuest – spawner will only be triggered when the player has this quest.
  • Level – determines the level of spawned enemies.  

IMPORTANT: BP_RPG_Spawner_Enemy is being replaced by the new BP_RPG_Spawner_Enemy_Advanced, in a future update, it will be marked as deprecated and eventually removed. It is still available in the Kit to facilitate the transition to the new spawner in existing projects.

New spawner (BP_RPG_Spawner_Enemy_Advanced) offers more controls over spawning points. It automatically activates and deactivates depending on the number of heroes in the activation radius. When there are no player heroes nearby, the spawner is basically irrelevant and it will attempt to remove enemies it has spawned. So they can be respawned when any of the players come back.
These are configurable variables:
  • SpawnRadius - determines how far from the center of spawner spawn points will be generated.
  • DistanceBetweenSpawningPoints - the bigger the distance is the fewer spawn points will be generated
  • SpawnPoints - all spawn points generated for the spawner. You can manually add, remove or adjust spawn points so you have full control where enemies can be spawned. Firstly, you can also call GenerateSpawnPoints events from the editor and then adjust the existing points.
  • GuaranteedEnemies - enemies that spawned will spawn for sure.
  • BonusEnemies - enemies that the spawner will choose randomly from when random enemies are generated. Each assigned enemy class has a corresponding weight. So you can control how often certain enemies can spawn. IE. If one Enemy A has a weight equal to 1.0 and Enemy B has a weight equal to 2.0 then it means that Enemy B will spawn roughly 66,66% of the time.
  • Level - level of spawned enemies.
  • MinBonusEnemies - the minimum number of additional random enemies.
  • MaxBonusEnemies - the maximum number of additional random enemies.
  • ActivationRadius - spawner will spawn enemies when one of the players enters the activation radius. Enemies will be despawned (deleted) when all players leave the activation radius.
  • ShowSpawnRadius - editor only, shows spawn radius sphere component, doesn't affect gameplay, the component is deleted on begin play, used purely for clarity reasons
  • ShowActivationRadius - editor only, shows activation radius sphere component, doesn't affect gameplay, the component is deleted on begin play, used purely for clarity reasons

Save Blueprints

General Save (BP_RPG_SAVE_General) – acts as some sort of container for hero saves. It stores an array of all created hero saves and last played hero save. It is used in the main menu and in-game during hero initialization, save and load.


Options Save (BP_RPG_SAVE_Options) – stores all player options. Settings are used globally, it means that they will be the same for all heroes, thus you can change them in the main menu and in the game. Whenever options are changed they will be automatically saved to the file.


Hero Save (BP_RPG_SAVE_Hero) – created for each hero, stores all hero data: stats, skills, items, quests, achievements, crafting, quick access, buffs, respawn point and map. Add there anything that should be saved per hero.
Hero data can be saved/loaded through Player Controller (BP_RPG_PC_InGame) using: SavePlayerData_CLIENT and LoadPlayerData_CLIENT functions. Additionally, hero data is loaded automatically during the initialization phase and saved when the player quits the game, goes back to the main menu or transit between maps.
More info about hero save and load can be found below in section dedicated to Saves Manager.

Duel Blueprints

Duel Manager (AC_RPG_DuelManager) is responsible for communication between client and server (eg. send and receive duel invitations).  There is one variable that can be adjusted:
  • DuelInvitationCooldown - determines the delay that occurs when a player rejects a duel invitation (so other players cannot spam duel pop up all the time).

Duel blueprint (BP_RPG_Duel) is the blueprint that maintains the duel action (tracks player health, checks if they are within the duel area, etc.). There are a couple of variables to configure:
  • AutoRejectTime - how long it takes to automatically reject the duel by a challenged player (ie. when he doesn't reject or accept duel invitation manually). It also determines how much time the player has to decide whether he wants to participate in a duel or not.
  • CountdownTime - how much time players have to get to the indicated duel area when duel invitation gets accepted.
  • DuelDuration - how long duel lasts. If neither of the players dies and duel time elapses, the duel will end in a draw.
  • DuelRadius - determines the size of the duel area. Leaving this area during the duel will result in loss.
  • DistanceCheckFrequency - how often game checks if any of the players left the duel area.

IMPORTANT: To send duel invitation to another player you have to:
  • THIRD-PERSON MODE - come close to another player, point the camera at him, and press X.
  • TOP-DOWN MODE - hover the cursor over another player and press X.
This is a temporary solution and will be swapped with a new player to player interaction system that will come in the nearest update.


Stats Manager

Stats Manager (AC_RPG_StatsManager) handles functionality related to character, such as attributes, stats, damage, level, experience points, buffs and effects over time.

Stats Manager comes from standalone product. More information and in-depth guide can be read on its dedicated site(HERE).


ATTRIBUTES

Attributes are special character properties that basically don’t do anything on themselves. Each attribute affects character stats and these have an effect on actual gameplay (ie. Strength increases damage, Endurance increases health and defense, etc.). They are used to give the player some control over his character growth. Attributes are used only in collaboration with player characters.
By default, there are four attributes: Strength, Dexterity, Endurance, and Wisdom. They can be edited in E_RPG_AttributeType enumeration.
Default attribute values and stat bonuses which are granted by attributes can be edited directly in DT_RPG_Heroes data table (more about it in data tables section).

There are several functions to manage attributes:
  • ReceiveAttributePoints – adds attribute points to the pool of available attribute points.
  • SpendAttributePoint – spends one available attribute point to increase the value of an attribute. It will also automatically recalculate attribute final value and affected stats values.
  • ResetAttributePoints – restores all spent attribute points and sets all attributes values to default ones. It will also automatically recalculate all attributes and stats values.
  • GetAttributeValue – returns final value of a given attribute.

Attributes can be also modified by external sources like buffs or items. RPG Kit already provides attributes merged with buffs and items. However, if you ever need to modify attribute value you can use following functions:
  • AddAttributeFlatBonus – adds flat ba onus to attribute total value. Value can be either positive or negative.
  • AddAttributePercentageBonus – adds given percentage bonus to attribute total value. Value can be either positive or negative.
  • RemoveAttributeFlatBonus – removes given flat bonus from attribute total value. Won’t do anything if there is no such bonus.
  • RemoveAttributePercentageBonus – removes given percentage bonus from attribute total value. Won’t do anything if there is no such bonus.
Keep in mind that after adding or removing the bonus, attribute final value won’t be recalculated automatically. You will have to do it manually by calling either RecalculateAttributeFinalValue (if you can easily specify what attribute was changed) or RecalculateAllAttributesFinalValues (if you cannot specify what attribute was changed or there were many attributes affected).


STATS

Stats are the most basic character properties that are used in various gameplay elements, ie. Health determines how much damage character can take and Critical Rate determines the probability of dealing powerful hit. Primarily, they are used in player character and enemies blueprints but could be used with any actor (of course only if an actor needs such complex stats system).
Some of the stats also have so-called “current” value which reflects the state of a certain stat. This is commonly used with stats such as health or mana. Stat final value determines a pool of health while stat current value reflects how much of it left (so a character can die when it reaches zero).
Default stats are Health, Mana, Power, Movement Speed, Critical Rate, Critical Power, Defense, and Attack Range. Of course, you can edit them or add new ones in E_RPG_StatType enumeration.
Same as attributes, default stat values are set in DT_RPG_Heroes data table (for player characters) and in DT_RPG_Enemies data table (for enemies).

Stats management functions:
  • GetStatValue – returns stat final and current values (current value will equal zero if stat doesn’t use it).
  • SetStatCurrentValueToMax – sets current value of chosen stat to its max (final) value.
  • SetNewStatCurrentValue – sets current value of chosen stat to specific value (the system will automatically clamp it between 0 and its final value).
  • ModifyStatCurrentValue – adds (or deducts in case it is negative) specific value to current value (the system will automatically clamp it between 0 and its final value).
Stats can be modified by external sources in exactly the same way attributes are. Also, RPG Kit already provides stats merged with buffs and items. Stats can be modified further using the following functions:
  • AddStatFlatBonus – adds a flat bonus to stat total value. Value can be either positive or negative.
  • AddStatPercentageBonus – adds given percentage bonus to stat total value. Value can be either positive or negative.
  • RemoveStatFlatBonus – removes given flat bonus from stat total value. Won’t do anything if there is no such bonus.
  • RemoveStatPercentageBonus – removes a percentage bonus from stat total value. Won’t do anything if there is no such bonus.
Keep in mind that after adding or removing the bonus, stat final value won’t be recalculated automatically. You will have to do it by calling either RecalculateBaseStatFinalValue (if you can easily specify what stat was changed) or RecalculateAllBaseStatsFinalValues (if you cannot specify what stat was changed or there were many stats affected).


LEVEL AND XP

Stats Manager provides simple level system. It can define both player characters and enemies levels, adjusting attributes and stats values to match actors levels. It also offers experience points functionality which can be used for player characters so they can level up, get stronger and receive various rewards.
The most important function is:
  • ReceiveExperience – adds the number of experience points to the current amount of experience points. When the required number of experience points is reached it will increase the player level and reset experience points to zero (plus surplus that left after level up).
There are also other functions like LevelUp or ReceiveLevelUpReward but they are called internally in ReceiveExperience function when XP threshold is reached.


BUFFS

Buffs provide temporary bonuses to attributes and stats. They can be applied on a trigger when items are used or equipped when skills are cast etc. Buffs can be customized, you can determine its influence type, stacks number, removal behavior and bonuses (including negative).

Each buff has its equivalent in E_RPG_BuffType enumeration, whenever you want to edit or add new buff start there. To set up buff default data head to DT_RPG_Buffs data table.

A lot of buffs functionality happens behind the scene, like buffs power comparison, time management or adding/removing bonuses. Although, there are few functions that help to manage it:
  • ApplyBuff – applies buff of the given type. Additionally, you need to specify the number of stacks applied, whether it is permanent or has the certain duration and as well its bonuses.
  • RemoveBuffByType – removes buff of the given type. You can force to remove all buffs stacks (even if by default stacks are removed one by one). You can also check to remove buff if it is irremovable by default.
  • RemoveRandomBuff – removes random buff of given influence type. Leaving influence type in NotDefined state will remove one random buff of ANY influence type.

To modify buffs time use:
  • SetNewBuffTime - changes the remaining time of chosen buff to the given value.
  • ModifyBuffTime – increases or decreases the duration of chosen buff by given value.

Important note: to keep everything unified, buffs makes use of items bonuses. Check Items Manager component section for more info.


EFFECTS

Effects provide temporary events that affect the character, such as health regeneration, burn, poisoning, different kind of auras, etc. Same as buffs they can be applied on the trigger when items are used or equipped when skills are cast etc. They can also be customized, you can determine its influence type, stacks number, removal behavior.
Buffs grants bonuses to stats and attributes, effects in contrary can be used in a way broader range hence each effect has to be set up manually.
Effects management functions:
  • ApplyEffect – applies the effect of the given type. You need to specify the number of applied stacks, power, number of ticks and tick frequency (if you check Permanent option you only need to adjust tick frequency).
  • RemoveEffectByType – removes effect of given type. You can choose to remove it even if it is irremovable by default.
  • RemoveRandomEffect - removes the random effect of given influence type. Leaving influence type in NotDefined state will remove one random effect of ANY influence type.

To modify effects remaining ticks use:
  • SetNewEffectTicks – changes the number of remaining ticks of chosen effect to given number.
  • ModifyEffectTicks – increases or decreases the number of ticks of chosen effect by given number.

Buff and effects are displayed in the same widget container. You can specify that container by calling SetBuffsAndEffectsContainer with container panel widget pinned in.


DAMAGE

Stats manager uses a special function to apply damage to a character, it is:
  • ReceiveDamage – applies damage to character considering damage dealer’s critical rate and critical power and own defense stat.
When damage is received system will also automatically spawn widget pop up with damage displayed.

Items Manager

Items Manager (AC_RPG_ItemsManager) handles functionality related to items, such as inventory, equipment, storages, and vendors.
There are 3 other components that are associated with Items Manager:
  • Container (AC_RPG_Container)
  • Equipment (AC_RPG_Equipment)
  • Crafting Manager (AC_RPG_CraftingManager)

Items Manager, Container, Equipment and Crafting components come from standalone product. More information and in-depth guide can be read on their dedicated site (HERE).


CONTAINERS

Regardless if it is character inventory, storage or vendor they all use the same AC_RPG_Container component. You can add it to any actor, set type and size and it is ready.

To add an item to container use:
  • AddItemToContainer(ByID) – generates random item with from data table using the provided ID and adds it to a container. You can determine the amount of item and its quality. Additionally, it will return the amount of item that didn’t fit into the container.
  • AddItemToContainer(ByStruct) -  adds previously generated item to container. In this case, you can only determine its amount. It also returns the amount that didn’t fit into the container.

To remove an item from container use:
  • RemoveItemFromContainer – removes from container certain amount of the desired item. If needed, the required amount will be removed from many stacks.
  • RemoveItemFromContainerAtIndex – removes from container certain amount of item at a specific slot.


EQUIPMENT

Equipment is a special container that stores equipped items. Items are equipped and unequipped by drag&drop operations so there is no functions need to be called for it to happen.

However, if you wish to equip/unequip items from external sources (ie. on the trigger) you can use:
  • QuickEquipItem – this requires an inventory slot to be passed, so the system can find the item that should be equipped in the inventory container. Found item will be automatically moved from inventory to equipment.
  • QuickUnequipItem – this requires equipment slot to be passed, so the system can find the item that should be unequipped in the equipment container. Found item will be automatically moved from equipment to inventory.
Equipping operations automatically recalculates item bonuses granted to the character.


CRAFTING

AC_RPG_CraftingManager
Crafting Manager is the addition to Items Manager that handles items crafting. It uses items from player inventory container and crafted items are added there as well.

To craft item call:
  • CraftItem_SERVER – it will attempt to craft the desired item. However, item will be crafted successfully when craftable is unlocked, a player has enough space in inventory and has all required materials.
Craftables that are not unlocked by default can be unlocked on-demand using UnlockCraftable function.


GOLD

Gold is stored in Container components. To modify the amount of gold in container simply call ModifyGoldAmount function.
The proper gold amount is displayed in widgets by using BPI_RPG_CurrencyUpdater. If you wish to display the gold amount in the widget just add that blueprint interface to a widget, compile and call this function:
  • UpdateGoldAmount - provides the gold amount.


QUICK ACTIONS

Item operations, such as moving between containers, equipping, unequipping, buying or selling happen on drag and drop. However, for user convenience, there are also implement so-called Quick Actions. These actions are active when the Left Ctrl button is held or on LMB double click (Left Ctrl button binding can be changed in BP_RPG_PC_InGame blueprint, in NonbindableControls graph).

In addition to Quick Actions, there is also Stack Splitting action, which let players split a certain stack of the item into two. Stack splitting activates when Left Shift is held and an item is clicked with LMB (Left Shift button binding can be changed in BP_RPG_PC_InGame blueprint, in NonbindableControls graph).


GENERAL ITEM ACTION

There are several actions that let the player interact between inventory and game world:
  • PickUpItem_SERVER – attempts to add to inventory given item.
  • ThrowOutDraggedItem_SERVER – attempts to spawn dragged item on the ground near the player.
  • UseItemFromInventorySlot_SERVER – attempts to use an item that is in a given inventory slot.
  • UseItem_SERVER – attempts to use item with a given ID, also from inventory.

Each item can have a unique usage effect. It can be set up in Items Manager’s ItemsEffects Graph. You will also find a few examples there.


ITEM QUALITY

Depending on type items can have different quality. By default, there are 4 qualities available: Common, Rare, Epic, and Legendary. You can add new or edit existing ones in E_RPG_ItemQuality enumeration.
You can roll random item quality using RollItemQuality function, which can be accessed globally (more info below in Items Function Library section).


ITEM BONUSES

Items can apply various stat and attribute bonuses. You can add new or edit existing bonuses in E_RPG_BonusType enumeration. However, to set up what each bonus actually does or what it increases you need to head to FL_RPG_Items function library and edit both ApplyBonuses and RemoveBonuses functions (more info below in Items Function Library section).
Each item belongs to specific bonuses group (determined in DT_RPG_Items data table). Each group contains an only specific pool of bonuses, so you can easily set up a number of possible bonuses for a large number of items, ie. swords, armors, helmets, etc. If an item requires unique bonuses simply create unique bonuses group for it.
Item bonuses can be rolled using RollItemBonuses function, which can be accessed globally (more info in Items Function Library section).

Quests Manager

Quest Manager (AC_RPG_QuestsManager) stores and handles all quests acquired by the player. There is also Quest Indicator component (AC_RPG_QuestIndicator) that is associated with Quest Manager. Is responsible for displaying proper information to the player whether quest can be accepted, progressed or finished at NPC.

Quests Manager and Quest Indicator come from standalone product. More information and in-depth guide can be read on its dedicated site(HERE).

Quests management functions:
  • AcceptQuest – attempts to accept desired quest. All requirements have to be met.
  • AddQuestObjectiveProgress – modifies the progress of given objective in all quests that have this objective.
  • FinishQuest – attempts to finish the desired quest. All objectives have to be completed.
  • UnlockQuest – Unlocks desired quest so it becomes available to the player. Generally, this function is used when quest doesn’t have any requirements but we want it to be available to the player in specific circumstances (ie. when items are used).
  • AbortQuest – attempts to remove desired quest.
  • FailQuest – attempts to set quest to failed state.
  • ResetQuestProgress – set the progress of all objectives of the given quest to zero.
  • RestoreQuest – removes quest from the pool of finished quests, which makes it available once again.

Achievements Manager

Achievements Manager (AC_RPG_AchievementsManager) handles and stores all available achievements. Achievements are simple and have only one objective but they have multiple tiers.

Achievements Manager comes from standalone product. More information about it and in-depth guide can be read on its dedicated site (HERE).

Achievements management functions:
  • AddAchievementsProgress – increases the progress of given achievement.
  • FinishAchievement – finishes achievement and grants player a reward.

Skills Manager

Skills Manager (AC_RPG_SkillsManager)handles functionality related to skills such as unlocking, skill points or cooldowns.

Skills Manager comes from standalone product. More information and in-depth guide can be read on its dedicated site (HERE).

Skills management functions:
  • UnlockSkill – unlocks a skill that hasn’t been unlocked by default. Used to grant a skill through external sources (ie. when a certain item is used or certain quest is finished).
  • ReceiveSkillPoints – adds skill points to the pool of available skill points.
  • ResetSkillTree - sets all skills levels to default values and returns all spent skill points to pool of available skill points.
  • UpgradeSkill - increases the skill level by 1.
  • DegradeSkill - decreases the skill level by 1.
  • ResetSkill - set the level of certain skill to its default value and restore all skill points spent on it.

There is also a function that allows modifying cooldown time:
  • ModifySkillCooldown – increases or decreases cooldown time of given skill.
You can also manually activate or deactivate cooldown using: ActivateSkillCooldown and DeactivateSkillCooldown functions.

Quick Access Manager

Quick Access Manager (AC_RPG_QuickAccessManager) is responsible for handling Hotbar activity. It enables skills and items to be registered and used with keyboard or mouse button click. Skills and items are registered when they are dragged over and dropped on Quick Access Slot. It is also possible to swap registered objects directly in Quick Access Bar.

If you wish you can also register skills and items manually using:
  • RegisterObjectInQuickSlot_SERVER - registers given object (skill or item) in chosen slot. Naturally, passive skills cannot be registered in Quick Access Bar because they cannot be used at all. Also, only registrable can be put in the Quick Access Bar.
Whenever skill is registered it will automatically update its remaining cooldown time. Same goes for total item quantity.

An object can be removed from the Quick Access Bar using:
  • UnregisterObjectFromQuickSlot_SERVER – removes registered object from chosen slot.


Originally, Quick Access management comes with both Items Manager and Skills Manager. However, that functionality was pruned from these blueprints and consolidated into separate Quick Access Manager. Although, these Managers still handle drag&drop operations on their own.

Saves Manager

Saves Manager (AC_RPG_SavesManager) is a little component that handles hero saving and loading. Most important functions are:
  • SaveHero – basically, gets data from all player components and assigns it to proper structures in hero save file. All components have unified functions that return data to save.
  • LoadHero – this one gets data from hero save file and assigns it to proper player components. Loaded data is not only written to components variables but there are also several additional actions executed in each component that loads data. Generally, it updates data displayed in player widgets, resets timers, etc. so everything matches the current state of the player. In a multiplayer game, data is read from hero save file and uploaded to the server first.

Additionally, Saves Manager stores hero respawn point data.

Floating Text Manager

Floating Text Manager (AC_RPG_FloatingTextManager) handles damage pop-ups. It is the only thing it does currently. However, it can be expanded by adding pop-ups for other things that may be displayed to the player, such as experience points.

Notifications Manager

Notifications Manager (AC_RPG_NotificationManager) handles notifications displayed on the screen (ie. when a quest is acquired or finished).

Notifications Manager comes from standalone product. More information and in-depth guide can be read on its dedicated site (HERE)

To display the notification on the screen use QueueNewNotification.

Options Manager

Options Manager (AC_RPG_OptionsManager) is responsible for managing and applying game options. It also handles keymappings.

Options Manager comes from standalone product. More information and in-depth guide can be read on its dedicated site (HERE).

Interaction Manager

Interaction Manager (AC_RPG_InteractionManager) is simple actor component that executes (or finishes) interaction between player and target actor using StartActorInteraction_SERVER and FinishActorInteraction_SERVER function. It also handles dialogue window construction and swapping between dialogue options.

More information about how to set up interaction can be found in the Blueprint Interfaces section (Interaction Interface).

Professions Manager

Professions Manager (AC_RPG_ProfessionsManager) is an actor component that manages gathering of special resources. You can add as many professions as you like. To do it create new entry in E_RPG_ProfessionType enumeration and add it to Professions Manager in player controller blueprint (BP_RPG_PC_InGame). Last thing to do is adding new slot to professions window widget (WBP_RPG_ProfessionsWindow).


Gatherables (BP_RPG_Gatherable) are special resources that can be gathered when player reaches required profession level. To add new gatherable actor to the game create a new blueprint that inherits from BP_RPG_Gatherable. There is a couple of thing to configure:
  • DisplayName - name that will be displayed to player (eg. during interaction in third-person mode)
  • RequiredProfession - what profession is required to gather this resource.
  • RequiredProfessionLevel - what level required profession should be.
  • MaxInteractingPlayers - how many players (at once) can interact with the actor.
  • GatheringAction - what type of action will be executed during gathering (used mainly for playing proper animation in hero blueprint)
  • GatheringTime - how long will it take to gather resources from the actor.
  • GatheringTicks - how many times players can gather resources from the actor before it disappears.
  • RespawnTime - how long it takes before actor will be gatherable again.
  • ExperienceReward - how many experience points are awarded to player profession upon successful gathering.
  • ItemRewards - items that will be granted to player upon successful gathering.


You can adjust what animation montage will be played during gathering resources by overriding PlayGatheringAnimation event in your hero blueprint.

Blueprint Interfaces

Blueprint interfaces are divided into two groups: General and Widget Updaters.

WIDGET UPDATERS

These blueprint interfaces are used only to send data from player components to widget blueprints. More info about each of them in corresponding components sections or sites (for Achievements Updater check Achievements Manager etc.).


GENERAL

These blueprint interfaces are used to simplify communication between player hero and various objects.

BPI_RPG_Combat
Currently implemented only in player hero blueprint. Thanks to this other blueprints can easily get player hero different conditions: can a hero be attacked, can hero move and similar.
To check how they are implemented or to extend certain conditions go to BP_RPG_Hero blueprint.

BPI_RPG_Interaction
This blueprint interface is implemented in every blueprint that player can interact with. It determines what interaction will be executed when an object interacted by the player. Enemies will be attacked, items will be picked up and NPC will start a dialogue.
To make object interactable implement this interface to its blueprint. Once it is done you can configure a few things. The implemented interface will add a few functions to your blueprint:
  • CanBeInteracted – here you define the condition that allows (or disallows) to interact with the object.
  • GetInteractionText – returns text that will be displayed when a player gets in interaction range.
  • GetInteractionRange – determines how far from the object player can be to interact with it.
  • GetInteractionType – used only in top-down mode. Defines how Hero AI should act. In most cases, a player hero will just come to the object and try to interact with it. The only exception is Enemy, once the player hero gets close enough to the enemy it will attempt to attack it.

When you implement this interface to the blueprint you will also get access to two events:
  • OnActorBeginInteract – this is executed when the player attempts to interact with the actor. Use it to implement what happens on interaction (ie. interacted NPC pops up dialogue window, quest collectable is being collected and disappears or an item is added to player inventory).
  • OnActorEndInteract – this one is executed when the player finishes an interaction with the actor. Can also be used to interrupt ongoing interaction (ie. player talks with NPC and is hit by an enemy, so game automatically closes dialogue window).

Blueprint Function Libraries

There are 3 function libraries that are mainly used by their corresponding Managers:

ITEMS FUNCTION LIBRARY (FL_RPG_Items)

Global functions:
  • ItemQualityToColor – simple conversion function that returns color depending on chosen quality.
  • ItemQualityToText – simple conversion function that returns text depending on chosen quality, the text is ready to be used in widgets.
  • ItemTypeToText - simple conversion function that returns text depending on chosen item type, the text is ready to be used in widgets.
  • BonusTypeToText - simple conversion function that returns text depending on chosen item bonus, the text is ready to be used in widgets.
  • RollItemQuality – returns random quality from the pool of available qualities of the given item. For demo purposes, each quality has an equal chance to happen but there is also slightly more advanced functionality prepared – just connect nodes indicated by comment.
  • RollItemBonuses – returns random bonuses rolled from pool of available item bonuses. Number of bonuses depends on Item Quality. System also has possibility to roll duplicates or only unique bonuses. Rolled bonuses will have weight in range from 0 to 1.
  • CalculateItemBonusesValues – this function extracts bonuses and their values from item structure. Items stores bonuses in ranged weight (0-1) thanks to this items and their bonuses can be edited later and changes will be reflected in game at any stage of development. So this function is simply used to convert weights into actual values.
  • ApplyBonuses – adds bonuses to actor, each available item bonus type should have its behavior implemented here. Bonuses aren’t limited only to increase or decrease stats and attributes. However, unique bonuses will require unique implementation.
  • RemoveBonuses – removes bonuses from actor, each available item type bonus should have its behavior implemented here. Generally, it should be opposite to what ApplyBonuses function does.


STATS FUNCTION LIBRARY (FL_RPG_Stats)

Global functions:
  • AttributeTypeToText - simple conversion function that returns text depending on chosen attribute.
  • StatTypeToText - simple conversion function that returns text depending on chosen stat.
  • DurationTimeToText – converts seconds to widget friendly text (minutes + seconds). Used to properly display buffs and effects remaining time.
  • SingleDigitToDoubleNumber - converts single-digit integer value to double-digit string (ie. 5 becomes 05). Mainly used to properly display time in widgets.
  • AddUpAllArrayIntegers – adds up all integers from an array and returns a single integer value.
  • AddUpAllArrayFloats - adds up all floats from an array and returns a single float value.
  • MultiplyAllArrayIntegersByBaseValue – multiply by given base value by all integers from an array and returns base value after all changes.
  • MultiplyAllArrayFloatByBaseValue - multiply by given base value by all float from an array and returns base value after all changes.
  • GetBuffStaticDataFromDatatable – reads buff data from the buffs data table.
  • GetEffectStaticDataFromDatatable – reads effect data from the effects data table.


QUESTS FUNCTION LIBRARY (FL_RPG_Quests)

Global functions:
  • TimeToText – converts time (which is provided in seconds) to proper text (hours/minutes/seconds).
  • ConvertIntToDoubleDigit – converts single-digit integer value to double-digit string (ie. 5 becomes 05). Mainly used to properly display time in widgets.

Data Tables

ACHIEVEMENTS

DT_RPG_Achievements – contains all achievements available in the game.
  • ID – unique ID used to distinguish achievements in the game logic. Have to be the same as a row in the data table.
  • DisplayName – the name displayed to players.
  • Description – brief description of what player has to do, also displayed to players.
  • ObjectiveType – achievement objective, multiple achievements with the same objective will be grouped together to create tiers.
  • RequiredProgress – how much progress in the objective player has to acquire to complete the achievement.
  • Reward – awarded to the player for completing the achievement. Can be expanded in S_RPG_AchievementReward structure. The logic for each achievement reward should be implemented in Achievements Manager.
  • VisibleByDefault – determines whether achievement is visible to the player right away or it becomes visible later (ie. can be shown by finishing another achievement).
  • AchievementsToShowOnFinished – list of achievements that will become visible to player when this particular achievement is finished.

QUESTS

DT_RPG_Quests - container all quests available in the game.
  • ID – unique ID used to distinguish quests in the game logic. Have to be the same as a row in the data table.
  • DisplayName – the name displayed to players.
  • Description – description of what the player has to do.
  • Type – category of quest. Different quests can be displayed differently in the game world, ie. story quests may have different indicator color than repeatable quests.
  • MaxRepeats – how many times quests can be finished.
  • RequiredFinishedQuests – what quests player has to finish to make this quest available.
  • Objectives – a list of objectives that the player needs to fulfill to complete the quest. Each objective consists of objective ID paired with its required progress and brief text description displayed to the player.
  • FinishAutomaticallyOnObjectivesCompleted – determines whether the quest should automatically finish itself when all objectives are completed.
  • FinishQuestInfo – short info displayed to the player when all objectives are complete. This will be displayed in place of complete objectives, basically giving hint what the player has to do to finish the quest (ie. Bring seeds to Elder).
  • AcceptNewQuestsOnFinished – quests that will be automatically acquired when this particular quest is finished. Used to make chained quests.
  • UnlockQuestsOnFinished – quests that will be unlocked and available to the player when this particular quest is finished. Useful when certain quests should be available to the player with story progress (ie. quests in certain town are available when a town is rescued).
  • UnlockedByDefault – determines whether the quest is available to the player from the beginning (player still need to fulfill requirements to accept it). Locked quests can be unlocked manually on demand through Quests Manager.
  • Removable – determines whether quest can be aborted or not.
  • AutoAbortWhenFailed – determines whether quest should be immediately removed from quest log when it has failed.
  • AutoTrackWhenAccepted – determines whether quest should be automatically added to quest tracker when it is acquired.
  • InterruptDialogueWhenAccepted – if this is checked, the dialogue window will be automatically closed when the player acquires this particular quest. Useful when the player acquires timed quest and he shouldn’t spend more time talking with NPC or when NPC becomes hostile after acquiring the quest.
  • Reward - awarded to the player for completing the quest. Can be expanded in S_RPG_QuestReward structure. The logic for each quest reward should be implemented in Quests Manager.
  • TimeToComplete – time to complete the quests, when time runs out. If equal to zero, the quest won’t be timed.

BUFFS AND EFFECTS

DT_RPG_Buffs – contains all buffs available in game.
  • Type – determines the type of the buff, each buff should have a unique type. Buff type should be exactly the same as row name.
  • DisplayName- the name displayed to players.
  • Description – brief description displayed to players.
  • InfluenceType – determines whether buff is positive, negative or neutral. Leaving it at NotDefined state will make buff unable to react to various gameplay elements.
  • Displayable – determines whether buff can be displayed to the player in Buffs and Effect Bar widget. If buff is not displayable it will still work, the player just won’t see its icon.
  • Icon – an image of the buff.
  • Stackable – determines whether buff is stackable or not. Bonuses of stackable buffs are multiplied by the number of currently applied stacks.
  • MaxStackAmount – the maximum number of stacks that can be applied.
  • RemoveStackByStack – determines default removal behavior when buff time runs out or is removed on demand. When this option is checked in and there are several stacks applied it will remove one stack of the buff and reset its duration. When checked off it will remove a buff regardless number of stacks.
  • Unremovable – determines whether buff can be removed by standard methods. If this option is checked in the buff can only be removed by selecting a special option during using removal function.

DT_RPG_Effects – contains all effects available in game.
  • Type – determines the type of effect, each effect should have a unique type. Effect type should be exactly the same as row name.
  • DisplayName- the name displayed to players.
  • Description – brief description displayed to players.
  • InfluenceType – determines whether the effect is positive, negative or neutral. Leaving it at NotDefined state will make effect unable to react to various gameplay elements.
  • Displayable – determines whether the effect can be displayed to the player in Buffs and Effect Bar widget. If the effect is not displayable it will still work, the player just won’t see its icon.
  • Icon – an image of the effect.
  • AdditionalTickWhenApplied – determines whether one additional tick should be executed immediately when the effect is applied.
  • Stackable – determines whether the effect is stackable or not. Power of stackable effects is multiplied by the number of currently applied stacks.
  • MaxStackAmount – the maximum number of stacks that can be applied.
  • Unremovable – determines whether the effect can be removed by standard methods. If this option is checked in effect can only be removed by selecting a special option during using removal function.

ITEMS

DT_RPG_Items – contains all items available in the game.
  • ID – unique ID used to distinguish items in-game logic. Have to be the same as a row in the data table.
  • DisplayName – the name displayed to players.
  • Description – description what player has to do, also displayed to players.
  • TriviaText – additional description. Acts as flavor text usually not related to gameplay. Displayed to players as well.
  • Size – determines how many slots horizontally and vertically item occupies in containers.
  • Value – default value of the item.
  • Type – a category that item belongs to.
  • Subtype – sub-category to group items better.
  • Usable – determines whether the item can be used or not (ie. potion).
  • RegistrableInQuickBar – determines whether the item can be registered in Quick Access Bar or not. Usually, items that are not usable should be registrable as well because they won’t provide any effect when used through quick access slot.
  • Image – an image of the item.
  • MaxAmountInStack – how many pieces of the specific item can be collected to one stack.
  • AdditionalLockedSlots (equipment exclusive) - determines which slots will be locked/excluded from equipment when this specific item is equipped. Eg. If you want to create a two-handed weapon you can lock slot where a shield is equipped. One item can lock multiple slots.
  • AvailableBonusesGroupID (equipment exclusive) – determines what group item uses to roll its random bonuses. More about bonus group below in DT_RPG_ItemBonuses section.
  • AvailableQuality – all qualities that item can occur in.
  • SkeletalMeshEquip (only for equipment) - this skeletal mesh component will be added to the actor when the item is equipped. Skinned meshes can be used to create equipment parts which need to bend with the body, such as torso armor or trousers.
  • SkeletalMeshEquipSocket (only for equipment) - determines to which socket a mesh should be attached when equipped to a certain slot. Use this only if you want the mesh to be attached to a socket (ie. bow or whip), leave empty and it will be attached to the main mesh (ie. armor).
  • StaticMeshEquip (only for equipment) - this static mesh component will be added to the actor when the item is equipped. Static meshes are mostly used for rigid equipment parts, such as weapons or helmets.
  • StaticMeshEquipSocket (only for equipment) - determines where static meshes are attached to (to which sockets). It requires a paired slot index and socket name. Thanks to this we can equip the same item to different slots without excessive changes. Eg. Let's assume we have two equipment slots with indexes 1 (right hand) and 2 (left hand). We also have a sword which can be equipped to the right or left hand. Thanks to this paired values we can set up that when the sword is equipped to slot 1 its static mesh will be attached to the right-hand socket if the sword was equipped to slot 2 it would be attached to the left-hand socket.

DT_RPG_ItemBonuses – contains all group used to determine bonuses for items.
Each row contains only one variable – AvailableBonuses. Each available bonus consists of bonus type paired with its minimum and maximum values. Row names are used as AvailableBonusesGroupID in Items data table.

DT_RPG_Craftables – contains all craftable items available in the game.
  • ID – unique ID used to distinguish craftables in the game logic. Have to be the same as a row in the data table. It also has to be the ID that can be found in Items data table, otherwise, no items will be crafted.
  • RequiredMaterials – ID of the item paired with its required amount. Multiple materials can be added.
  • CraftingGroup – a category that craftable belongs to. Used to group items in crafting window widget.
  • CraftedAmount – how many items will be crafted on a single crafting attempt.
  • UnlockedByDefault – determines whether craftable is unlocked and visible to player by default or it becomes available at special circumstances (ie. player need to use recipe item to unlock it).
 
LEVEL

DT_RPG_Level – contains all levels that can be acquired by a player hero.
  • ExperienceNeededToReachThisLevel – how much experience points player need to accumulate to acquire this level (each time player levels up experience counter is reset).
  • AttributePointsGainedOnLevelReached – how many attribute points the player will receive when acquiring this level.
  • PerkPointsGainedOnLevelReached – how many perk points the player will receive when acquiring this level. PERKS SYSTEM IS NOT USED CURRENTLY.
  • SkillPointsGainedOnLevelReached - how many skill points the player will receive when acquiring this level.

OPTIONS

DT_RPG_Options – contains a list of all options available in the game. To add new options to the game expand certain options maps instead of creating new options row.
An in-depth guide on how to create new game options can be found in Options Constructor dedicated site.

DT_RPG_Keymappings – contains a list of all default project keymappings. All rebindable keymappings should be added there.
An in-depth guide on how to create new game options can be found in Options Constructor dedicated site.

HEROES

DT_RPG_Heroes – contains all heroes available in the game.
  • DisplayName – the name displayed to players. It can be the name of the character, its class or profession, etc.
  • ActorClass – blueprint template that is used by this hero.
  • Portrait – image used during dialogues.
  • DefaultAttributes – starting values of hero attributes.
  • AttributesPerLevel – determines how attributes increase with each gained level.
  • AttributesBonusesToStats – determines how attributes affect stats.
  • DefaultStats – starting values for hero stats.
  • DefaultStats(CurrentValues) –determines what stats use “current” state (ie. Health or Mana) and their initial values.
  • StatsPerLevel – determines how stats increase with each gained level.
  • DefaultPerks – CURRENTLY NOT USED.
  • StarterEquipment – equipment that the hero starts with. Each element requires equipment slot index and data of item equipped to it. You can also specify item quality and its bonuses.
  • StarterItems – starting items that will be added to player inventory.
  • StarterStashItems – starting items that will be added to player storage.

SKILLS

Each data table determines a different set of skills.
  • ID – unique ID used to distinguish skills in the game logic. Have to be the same as a row in the data table.
  • DisplayName – the name displayed to players.
  • TriviaText – acts as flavor text usually not related to gameplay. Displayed to players.
  • Type – what category skill belongs to.
  • Cooldown – the time between skill uses.
  • DefaultLevel - starting level of the skill. Skill will be at this level once it becomes available to a player (ie. after its requirements are met or when it is unlocked).
  • UnlockedByDefault - determines whether a skill is available to a player (of course, once its requirements are met) or player needs to complete special action to unlock it (ie. finish a specific quest or reach a certain level).
  • UnlockingRequirementText - a hint that will be displayed in skill tooltip to let a player know what he needs to do to unlock a certain skill.
  • Icon - an image of the skill.
  • RequiredSkills - all skill (and their levels) that player must possess to make this skill available. Used mainly to create larger, complex Skill Tree with a lot of subskills.
  • Levels - contains data of all levels of the skill. Each level has a few editable variables:
    - PointsRequiredToUpgrade - how many points a player needs to spend to upgrade to this level.
    - Description - description of a specific skill level that will be displayed to a player (ie. in skill tooltip).
    - Stats - custom stats map (name + value) that is used to handle skills effects in blueprints.

ENEMIES

DT_RPG_Enemies – contains all enemies available in the game.
  • ID – unique ID used to distinguish enemies in the game logic. Have to be the same as a row in the data table.
  • DisplayName – the name displayed to players.
  • DefaultStats – starting values for enemy stats.
  • DefaultStats(CurrentValues) –determines what stats use “current” state (ie. Health or Mana) and their initial values.
  • StatsPerLevel – determines stats increment per enemy level.
  • PerLevelXP – XP gained by players when the enemy is killed. Multiplied by the enemy current level.
  • LootableItems –items that enemy can drop when it is killed.
  • AchievementsObjectives – achievements that will be progressed when the enemy is killed.
  • QuestObjectives – quest objectives that will be progressed when the enemy is killed.

NPC

DT_RPG_NPC – contains all NPC available in the game.
  • ID – unique ID used to distinguish NPC in the game logic. Have to be the same as a row in the data table.
  • DisplayName – the name displayed to players.
  • Portrait - image used during dialogues.
  • GreetingDialogue – dialogue that will be displayed to the player when he starts an interaction. Consists of InitialPlayerText and Dialogues*.
  • QuestsToAccept – list of quests possible to accept at this NPC. Consists of Quest ID paired InitialPlayerText and Dialogues*.
  • ObjectivesToProgress – list of quests objective that player can progress at this NPC. Consists of Objective ID paired with InitialPlayerText and Dialogues*.
  • QuestsToFinish – list of quests possible to finish at this NPC. Consists of Quest ID paired with InitialPlayerText and Dialogues*.
  • FarewellDialogue – dialogue that will be displayed when the player chooses the farewell option from the dialogue window. Consists of InitialPlayerText and Dialogues*.
  • Vendor – determines whether NPC sells and buys items.
  • VendorDialogue – dialogue that will be displayed when the player chooses the vendor option from the dialogue window. Consists of InitialPlayerText and Dialogues*.
  • VendorBasicItems – list of items that will be for sure available at a vendor.
  • VendorRandomItems – list of items that NPC will randomly choose from when filling its container.

*Whenever a p wants to accept or finish a quest, progress the objective or access the vendor, the game will start a conversation. Each conversation consists of 2 variables:
  • InitialPlayerText – single text that will be visible on dialogue slot in the dialogue window.
  • Dialogues – a sequence of NPC texts that will be displayed one after another.
The only exception is GreetingDialogue. A player doesn’t have the possibility to choose any option because Greeting is started automatically when interaction happens. In this case, InitialPlayerText will be displayed as first and then NPC Dialogues sequence.

AI System

The AI system uses the behavior tree system. However, most of the functionality is handled by the components, they also store variables (instead of variables being stored in blackboards). There is one AI controller (BP_AI_Controller) which has all these components and is used as some kind of bridge between these components and behavior tree. The AI system is driven by commands, actions, and events that let users control and plan their AIs behavior.

Commands are sent to the AI controller so the system can determine what to do next. Available commands are:
  • Follow - AI will follow the given actor as long as it's in the threshold range.
  • Patrol - AI will move from point to point taking a short break every time it reaches the destination. Points can be visited randomly, in loop or back and forth. Direction can also be determined.
  • RoamAroundPoint - AI will randomly roam around a given point. It means it will move between random points in a certain radius from the center point. It will also take a short break every time it reaches the destination.
  • RoamAroundActor - AI will randomly roam around a given actor. It means it will move between random points in a certain radius from the actor. It will also take a short break every time it reaches the destination. AI will roam around the actor as long as it is in the threshold range.
  • StartInteraction - AI will attempt to interact with a given actor.
  • EndInteraction - AI will attempt to finish currently ongoing interaction. You can determine whether interaction ended successfully (ie. AI interacted long enough to turn on a machine) or was terminated (ie. AI was hit and it interrupted the interaction).
  • Idle - simply turns off active behavior.
  • Move - AI will attempt to move to a given actor, or if the actor is not specified to a given location. Basically, this command is built-in MoveToActor/MoveToLocation. It is just slightly extended to work with the AI system. Important: using Move command will always reset behavior to the idle state.
  • Attack - AI will attack a given actor (as long as the required conditions are met, IE. actor can be targeted). Additionally, you can choose to force attack, so AI will attack the target regardless if it is the biggest threat or it is an ally).
  • Support - AI will support a given ally (as long as the required conditions are met, IE. actor can be targeted).
  • ResolveAttackEffect - this command is used internally by the system and is used to execute an attack effect when the animation time is right.  So during sword swing animation, a character can do the damage when a sword is in front of the character instead at the beginning of the animation.

Commands can be called as long as you have access to the actor's AI controller. Most of the commands work within a limited radius (threshold). So usually you will need to use Move command first and when AI arrives at the destination follow up with another command (like Roam or Attack).


Actions are taken by the controlled actor, so the system knows what to do when given behavior is active or how long it lasts. Actions are already implemented in enemy (BP_RPG_Enemy) and NPC (BP_RPG_NPC) blueprints. However, they are empty and are meant to be overridden/extended in children's blueprints. All of the action return "Implemented" boolean, it lets the system know that the actor uses given action. Additionally, most of the actions return "Duration" float, it informs the system how long certain action will last. These are available actions:
  • SwitchToMelee - determines what to do when AI switches from Ranged or Support to Melee combat.
  • SwitchToRanged - determines what to do when AI switches from Melee or Support to Ranged combat.
  • SwitchToSupport - determines what to do when AI switches from Melee or Ranged to Support combat.
  • UseMeleeAttack - determines what to do when AI performs a melee attack on an enemy actor.
  • UseRangedAttack - determines what to do when AI performs a ranged attack on an enemy actor.
  • UseSupportAction - determines what to do when AI performs support action on ally actor.
  • EngageCombat - determines what to do when AI engages in combat. (IE. Equip weapon)
  • DisengageCombat - determines what to do when AI disengages combat. (IE. Unequip weapon)
  • StartInteraction - determines what to do when AI starts interacting with an actor. (IE. Play different animation depending on the interactable type)
  • StopInteraction - determines what to do when AI stops interacting with an actor. (IE. Stop playing interaction animation)

Keep in mind that if you want to use given action and usually you want to use at least a couple of them you need to override it in child blueprint and at least check "implemented" state.
For example, you need to override both EngageCombat and DisengageCombat and check "Implemented" even if you don't plan to use any animations to switch between these states. Otherwise, the system will think that the actor cannot engage or disengage combat.

There are two special actions GenerateEnemyToAttack and GenerateAllyToSupport. You can use them to override the system's default enemy or ally generation. By default, AI will attack the enemy with the highest threat and support the ally that's closest. Using these two actions you can implement your own logic how targets are chosen (IE. prioritize the enemy that is ranged or support the ally that has the lower health).
Important: Keep in mind that these functions are called quite frequently (every ~0,5s), so try to keep them as performant as possible, unless you are planning to have only a few enemies in the level.


Events are responses sent to the controlled actor when given action has taken place or AI state has changed in general. Here is the list of currently available events:
  • OnCombatEngaged - called when AI successfully entered the combat. Additionally, it provides AttackType that determines which combat type was used to enter the combat.
  • OnCombatDisengaged - called when AI successfully leaves the combat. It also provides AttackType that determines which combat type was active upon leaving the combat.
  • OnSwitchedToMelee - called when AI successfully attempted to switch combat style to melee. Provides parameter that determines from which combat stance it has switched.
  • OnSwitchedToRanged  - called when AI successfully attempted to switch combat style to ranged. Provides parameter that determines from which combat stance it is switched.
  • OnSwitchedToSupport - called when AI successfully attempted to switch combat style to support. Provides parameter that determines from which combat stance it is switched.
  • OnSwitchingInterrupted - called when AI didn't manage to fully switch combat style (IE. a character was hit or stunned and thus interrupted during playing weapon switching animation montage).
  • OnAttackEffectResolved - called when given action takes place. (IE. a character swings sword but actual damage is during in the middle of the animation montage, so this event will be executed at that point). Use the SwitchOnName node to control different attacks. Currently, available names are Melee, Ranged, Support (they are case sensitive).
  • OnAttackInterrupted - called when AI didn't manage to fully perform an attack (IE. a character was hit or stunned and thus interrupted during playing an attack animation montage).
  • OnPatrolBreakStarted - called when AI takes a break when it reaches the destination (patrol point).
  • OnPatrolBreakEnded - called when AI finishes its break at patrol point.
  • OnRoamBreakStarted - called when AI takes a break when it reaches the destination (random roam point).
  • OnRoamBreakEnded - called when AI finishes its break at random roam point.
  • OnRoamTargetChanged - called when AI notices that the actor it was meant to roam around has changed, either it was switched manually, deleted or went outside the threshold range.
  • OnFollowTargetChanged - called when AI notices that the actor it was meant to follow has changed, either it was switched manually, deleted or went outside the threshold range.
  • OnInteractionStarted - called when AI successfully started interaction.
  • OnInteractionEnded - called when AI ended interaction, either it was successfully finished or terminated.
  • OnMovementFinished - called when AI finishes movement.

All these events should be overridden in children's blueprints so each actor/character can act uniquely.
Important: if you have a lot of blueprints in a hierarchy and want to override an event in the blueprint lowest in the hierarchy it should be overridden in all parent blueprints otherwise it may not be executed.
Example. You have the Enemy blueprint, then there is Goblin blueprint which inherits from the Enemy, then there is RangedGoblin which inherits from Goblin and lastly, there is GoblinArcher which inherits from RangedGoblin. So the hierarchy looks like this Enemy>Goblin>RangedGoblin>GoblinArcher.  If you want to override the OnCombatEngaged event and implement functionality in GoblinArcher you should override this event in Goblin and RangedGoblin blueprints as well (though you don't need to implement functionality, the event just need to exist there).


There are also AI examples which can be downloaded separately from here: LINK
Unpack it and paste the AIExamples folder directly to your project's content folder. Most of the examples are simple but should let you better understand the AI system and help you wrap the head around it.  New examples will be added from time to time to present different combinations and behaviors.

AI Configuration data table

AI Configuration data table consists of several sections:

ROAM
  • Radius - how far from a target (point or actor) AI can roam.
  • BreakDurationMin - minimum time AI will be waiting when it reaches a destination point (roam point).
  • BreakDurationMax - maximum time AI will be waiting when it reaches a destination point (roam point).
  • Threshold - range in which Roam Behavior works. Always should be higher than the Radius. If the distance to a target is higher than the threshold AI will stop roaming.
FOLLOW
  • DistanceTolerance - distance to a target below which AI won't attempt to move.
  • Threshold - range in which Follow Behavior works. If the distance to a target is higher than the threshold AI will stop following.
PATROL
  • BreakDurationMin - minimum time AI will be waiting when it reaches a destination point (patrol point).
  • BreakDurationMax - maximum time AI will be waiting when it reaches a destination point (patrol point).
COMBAT GENERAL
  • CombatType - determines how AI fights.
  • MeleeToRangedSwitchDistance - the distance at which AI will convert from melee to ranged combat (if the distance is above this value) or from ranged to melee combat (if the distance if below this value). This will work only if the CombatType option is set to AdjustToDistance.
  • PrioritizeSupport - if AI can support and has proper ally target to support it will choose to support that ally over fighting the enemy.
  • IgnoreCombat - determines if AI should ignore combat completely and always do its non-combat activity (follow, roam, etc.). AI will never involve in combat even if it has nothing else to do. Note that either fighting the enemy or support the ally is considered as combat.
COMBAT MELEE/RANGED
  • AttackRadius - maximum distance to the target at which AI will perform an attack. If AI is farther than this it will attempt to move to a target until it enters the AttackRadius.
  • DistanceTolerance - added to the AttackRadius during distance checks. This prevents AI from moving when its target is at the edge of the AttackRadius even if the target moved a little bit farther. Thanks to this AI is more tolerant of any location changes and doesn't attempt to chase the target if the location changes 1cm by 1cm.
  • AttackFrequency - how often AI will perform an attack. (2.0 = attack once every 2 seconds, 4.5= attack once every 4.5 seconds)
  • AcceptanceAngle - before AI performs an attack it will rotate toward the target to face it. This determines how inaccurate AI can be. AI will continue to rotate until the angle between the controlled actor and its target is lesser than this. Usually, you want to keep it at least at a few degrees so AI can attack and not spend forever rotating.
COMBAT SUPPORT
  • SupportRadius - maximum distance to the target at which AI will perform support activities. If AI is farther than this it will attempt to move to a target until it enters the SupportRadius.
  • DistanceTolerance - added to the SupportRadius during distance checks. This prevents AI from moving when its target is at the edge of the SupportRadius even if the target moved a little bit farther. Thanks to this AI is more tolerant of any location changes and doesn't attempt to chase the target if the location changes 1cm by 1cm.
  • AttackFrequency - how often AI will perform support activities. (2.0 = cast once every 2 seconds, 4.5= cast once every 4.5 seconds)
  • AcceptanceAngle - before AI performs a support activity it will rotate toward the target to face it. This determines how inaccurate AI can be. AI will continue to rotate until the angle between the controlled actor and its target is lesser than this. Usually, you want to keep it at least at a few degrees so AI can support and not spend forever rotating.
COMBAT ACTIVATION
  • SupportEnabled - determines whether AI is able to support allies or not. Generally, this could be achieved by overriding available targets to support. However, if you plan certain AI to never have support capabilities leave this uncheck so the system will skip several conditions checks.
  • Aggressive - determines whether AI should automatically attempt to attack hostile targets that enter the SearchRadius. Otherwise, AI will attack only when it gets damaged, called by an ally or manually triggered.
  • SearchRadius - the distance at which AI starts checking whether an actor is an enemy or an ally.
  • DeactivationRadius - the distance at which AI stops checking whether an actor is an enemy or an ally (actors need to enter SearchRadius first).
  • HostileClasses - actor classes that are considered hostile (enemy). You can add classes one by one or you can add "master" class and select to consider all of its children's classes hostile.
  • FriendlyClasses - actor classes that are considered friendly (ally). You can add classes one by one or you can add "master" class and select to consider all of its children's classes friendly.
  • ObjectTypes - object types that system will consider during searching for enemies or allies in range.
  • CallAllies - determines whether AI should inform all allies nearby (in the SearchRadius) that an enemy is nearby. This activates either when an enemy enters the SearchRadius or when AI is damaged.

The above variables are only initial settings. You can change them anytime during runtime to achieve desired effects.