Mechanics
RTS Controllable AI - High Orbit
The behaviour tree designed for this ongoing project encompasses both independent AI tasks as well as player input. The behaviour tree in this example is the ‘Combat’ Tree. It handles changes in player input, such as an attack or move command, but also must be able to attack nearby enemy units independently of player control.
The above image shows the current iteration of the combat tree. This mainly encompasses an Idle, MoveTo and Attack tasks, based on the results given through an AI_Awareness service. This service is responsible for checking a given area and returning any valid pawn with another TeamID to the controlled pawn. This is done using a multi-sphere trace as shown in the image below:
Get Closest Enemy Function
Attack tasks based on the results given through an AI_Awareness service is responsible for checking a given area and returning any valid pawn with another TeamID to the controlled pawn. This is done using a multi-sphere trace as shown in the image above
AI Awareness Service
The AI_Awareness service, in of itself, clears the ‘EnemyPawn’ blackboard key on each cycle. This is for two reasons; firstly, to ensure that the controlled pawn does not continue attacking the previously set enemy pawn, after it has moved out of range. Secondly, to ensure that the controlled pawn is always switching targets to the closet enemy pawn. A new target is always set on each AI cycle, unless there are no enemy units within range.
RTS Building Construction - High Orbit
The design of the High Orbit project requires multiple key bindings to be utilised for different functions depending on unit type.
Three types of actor are created from the Parent_Baseclass object. These being:
-
Workers – Responsible for resource collection and building construction
-
Buildings – Responsible for unit creation
-
Combat Units – Fighting units capable of either direct damage or support abilities
With the Q, W, E, R, T and Y keys all being used to allow the player to interact with the selected unit’s options, dependent on type.
An enumerator is used to determine unit type and then utilises an interface and messaging nodes to execute the selected unit's first, second, third, fourth, fifth or sixth ability slot as shown in the image below:
Player Controller Input Key Commands
For this example, the Structure Build Options will be showcased to show how the worker units construct new buildings, in keeping with the in-game economy system.
The sole method of building construction for the player is through Ely_Drone units, which build up to six possible unit producing structures. Variables such as Build Time, Structure Option and Health are all stored within the Drone blueprint:
Ely_Drone Construction Options
The image below showcases the ‘C Drone Module’ option path and utilises a previously made macro within the gamemode. This is called through an event dispatcher to check the ‘Crystal Cost’ and ‘Fuel Cost’, collected by the player, through mining against the required costs needed to create the selected structure.
The ‘BP Ghost Building’ is a movable transparent actor, which allows the player to place the building in any location they choose, that isn’t blocked by another unit or structure.
The ‘crystal’ and ‘fuel’ costs are then reduced from the collected value stored in the gamemode:
'C_Drone Module' Function
All the variables collated within the Ely_Drone unit are then passed to the BP Ghost Building, which sets these variables with a struct node:
Building Manager Construct Building Event
The building manager blueprint then spawns a spawning actor, which acts as a visual representation of a building under construction. This actor retains all of the information from the struct. This is important as it allows the spawning actor to remain in the game world for as long as the initial ‘build time’ variable reaches <= 0:
Ghost Building 'Begin Build' Event
Once the spawning actor has reached the required build time in seconds, the building initially set in the Ely_Drone object is spawned, with the spawning actor timer being reset and the spawning actor destroyed.
The spawning actor is a child class of the BaseClass and therefore can be destroyed during the construction process. At which point the spawning actor is removed without spawning the selected building:
RTS Fog of War - High Orbit
The fog of war mechanic is a feature integral to every RTS game, and something that I had to replicate within my own project. With several different solutions attempted, the following method of fog of war creation proved to be the most effective, creating a polished fog of war effect with minimal taxing of the engine.
A render target was used, along with two materials. One spawned on level start; this was an entirely black material, used to mask all the sections of the level, with the exception of the player spawn location:
Fog of War Material
Fog of War BO on Begin Play
In the above image, the removal material is set and then used to remove any potential remaining cleared fog from a prior game save, by clearing the render target. In contrast to the M_fog material, the M_Removefog material is transparent. When this material is applied to the render target, this gives the impression of the prior M_Fog being removed from the level and providing clearer vision:
Remove Fog Material
To find a point to apply the removal material from, a camera is placed above the BaseClass object. This then applies a line trace from the forward vector of the camera, which returns a UV collision from the FogofWar_BP plane placed within the level, and acts as a point of reference from which to apply the removefog material from:
Base Class Clear Fog Event
To further reduce dependency on the engine, the on-tick event was removed and replaced with a 0.1 second timer. This timer executes the ‘clearfog’ event within the BaseClass as shown above. The ‘SubtractDrawVector’ function, calls another event within the FogofWar_BP. This utilises the editable ‘DrawLocation’ variable shown within the M_RemoveFog material, to draw the removal material onto the render target:
FPS Inventory
The FPS Inventory is a hidden object placed within the game world that acts as a storage space for the player. Having the inventory as a separate object reduces the amount of functions within the already large player class.
Weapons and objects that can be picked up by the player, use an interface to hide the pickup and place it within the inventory index,. If the player does not have any weapons in their inventory already, then the inventory automatically equips the weapon at slot 0 as shown in the image below:
Inventory Pick Up Function
Players are also able to cycle through their inventory, using the mouse wheel, which unequips the currently equipped item and finds and equips the next item in the array. If the player reaches the final object within their inventory, this function also resets the cycling of the inventory back to slot 0 as shown in the image below:
Inventory Cycle Function
Items that are either equipped through cycling or by being picked up by the player, are placed within the ‘Currently Held Weapon’ slot. If the player attempts to equip an item they do not have within the inventory, this function will also pick up the weapon, if there is a matching actor nearby:
Inventory Equip Function
Items can also be unequipped and placed back into the inventory, if they are the currently equipped item. Using a ‘Use Item’ interface rather than an individual event for each item, ensures that the same input used for firing the currently equipped weapon and throwing a grenade can be handled via the same input. Both of these mechanics are shown in the images below:
Inventory Unequip Function
Inventory Use Equipped Function
The final option within the inventory system is a drop function. This removes the selected item from the array entirely and within the item blueprint also spawns a pickup in front of the player. This pickup retains the same ammo capacity as was used when the player removed the item. This allows the player to potentially re-equip the dropped item from the location that the item was dropped.
RPG Pressure Plate Puzzle - The Puzzle Project
This mechanic presents the player with a grid of pressure plates and an interactable virtual screen. The screen displays the correct sequence of pressure plates for the player to move over only once. Therefore, the player must memorise the correct sequence to unlock the level door and escape the room. The majority of the functionality for this mechanic is stored within the virtual terminal. The player mouse is displayed when the player initially approaches the screen within the terminal collision radius; as shown in the image below:
Terminal Display Text Collision Event
The timer for showing the player the correct sequence is set to five seconds. When this timer expires, the player will not be able to see the sequence a second time, as the sequence text is hidden. The player does however, have the option to restart the puzzle:
Terminal Display Sequence and Text Events
The functionality of messaging the terminal, when the player moves over the correct plates, is displayed within the pressure plate blueprint.
These are identical to the false pressure plates to the player, but utilise the terminal direct reference to increment the ‘Plates Pressed’ integer by 1, for each correct plate that the player moves over.
Once the 6 correct plates increment the terminal value to 6, a new button is displayed within the ‘Terminal UI’, which displays another button to allow the player to open the level door:
Pressure Plate Collision Event
