Player Character
Importing a Character
Before I can begin to build character attacks I need to import and implement one into the game. This is easily done.
Firstly download the character into your unreal library, then add it to a project. When installed open the project. The character will be in its own file, characters, heroes, character name, and the picture of the character with the blue line at the bottom. Drag this into the scene.
To control the character go to project settings, maps and modes, selected game modes, default pawn class, click here and select the character name.
Re-targeting for Animations
Animations are set to the skeleton, so for me to animate the character properly I must go to the chosen player character’s skeleton (found in their folder).
Once inside navigate to the retarget manager.
Navigate to the set up rig sub menu.
and select the humanoid rig.
At this point we need a skeleton to retarget to. In the animations pack there is a skeletal asset, this is the target (SK_Mannequin_Skeleton). Repeat the steps above to get to the target’s retarget manager and select the humanoid rig here too.
Exit out of the animation packs skeleton, to the skeleton icon, and right click. Select “Retarget to Another Skeleton”.
This will open a new screen where you can select the target (remember to change the t-pose so both assets, if necessary, for the best results.
Evaluation
This is a simple enough procedure. Allowing an easy re-allocation of the character skeleton. This can be valuable in getting a game’s characters to move in synchronicity. Allowing an easy route to character animations. Which in turn makes easier blueprinting that can be affected across all characters. Especially if you are familiar with a particular set up.
Attaching Weapons to a Character
With the character now in game it is time to import some weapons and attach them to them.
I built two swords, one one handed and one two handed, and a shield.
To attach them to my character I went to the character’s skeleton. In here I can attach sockets to bones, naming them with a suitable name. Once a socket is created I then attached an asset and moved that into a suitable position via the viewport.
With this process I created sockets for a sword, a shield, and a big sword, all in hand and sheathed.
As you can see the character looks a little overloaded and unsuitable for game play. To get around this all weapon states not in use were hidden in game. Which I later changed in the character blueprint (making them visible again in the character viewport).
This gives me a greater control for later in the game process when using both sets of weapons.
Also the sword that Aurora uses is part of her mesh but still needed to be unseen with my weapons. So I found the slot for her default weapon and made an invisible material, which I applied to it.
Once added it is time to set up the character.
Collision is important, both in your weapons for damaging and in your character, and shield, for damage received.
Starting with the character by placing a collision sphere at the core of the body, this can be adapted to any collision (the more elaborate the fighting in a game the larger , or the greater number, of sphere(s)). I placed the sphere at the optimum height in my player 1 character.
This should capture most damage.
Next add collision to all of your weapons, capsule collisions are best for these.
With custom settings, on overlap, giving a nice selection to refine if need be.
Evaluation
Socketing a character is necessary in games. Allowing the designer to add any asset directly onto the character. As long as you position the asset correctly and select the correct socket, one within range of the asset, the process can be simple.
In this case, weapons, collision needed to be added. Though this may not always be the case the process was an easy one. The only stumbling point I can see is selecting which collision should be enabled but if the wrong one is assigned it is easily spotted and even easier to rectify.
Moving forward this process could be used to enable quick costume changes in game, armour, stealth, etc. I suppose these could be assigned to any socket because the socket and item are only exclusive to the designers set up. Adding shoes to a head socket would still work, as long as the shoes are positioned correctly on the feet, but it could become confusing to any one else who works on the game. For this I would recommend keeping to the rule of attaching the asset to, or as near as possible to, the assets displayed position. If only for ease of finding the socket location later on.
Animation Montages
Animation montages are exactly what they claim to be, an animation with added effects that create a montage. In the case of animating a character, or characters, a montage gives a simple route into compiling a chain of events within an animation sequence.
Firstly you must select a suitable animation (icon with green bar) you want to embellish, or change, into something that would be fitting in your game (a jump animation could be manipulated into a taunt or cast animation), there are no limits. The only problem is the time spent scouring through all of the available animations to find a suitable one.
When one has been selected it is time to make it into a montage. This is done by right clicking on the animation, moving to the “create” drop-down, and selecting create animation montage. Then add a naming convention suitable for the animation and later reference. Montage icons are blue.
Now you have your selected montages it is time to head into the desired character animation blueprint ( orange, I think, I am colour blind, Unreal need to deal with their pastel colour system). If you look closely there is a pseudo animation icon in the lower right of the icon.
In the viewport the animation plays on a loop with a time bar at the bottom centre of the screen. This allows you to pause the animation and drag it to a point most appropriate for a notify to be inserted (weapon damage would be where the weapon would begin to intersect the enemies body, and so on..).
The left of the screen is the skeletal and asset details, while the upper right is the details panel. The lower right is a full, scroll-able, list of all the characters animations and montages for easy selection.
Between the viewport and time bar is where we insert our notify’s.
The upper bar is the element timing, a sequential numbering of the notify’s from first to last to be fired. The lower is where the notify’s go.
Adding a notify is done by right clicking on the notify bar and selecting a notify. If the one you need is not there you can simply create one (naming it accordingly). All of the notify’s, available or created, in a character animation bp can be used in any, or all, of that character animations if desired.
I added the combo start notify to the point where the character was just about to start swinging their sword, if you miss just click on the notify icon in the notifies bar and drag it (the timing icon will follow as they are the same object). Then the reset at the end, signifying the end of the combo and the chain is reset, unless the player clicks before this, taking the combo chain to the next animation and it’s notifies.
One more thing is to set your montages into a group. This is like a montage set. Applying them all to one group means your character can access the whole group. On the other hand, if you set one to a different group the character will not be able to use them. The default group for my player character is “Upper Body”.
The best for an NPC is the “Default” group, which can be enabled in the animation graph (found in the animation blueprint via the tab at the top of the graph.
To enable the added notifies you must navigate to the animation blueprint, this is found in the upper right corner of the screen.
The animation blueprint graph is the same as all other graphs, so instantly familiar and easy to use.
Activating a notify is as simple as creating one. On the graph right click and type the name of the notify used. Call it. Cast it to the player character. At this point you must create a string in the character blueprint that enables the notify in the game. In the case of my two nodes a combo attack (adds to a combo chain) and a combo reset (resetting the combo chain if the player didn’t click before the animations “reset” notify was enabled.
First is the notify string:
Which refers to, and acts upon, the player’s combe chain:
and reset combo chain:
A quick method for creating notifies is to enable the character blueprint reference via the original cast to player node. This not only speeds up creation times but also is more efficient to the game engine (lack of superfluous code to read).
Evaluation
Creating an animation montage is a confusing process at first. Not being able to see the effects (or reasons why?) the notify’s are added. The order makes sense but the activation at the correct time was a little strange. After I had done it, and tested to see, I began to see the how and why. Starting with an opener (combo start) and ending with a close (reset), with all of the other notify’s in between.
Maybe this could be achieved through strings in the character blueprint. Referencing the desired animation and inserting conditions at set intervals within the string but this would be expensive to the games running speed. Possibly creating a lag the the animation editor lessens.
Combo Setup
In this unit we are working from a set of already created strings, showing us how to build and implement the required animations and strings. As a result, for the combo system, we were directed to construct this script:
All of the primary attacks are initiated through the left mouse button, with a condition that the player is attacking. If it is it is a combo chain attack, if not the character is attacking for a chain attack. This passes through a switch (on int), activating the first attack, then the second, and so on.. The “combo” variable on the switch is set to a default of one, which is why the set combo’s are 2,3, and 4 from switches 1,2 and 3, respectively.
The next node in the string is a variable, type montage. Allowing us to set which montage to use. Selecting from my previously created montages I added three, one to each, making a varied attack chain that followed the previous body positioning, attempting to create a flowing movement for the character.
Whichever one was currently in use was then passed through a “play anim sequence” node. Which then played the selected animation sequence on screen, in game.
With a bit of fiddling (I couldn’t understand the way notifies worked at first) I got them up and running. Having a player that ran around a barren landscape, seemingly swatting flies away with a sword, but they worked.
At the bottom of the combo string is the combo reset string (referenced in the animation montage section). Which resets the combo chain if the reset notify is fired.
Evaluation
With my accumulated knowledge of blueprints I found this fairly easy to understaand and replicate. I can see that further conditions can be added to this chain, like is the player alive, or immobilised.
I cannot see another way of replicating this at the moment. Even if it were done differently there are some parts that would be required to replicate.
Special Attacks
The special attack chain is triggered by the right mouse button. This functions differently to the combo system. Where the combo system cycled through a preset list of attacks the special attack is dependent upon how many combo attacks have been used, 2,3, or 4. This means we can set up a scaling assault of attacks in the special attacks.
The designated, education, string showed that we can only special attack under two conditions. The first is if the player is attacking, the second checks to see if the player can special. Both of these conditions must be met to proceed. If so one special attack (the corresponding one) can be fired, once. After that the combo is reset via a custom node, referenced in the combo reset string.
To enable the three choices of special attacks some further construction must be made.
Three branches form the execution of the specials. This is derived from the conditions attached. Where the attack count (combo count) is set in an “if A is equal to B” node. So if A is the combo count then that is equal to the node with the inputted, corresponding, number. Although the nodes below are all set to 0 in the actual string they are, from the top down, 2,3, and 4. This corresponds with the combo counter after the switch node in the combo chain. So if the player has accrued a 3 combo the attack count variable will check the first condition, which is 2, this is false, so the attack variable will move to the second condition (3), this is true so the special will be set through the true path on the corresponding branch, firing the subsequent special attack.
Now we can add a set montage node (same as combo system) which will fire a selected montage, played through a “play anim montage” node.
The “can special”, boolean, variable can now be added to the combo reset string.
For the “can special” to be viable it must be referenced as an active condition. Attaching it to a custom event (similarly labelled) and then adding a notify to the animation montage(s), and activating them through the animation blueprint, with a reference to the new custom event there, will achieve this. The animation for a special cannot be fired until the condition (can special) is met.
Evaluation
Although the special string contains some of the elements in the combo string it’s setup is different. Where the combo string is about sequentially firing attacks the special string looks for a particular number in order to complete it’s function.
A part that is the same is the conditions required for it to work. Although the “is attacking” is the same a new condition, can special, is exclusive for this data chain.
As far as a different route to achieve the same effect I cannot see at the moment. A possible alternative is having a click event, where the special is randomly picked upon pressing, or the quicker the reaction the higher the special attack. This can be achieved through a random integer in range (1-3), with each montage is assigned a number.
Health and Energy Setup
What is a character without health or energy, a god. We are not aiming for that so we need to add these to our character.
First stop is in the creation of a widget to display them through. I used a horizontal box, containing a vertical box, which held the progress bars and their titles.
Now I have a display for my character’s vitals a string is needed to actuate it. Luckily the two strings are identical, except for their names and variables used.
The progress bar is bound to the selected character. The player health/energy is referenced from the character blueprint, which is then set to the progress bar via the widget variable with the corresponding naming convention.
For this to work it must firstly have the corresponding variables in place, and secondly, be displayed to the viewport.
So in the character blueprint I created the two variables (leaving their values empty). These were set in a string (on begin play) and can be adjusted on testing. To display was a created widget added to viewport.
For our health to mean anything it must be able to be affected.
In the player blueprint a string must be created to calculate the players health after damage is received. If the damage and the player health are not equal the damage must be taken from the player health.
The energy is simpler and applied more directly. Again in the character blueprint. Adding a penalty cost to the special attacks (I had changed the attack count variable to a simpler “combo” named variable).
Adding to the previous constructed special chain, with the combo count condition, to run in conjunction with the special counter.
If the player energy is greater than, or equal to, the inputted number, and the combo is viable, fire this chain of special attack.
Now we have to watch both our heath and energy in game (I know the second energy check is not connected to the and condition, it is now). The energy was effected in the HUD (I increased the number to test it’s viability. This energy drain is placed at the end of the string, prior to the “play anim montage” node. A reference to the player energy passes through a minus (float, with a settable number input as the cost), before updating the player energy.
Both of these are added as set values to the initialise bar (begin play) setting their values at the beginning of the game.
Evaluation
This is a necessary addition to the game, without it it is just a sparring match. Doing this section helped me in further understanding the mathematics of Unreal (which seems to be algebraic). Also the cross blueprint communication aided in my seeing the bigger picture of the process.
Both of these strings are frugal in their construction. A simpler, but less customisable, way would be to have a set cost for every attack, in both receiving (health) and giving (energy), but then the game would just become a first hit wins scenario.
Rage Mode
My first act was to add a new progress bar and title to the widget. Along with this came the bind. It was slightly different from the health and energy.
After casting to the character the rage is divided by 100 then set.
Now an adjustment is required to the health damage calculation made previously.
Instead of the damage being taken straight from the players health it is now set after the condition. It is then divided by another new variable, armour, to give a new, lower, figure before being set as a calculation in the bind to be updated via the progress bar.
In order for a rage meter to be built another string must be made for a rage calculation. Which will build in it’s progress bar.
Created with a custom event (Get Rage). The rage is set by taking the damage received and dividing it by either 2 or 3 (set by a random float in range). This is the added to the rage mode variable, which is governed by a clamp to be no less than 0 and no greater than 100. The value is added to rage mode for the calculation in the bind, which will update on the HUD progress bar.
The “get rage” reference can now be added to the damage (health) string. Directly updating the progress bar.
The final step is to add both the rage and armour values to the initialise string (begin play). Setting their start values at the onset of the game.
Evaluation
The rage bar is an interesting addition. Using the damage received as a trigger to rage (just like real life). This added a new dynamic to the game.
Again the calculations became easier to understand. Calculating portion of the damage received as a direct affector to the rage itself is an insight.
As far as doing this in a different way, I suppose you could add the rage directly from the damage received calculation in the same manner. Doing it this way keeps the blueprint clean and easily identifiable, allowing a more accurate, and easily adjustable calculation.
Restore Energy
Having energy drained is all well and good but what happens when it has all gone. Somehow it would come back in the real world, so it must in a game.
The first step is to calculate the energy restoration rate.
This must be done in the character blueprint in order to effect them. As this is a calculation a function needs to be created. Using the existing “player energy” variable as a basis we add 1 per half second clamped to a value of no greater than 150 (the value set in the initialise string), it can also have a value no less than 0 (I think that would make you dead in real life).
To enable this calculation in the game the function must be enacted within a string.
A custom event (regen energy) passes through a function enabler node, in which the function accessed is named, the time per action of the function, and whether or not it is once or recurring. If the energy regen is interrupted a new custom event (stop_energy regen) clears the timer, halting the progress.
A reference of the regen energy event is added to the combo reset chain, renewing the progress from that point.
It must also be added to the beginning of both the combo and special attack chains. Negating the ability to regenerate energy while spending it. To do this we must first have a check making sure we are alive (can’t recover from death). So a new boolean variable (Alive?) must be checked before the energy regen is affected.
Evaluation
Again an important feature in a game. It would be easy to play a game and not realise the player cam sprint, climb, and fight forever but this is never true in reality.
The process is as simple as any I have seen. Plus the calculation is one of basic arithmetic. Halting it’s progress upon expenditure of energy helps to make it a realistic mechanism.
I don’t think there could be an easier way of replicating this short of Unreal creating a special node catered just for this procedure.
Camera Shake
Ever hit something so hard it felt like all of your joints shook?
In a fight to the death the blows would be as mighty as the wielder can manage. If this could be achieved in a game it would add to the struggle and terror involved, that and it would look cool. As luck would have it, in the world of computer simulated life, you can.
There is a node just for this.
Adding a custom event, to initiate and a variable for the magnitude (10) it can be done.
For the shake to occur a blueprint must be created.
Go to the content browser (BP folder) and right click. In the all classes bar type camera shake.
Select it and rename it something appropriate (Character camera shake).
Open it and input the values of the shake.
Then reference it in the camera shake node, under the dropdown entitled “Shake”.
Now go to the character animation blueprint and create a new notify, placing it in the notifies bar at a suitable place in the animation (just after the strike is best).
When done go to the animation blueprint and create a notify, using the camera shake (custom event) node as the reference.
For it to be of any use it must be used in a string, in all of the desired attack ones. Do this by setting the camera shake variable created for the original camera shake string. Adding a magnitude worthy of your players blow.
Evaluation
This was a fun node I had no idea Unreal had created. The enabling process was mostly a recap of what had been done before. Except for the blueprint creation but that was for the base settings.
As far as replicating this effect in another way I think it could be done by setting up a camera and adding a string which moved it’s world location side to side over a small distance. Though this would be a pointless task.
As far as the mechanic it has endless uses from moving heavy blocks to the effect of a tank rumbling past in a war game. Fantastic!
FOV Change
With a shake in place why not disorient yourself a little more with a field of view change.
Using, a now familiar, custom event (Zoom FOV), a timeline and a set field of view, all effecting a chosen camera.
The timeline is set by opening (double click). Once inside you can build a timeline. This one has three points of time. The first is 0 seconds 90 degrees, the second 0.2 seconds and 70 degrees, the third is 0.5 seconds and 90 degrees. So a half second wobble with a movement of 20 degrees towards the player, and back again.
To enable this as part of the attack sequence we must , again, create a notify and reference it.
Evaluation
This was a fun addition but not as fun as the camera shake. It has a feeling more like the morning after a good nights drinking. With that said it is a nice effect with many uses. Like a transition in a game when you pass an item of interest, or even a reaction to a blow.
Again replicating this would be an exercise in futility as the string is short and sweet.
Character Launching
In a hard fought battle a forward surge of the body can double the force of the blow. Any fighting game must have at least one example of this mechanic if it is to be believed.
This is another one of those unexpected nodes that Unreal have nicely created for us.
Starting with another custom event we set the ground friction to 0 (slippy), launch the character, after a delay of a quarter of a second the friction is returned to the ground allowing traction again.
The direction of the launch is determined by the vectors, forward and up take your character upwards frontally, right and up will take your character in an upward right manner. With this in mind there is a need to create a launch variable matching the desired vector, forward vector and launch force, up vector and up force. These are multiplied together giving a direction and speed. When you have two sets (forward vector and up vector) they are added to give the illusion of a leap in that direction.
When done it can be added to the notifies, referencing the custom node as usual. Then it can be added to your attack string, where desired, setting whatever force you like.
Evaluation
Another useful accent for a convincing attack sequence.
The mathematics was simple again, allowing me to understand the construction of Unreals procedures a little more.
To recreate this in another way would require moving the character with an involuntary jump instead of a launch.
Adding Collision to the Character
With my character set up for damage recognition, giving and receiving, it was time to move on to what can be seen in game.
For the collision to be recognised by the character it must be referenced in the blueprint. Creating two custom events (collision on and off) per weapon, the target being the weapon’s collision mesh from the components panel.
For this to be useful it must be told when to be activated and deactivated. This is done via the character animation montage. Creating a collision on and off, placing them at the optimum position(s) in the animation sequence.
Calling the new animation notifies in the animation blueprint, attaching each to the collision, enable & disable, events in the character blueprint.
Now we add damage to the overlap. If the player and the collision object are not equal apply this damage, a random number between the min and max damage values, all of this is instigated via the players controller.
To reset this, after one strike, a custom event named reset damage, ran through a sequencer, attaches to the reset(s) on do once.
A reference of this is then attached to the end of the sword collision disable(s), resetting the damage after the strings execution.
Damage modifiers are added to the two ultimate attack weapons directly to their blueprints. The heavy sword attack gets a one hit value of 500,
While the spin attack gives 15-25 per collision, via a random float in range.
Evaluation
Making a collision visible, in the games language, is an important aspect. Not only in fighting games, but all games. Collecting coins in Mario, colliding with another car, even on a basic level of walking into a table. This process adds a new dynamic of target-able collision. Allowing the designer to place collision wherever they want, in whatever way they desire.
An alternate route would be to add the illusion of collision by referencing the object and the target. When their positions coincide the specific collision values could be applied. This sounds like a long dull process, especially in testing, and should only be used in targeted, ranged attacks.
Saying that, the ranged attacks could be used with a projectile with a collision box. Locating the targets world transform and projecting the asset to intersect with a line trace. This is apparent in many games, like bullets from a gun, a fireball attack, anything that is cast from one character to another. As long as the target has collision the projectiles hit will register. This method also enables the targets ability to avoid the attack, given enough reaction time, depending on the cast distance.
Problem
Even though my attacks fired sometimes, after testing, I got some warnings always relating to the animation blueprints. I did some research and found out that to enable the notify’s the cast to node that fed the event reference should be done for every one. Not doing so would cause problems. Especially if the notify connected to the original cast to node wasn’t fired as part of the chain. This meant I would either need to create the whole cast to string for every notify, or I needed to find an event that would allow me to create the string once, then run every other notify from it, lessening the cost of data read time (this is not that important for my small level but would be costly in a large game. I want to create good habits early on).
The original string is below. Although it is efficient it could be costly in larger games:
I spoke to one of my peers and he informed me of an event that would suit, that was the “Animation Blueprint Initialize Animation”, perfect. This was already in use as a check for my character attacking. All I needed was a way to utilise the event and attach that to every other notify for them to work. The discussion, with my peer, revealed this answer too. Create a variable (player reference), insert it into the original string, then attach a “get” reference to each event reference attached to the notify.
After testing there were no more warnings.
Added Character Movement
Now we made amendments to the character movement speed. Adding a couple of conditions before moving: If my character is attacking, dodging, switching, or has their ult active, don’t move. If my character is alive, do move. This shows the control a character needs when creating a game. Controlling their movements to mimic reality as much as possible.
Next the mouse input was updated. If two of the conditions are active axis rotation is halved. In effect slowing down the player movement on the mouse player camera. Heightening the intensity of battle.
Another small piece of realism.
Evaluation
These amendments to the character movement add a realism to the game.
The first negates the players movement while they are doing another task. In reality, lets say, when someone is getting something from a backpack they become less aware of their surroundings as they fumble for the item. This is reflected in this amendment, where the player is already engaged in an action, switching a weapon, or attacking. In these cases it would be impossible for a person to change their actions immediately, so they would take a hit ( a gamble is involved).
The second string also mimics this real life phenomenon. If a person is dodging while changing a weapon, their concentration will be diminished because of the two extra tasks involved.
I think this could be affected with a separate string. Each condition would have it’s own string, directly affecting the player movement (based on world transforms and a calculation for their movement speed while doing it. A secondary set of strings would also be required for multiple operations at the same time.
The problem with this line of thinking is the efficiency. The amount of strings required would be large and therefore bad for the games flow (each movement would need to be located and activated, possibly adding up to several calculations needing to be executed at the same time).
At this point I added the visibility of my player characters on screen stats via the UI.
Problem
After completing the blueprint setup my damage transfers still did not work either way. After talking with a fellow student they advised me to target the character directly.
At first this appeared to work but after a bit of testing it only worked on the close ranged attacks. Also whenever my NPC fired their ultimate attacks a huge portion of my characters health would disappear, then reappear on the second cast of the NPC ultimate. Something was wrong.
I changed the damage transfer on my player character, cutting out the energy check for simplicity.
My character received damage from short ranged attacks.
I played around with the direct health subtraction for a while but nothing seemed to work. In an act of desperation I referred back to the original blueprint plans and spliced the two.
Referring to the cast to player, I changed the NPC health set node to an apply damage node (this is what the blueprint is primarily set up for). Attaching a random damage output. Hey presto, it worked. I applied it to all my ranged attacks and all damage transferred to my player character successfully.
Lock on Toggle
Next is an ability for the controllable player to lock on to the enemy.
After clicking the toggle key get the actor, for every loop. Lock on (function in a interface), thisd attaches to a toggle in a gate. The gate itself is activated constantly by a timeline but not in a conventional way. The timeline is reset every fifth of a second, on a loop,
Now it is essential to get both the character and the NPC locations, for the toggle to work.
Getting the controller (direct player character reference) and its rotation (so we can face the NPC when toggled).
The NPC location is sent to the players view, in this case the follow camera and get it’s location. The NPC is found via a variable in the game instance called “Boss Location”. Both of these pass through a “Find Look at Rotation (obviously), then into a “Rinterp to” (rotates to target). The raotation is broken to access the z axis, this turs the character to the locked on target. For the x and y rotational data, this is taken from the gotten controller rotation and broken down. The x, y, and z data is the compiled in a make rotator, then set in a “Set control rotation”. Now my player can look at a locked on target.
Now I need something to look at, namely my NPC. Thankfully the string is much simpler. I also needed a marker to signify my toggle lock on, I made that first.
Starting with an event (lock on) from the interface. This passed through a flip flop (toggle) to two set hidden in games. Both referenced the lock on cone, one set on the other off.
With that done I now needed to send the NPC location information to the lock on activation string. Via a function, created in the NPC event graph. Referencing the game instance for the boss location I accessed it’s world location via it’s mesh.
Happy with that I tested.
For some reason every other toggle found my player looking at something, not the NPC. I spent hours checking the codes but all seemed okay.
Then, after speaking to a peer, they pointed out that the player was looking at world position 0 on all axis. This is the default setting for my boss location variable and also centre of my arena. Turns out I had not referenced this function in the NPC event graph.
I attached it to my begin play, event, node. This solved the problem.
Dodge
With a reference to being alive and stopping the players energy regen before it can fire. Next a reference to whether the character is attacking or switching, this will also inhibit it’s firing.
There are two dodges, one stationary ( resulting in a backflip), one sideways (can only be activated after a velocity, vector, check. Both initiate from a disable input, and contain both launch and upward force values and both trigger their own montages. Ending with a retriggerable delay (so it can be used again), finally re-enabling the input.
Evaluation
The player lock on is not an essential feature for a game. It is a nice addition though.
The alternate use of the timeline for a recurring check that enables a toggle is an interesting use. Up to now the timeline has been used mainly for door opening, and closing, and other such activities.
My ability to read the string is growing and I am starting to understand the sentence a string makes. Giving an insight into how nodes follow on from each other and my being able to predict some nodes by the abilities of the preceding.
The annoying part of the process is my continuing ability to overlook simple actions that complete a procedure. In the case of referencing the NPC’s “Send Location” function in the NPC event graph, for the procedures enablement. But it is a learning curve and I am beginning to realise these small oversights more frequently and at a quicker pace.
The dodge action was interesting, especially as two different dodges were available from the same string. This means multiple dodges can be applied to one string, each with their own condition for firing.
NPC Attacks
Arena Setup
The first stage is to define an npc navigation boundary (nav mesh bounds volume), this tells the npc the limit to his movements, confining him to a particular area. The nav mesh bounds volume is only visible in the editor viewport and is a quadrilateral that can be stretched to suit the designers boundary limits.
With their boundary built it is time to effect the npc directly.
In their components you can add a “Pawn sensing” function. This mimics the npc’s ability to see and hear and can be manipulated through the AI tab.
Notice how the hearing (spheres) and the vision (decagon & cone) alter size or shape depending on their values in the details panel, AI tab. One drawback with this type of npc AI is that if they don’t see you they don’t look.
Another option is for the npc to constantly search for the player.
Now the npc is searching they must have a distance when they actually see an enemy. The calculation is to take the location of another player from the location of the npc. If the npc is within those bounds they see you. The range will be a length.
The secondary calculations are, from the bottom up, close range (this is the lowest distance), the next is the furthest distance (long range), and the top two are between the two (mid range). If any of these are triggered they are set to a print string with the coordinating range, which will let us know in game. I tested it, the npc saw me at every range.
For the npc to recognise they have seen us a string must be written for this the new function must be called.
A new custom event starts the string and also gives a reference to go on the end of the npc find player chain.
Now we have ranges for attacks we need to add the npc attacks for those ranges. Three custom events, named after the ranges, will be the trigger. Each will have a varied choice of attacks, long will have 1 (, mid will have 2, and close range will have 3 . To sort this out a random intiger in range will be used to denote this. This passes through a switch (on int), this will be the random selector.
A check must be made to see if our NPC is in combat or not before any of the attack commands will fire. This is done by simply adding an if? (branch) with the in combat boolean as the condition. Adding this to the player distance string as the first command.
Then as a check for our attacks.
For our attacks to play we need to play them, with a “play anim montage” node (handy!), creating a variable, object type, anim montage.
The NPC anim montage variable is also used to call the individual montages created from the available animations. Connecting them into the play anim montage node. Now a delay is added, to stop overlapping animations, with an set in combat at the end to close the chain, this on is set to false.
With the attacks done for now it is time to add health to our NPC. Simply done by creating a float variable, adding it to the initialise chain, adding a value in it’s window.
Problem
At this point I noticed my NPC was not playing animations. I tried rewriting the string for animation montages but nothing changed. I then tried animation montages that were part of the paragon characters setup, no change.
I added a print string to see if the command was firing after the “play anim montage” node, it was.
As you can see the hit notify is displayed, also the range notify is printed. Something is stopping my montage playing.
I did some research and found that I needed a node in the animation graph. “Slot ‘Default ‘ Slot”, corresponds to a default group any animation montage can be added to. They appear to give a good selection for a more effective animation technique. Selecting the default slot for each on my animation montages gave me an easy fix to getting animations on my npc.
Having remedied the animation problem I now noticed that the animations were not firing for their full duration. This was noticeable in the short sequences, only the longer. It was as if the animation was being cut short by the string re-firing over it.
I changed the longer animations to shorter ones, this worked better. Though I will find out why the longer ones did not work properly at a later date. Here is my NPC attack chain now.
NPC setup, continued
To display this, a widget is required, creating it in the same way as the playable character, adding a progress bar (for the health visual) and text (for the name).
When done a bind needs creating for the boss’s health. This again is the same as the player blueprint. Creating a health variable then a calculation for that health to be displayed in the progress bar.
Back to the find player string, we need to add the in combat condition to the npc search. If the npc is in combat, stop moving, if not move to find player.
Also add the find player reference to the end of the npc anim montage string, in order for the npc to resume a search if the player is not found again.
To stop the npc attacking instead of searching we can add a variable that will make them search or attack.
The option is the find player or long range attack, the decision is the 50/50 coin toss the random integer casts, governed by the equal to 0.
To make sure the npc faces the player a new custom event is required. Finding the rotation you need a “Find look at rotation” node. The input has two pins start and target. So to have the npc facing the player you need to take the player location (target) and the npc location (start). This will align the npc to the players location. Adding this to the end of the anim montage system will enable this in game.
Now to enable the npc on a trigger box overlap.
First amend the initialise string, dropping the event begin play for a custom node entitled “activate_NPC”.
Then drop a trigger box in the level and open the level blueprint. Create a string saying when another actor (player) overlaps the trigger activate the npc.
At this point I added a set visibility to the boss’s name and health bar, so the viewport would update with this information.
Now set up collision on the npc. It is different from the player collision set up. This applies to all weapons, in my npc’s case he has a staff as well as a foot attack.
Followed by the collision on and off in the character blueprint. Print strings have been added for testing later.
For their collision to mean anything animation notifies (activation and deactivation) need to be created and added at the optimum time in the animation sequence. Ensuring a correct and easily identifiable name is given in each case.
At this point I noticed my npc was not running upon testing. I added a blend space. Selecting a suitable idle, walk, and run.
To animate I created a new state machine,
with some simple animations, the conditions were all a check to see if the npc was in the air.
Now my npc actually ran across the scene instead of gliding.
Moving back to the npc attacks , we need them to register and the best way is through collision. When their collision box (staff or foot) overlaps the players core a hit will register. To begin with we need to set up the npc collision output.
Referencing this in the player blueprint.
Once checked and done expand the npc overlap hit chain to first check it is hitting the player, then trigger the player hit events just created.
Looking ahead this could be used for multiple hits across a variety of instigators.
Moving on it is time to assign damage to each individual attack, using float variables.
The variables are left blank, otherwise all damage dealt would be the same. Instead a separate damage input can be assigned to each attack.
NPC Damage Received
Starting with an any damage event a condition is added, if the damage is caused by another player set the damage to the game instance “Do damage value” variable. An armour roll is calculated separately. The damage is divided by the armour value and sent to the “Do damage value”.
If the value of the NPC’s health reaches 0, or less, then the player is dead.
If not, and the damage is above 30 then the NPC fliches, via a play montage. If the players health is equal to, or less than 0 after the flinch then the NPC dies.
This is all compiled in one string.
Evaluation
This multiple action string showed me how to compile a series of events, one event with two possible outcomes.
More and more blueprinting is making sense. From the recognition that damage is caused by any other to the armour value deduction. It appears that the bulk of calculations are algebraic. Meaning that all I need to do to find a value is to see the two factors as an x and y input, giving me a new value of z. Who says algebra is not useful after school?
Projectile Attacks
Because a fighting game reflects real life all attacks cannot be melee, some must be ranged, even if it a thrown rock. So my npc needs some of these to fill out their attack chain.
Starting with the creation of a projectile.
I used a simple sphere and added a material from the aurora set.
Next I added a collision sphere, for it to register a hit. When done I placed it in the npc body to give the illusion he had cast it, I can delay its visibility later, giving a further illusion that he cast it from his staff.
Adding a rotation to the project is a personal choice, in some cases this could add a nice effect to the graphic interface, making it more pleasing to the eye.
These effects have been created to add to the following debuffs for a nice visual. I will add them when everything else is working.
Speed Debuff
Adding a debuff on the npc would create a mechanism that could be adapted to fit into their attack chain. Creating a variable that can be fired at a set amount, balancing the fight to one that would be close. If the damage output is weaker in a fight then the debuff will aid in the balance overall. A speed debuff would slow the player, limiting their damage output or adding more attacks to the npc. In this case two will be apllied to the npc set, slow and burn.
Starting with the speed debuff. Firstly I needed a blueprint interface. The interface is a collection of one or more functions that can be used across multiple objects, Allowing them to share and send data to each other. In spite of this they, however, cannot add new variables, edit graphs, or add components. It is found in the content browser, blueprints, blueprint interface.
When opened a familiar graph is present. In the top right corner, my blueprint panel, has an option to add new functions. I added two, a speed debuff and a burn debuff.
Now the interface needs to be added to each player it effects, both casting and receiving. This is done in the respective character blueprints via Class Settings, on the main tool bar.
Simply click on the add button in the interface panel and select the appropriate interface.
Now it can effect both players, depending on which side of the debuff they are. Because it is both cast and received a string activating it must be added to each of the character blueprints.
The cast is the simpler of the two (avtivating the “speed debuff” through the get player character).
The affected character, my player, is a little trickier.
Starting with a called speed debuff event, from the interface. Our condition is the ability to cast an ultimate attack, so one normal attack upwards. The top two walking speeds are the slower, debuffed ones, the lower two are normal walk and run speeds for the character. The re-triggerable delay is the same as a delay but can be re triggered with a, settable, time, in this case that is the random float in range (set between 7 and 14 seconds).
Finally assign this event to an attack in the protagonists blueprint (NPC, in my case).
Fire debuff
Having added the interface to the player character I can now add the fire debuff.
This is created as an actor blueprint. Adding an arrow, for the direction, a trigger box, to cast on overlap, and a particle effect, in this case the P_Fire effect from the starter content folder in the content browser.
Altering the triggers setup to a custom setup.
In the blueprints event graph we set up the conditions.
Upon overlap it fires once, if the condition that it is the player character, is met. It then checks the second condition to fire on zero, from a choice of one and zero. This give it a fifty percent chance of hitting. The final node is a reference to the burn debuff function in the npc interface.
For this to work the trigger box must be active, so a second string is required to activate it.
On begin play is where the string begins. After a second delay the fire is set to hidden, the trigger is set enabled with a life of six seconds, after which the actor is destroyed. This allows us to fire the debuff more than once, with every subsequent action being the same as the first.
As both of these debuffs are in the mid range attacks it becomes the players responsibility to recognise this and prevent it as much as possible.
If the cast is to work it must be present in the npc character blueprint.
A custom evnent is used with an appropriate name, in this case “CastFire”. The actor is then spawned, with a reference to the fire debuff blueprint in the class dropdown. The spawn transform is the player character, so a reference to this is required. To know where they are requires a get actor location, which passes through a make transform, making the transform (player location, rotation, and scale) the player character.
Now the npc can cast a debuff at our player character a recieving point on the player is required. This is done with a capsule collision (Burning) that is assigned to the player mesh.
And added to a socket, in this case on the spine.
Now there is a target point for the debuff to effect a string is required to actuate it. To do so we must reference the npc interface again.
Making an event burn debuff node. The particle effect needs to be displayed with a spawn emitter node, the template is the P_Fire particle effect, attaching it to the new capsule component, also the location type has been changed to snap to target. This still allows me to add a visual effect of casting some sort of fireball, a delay can be added to the front of this string (after the initiation) allowing the visuals to take place first. Next is the effects lifespan, which is delayed between 3 and 6 seconds, before being destroyed.
For the debuff to affect the player character it must be referenced in their blueprint.
Problem
When casting the spinning blade ultimate attack the camera kept transitioning from the third person camera, to the player, and back out, also the player was trapped by the attack.
I set the blades collision, in the blueprint, to no collision. The changed all the capsules to a custom collision where the collision was ignored by both the visibility and the camera. This fixed both problems. The only thing that bothered me was the ultimate attack stayed in place after the player had moved. This is something I will look into when I have more time.
Spawn Projectiles from Ranged Attacks
For a projectile to spawn I must first have a projectile to spawn. In this case I am using my Tri Flame NPC attack to demonstrate.
Reading backwards in the string: take the BP actor amd get it’s world location. Next add it’s target, in this case it is the player character and get it’s the actor’s location. Now find and look at their rotation. Make a transform for the actor to recognise this calculation. Spawn the actor and assign it an event (custom).
The final product looked like this:
Evaluation
Another pocket process that can be used for the same reason in a multitude of ways.
After creating this action I added it to my NPC debuff attacks, so their is a visual representation when they happen.
I suppose I could have built this in the actor’s BP but the NPC event graph will do for now.
Extra’s
Background Music
I decided to add some music to my sequence. I decided to use some Japanese drum music to add some atmosphere.
I found a, free, suitable mp3 file online and converted it to the UE4 preference WAV file, via an online converter.
Simply drag the file in and start conversion. When done download the file, to a suitable folder.
Now head over to unreal, contents browser, starter content, audio.
Import the WAV file.
Now right click on it and create a cue (near the top).
Open the cue and save.
I placed play string in the character folder, on begin play.
But found the music didn’t start to play for about ten seconds. So I cast to my player, disabled controller input with a delay of nine seconds then enabled controller input again. After testing I found the music began roughly around the time my NPC came into view, if I ran straight at him immediately.
Main Menu
I created a new widget to display a simple menu, one with a screenshot of the arena, and two buttons.
Moving to the editor. On the begin button a simple task of creating three set visibility’s (one for each element in the menu, all referenced and set to collapsed, a set game paused ( I had foolishly created the game in the persistent level), and a set show mouse cursor (unchecked). I also created a quit game string.
Then I moved to the level blueprint and created an on begin play string. To which was added a create widget with add to viewport,three set visibility’s (all visible and referenced to the same elements), a set game paused (checked, as I said I was in the game already), and a checked set show mouse cursor.
Here is a video of the splash:
My Blueprint Factory 