Idea Generation for Computer Games - Summary

To summarise this unit, I feel I have learned a lot about the implementation procedure for characters in video games, though there is still a lot more to learn however, through breaks and issues I have learned workarounds and actual fixes to issues.
Whilst this is a 3rd person perspective action game. a lot of the blueprinting processes I have learned will be transferable to other types of games.
I'm not going to pretend that everything I have done has properly sunk in yet however, as I am pretty sure I would not be able to replicate more than two thirds of the work I have achieved if I was sent away to do this again with no assistance from the internet, for I have run into many stumbling blocks along the way. I feel I would have absorbed more of the functionality going into the physical blueprints if I had a thorough understanding of multiple types of variables and other such elements within the engine but time, amongst other circumstances has simply not allowed me to expand as much as I would have liked.

From what I feel has sunk in on the other hand, I have a good standing on a level from which to build my knowledge of blueprinting, character implementation and game design as a whole and I am happy with the progress I have made throughout the unit.
With the assistance of various YouTube videos and the Unreal Forums, I feel have been able to somewhat competently produce and fix where appropriate, an implemented character, NPC and a moveset for each.

Going forward from this point, any issues outstanding within my character implementation, as small as they may be, will be assessed and dealt with as and when I have the time to apply to them, and I will at some point try and expand further, adding in many more enemies as was my original intention due to my overall project within the academic year in level design. I will also be looking at implementing gunplay further into the development process, adding in a cover and blindfire system, adding firearms and the player's own thrown projectiles.

Idea Generation for Computer Games - Changelog v1.01

Since finalising my current character implementation setup, I have been able to implement controller support as I had previously wished to do. I did not realise however, that it would be as simple as it actually turned out to be.
As I had a controller at my side giving me the ability to test my build right away on implementation of each new button input, this made the process a lot faster also.

The simplicity of the gamepad input lays in the events within blueprints, as with a very quick search for resource on the matter I found a completely referenced layout of a controller, using Unreal Engine 4 terminology.

Taking this into account, I set the button layout according to my current blueprint, making use of the fact that two inputs can be set simultaneously to the same piece of code. My allocated controller functionality was mapped as so;

- Standard Attack/Combo: Gamepad Face Button Left (X on Xbox controller)

- Special Attack: Gamepad Face Button Top (Y on Xbox controller)

- Dodge Roll: Gamepad Face Button Right (B on Xbox controller)
- Switch Weapon: Gamepad Left Shoulder (RB on Xbox Controller)
- Shield Mode: Gamepad Left Trigger (LT on Xbox controller)
- Slow walk: Gamepad Left Thumbstick (LS on Xbox Controller)

I purposely set aside two gamepad functions for other features I decided to add;

- Jump: Gamepad Face Button Bottom (A on Xbox controller)
- Auto Lock-On: Gamepad Right Thumbstick (RS on Xbox Controller)

-----------------------------------------------------------------------------------

Elaborating on the two button inputs which had been left vacant for features to be implemented, I have also added an auto aim/lock on feature, set on a toggle, and a jump.

Firstly, the jump is a very simple animation setup, set up in accordance with the setup in the base character blueprint.

I simple have the Gamepad Face Button Bottom and Space Bar input options set into a branch, which makes sure the played is not attacking, switching weapon or currently jumping. This branch, when read as false, communicates with the next branch, which is set to read whether or not the player is in Sword 1 or Sword 2 mode, this then triggers the difference in animation, as both stances have their own jump animation.

The animations themselves are set simple with "set att montage" nodes and a 'play anim montage' node.

I have no current means to test the functionality of this within my level in terms of geometry, but I will be looking to perform a quick test and and when I get a moment, to see whether or not this jump allows me to mount higher objects. I would ultimately have liked a higher jump animation, but the animation in use is the one within the specific set of animations, I would add an upward launch value in but feel the jump would then look completely unrealistic.

-----------------------------------------------------------------------------------

Alterations have been made to the core blueprinting process of my NPC, which have now allowed my NPC to die successfully without firing off other attacks prior to the actor being destroyed, I have also allowed my character to die and respawn just outside of the battle area.

As the fix was slightly confusing I consulted my peers for any opinions and knowledge they may have been able to lend on the subject and I have subsequently fixed the animations to fire appropriately, making the NPC die upon hitting 0 health.

There still appears to be a very minor issues with collision components casting damage, but I am happy with having fixed what was more of a core problem.

This was a pressing issue which I am thankful I have been able to rectify before my deadline, as the the NPC was dying, but not dying properly, as it could still fire off attacks.

I will look to fix the collision issues also, but right now they do not appear to unbalance the game too much, the boss fight has a certain tier of difficulty and can be beaten, but can also beat you if given the chance.

-----------------------------------------------------------------------------------

The final piece I have added to this point is a lock-on feature, set on the Right Stick Button and Tab, on a controller and Keyboard respectively.

To set the camera lock, I needed to implement a timeline and gate into my blueprint, the Timeline set to enter the gate, and the toggle occupied by a series of 'get all actors of class' and 'lock on' nodes.

The gate is then followed by a cast to game instance followed by a 'Set Control Rotation' node which contains all of the appropriate rotational information necessary on every axis.

Any Roll/Pitch and Yaw information which is applied through the core camera sequence is then plugged into the new rotation socket on the eventual set control rotation node.

The final product of the lock on is set to a toggle so that when I click in the right stick once on the controller or hit tab once on the keyboard the camera will lock to the NPC, with another press being required to remove the lock and return the camera to free movement.

The structure of the blueprint can be seen below;

Idea Generation for Computer Games - Shield Setup.

For added functionality, which could ultimately be utilised as a blocking mechanism to void damage later on, I have implemented a shield stance, in line with the riot shield mesh I originally created.
For this, I needed to create a multi directional blendspace and add in each of the blocking strafe animations necessary. After linking the actual functionality in terms of how it would be used into the character blueprint, I needed to assign it correctly in the animation blueprint, and this presented a problem.

A prior error which had arisen for both me and my peers arose again, when changing weapons, after a single attack with the secondary weapon, the character would automatically switch back to the primary sword and shield combo.
Whilst the shield mode was meant to be given its own state machine and its own slot, referred to as 'waist', the animations did not sync correctly at all, and resulted in the character being able to move backward and forward correctly, but strafing both left and right with only the right strafe leg movement in use, giving the effect that the character was walking forwards, whilst moving backwards.

This issue was fixed by adding the shield mode into the initial motion state machine, and altering the animations in use within the blendspace, as the initial guideline for the blendspace simply did not work with the suggested animations.

After the animations were added and the shield mode connected correctly within the state machine, and after a simple hook up in the character blueprint, the shield was able to be visibly raised when not attacking. This animation in question  was hooked up to the right mouse button on the condition that no attacks were in progress, otherwise a special attack would be linked in instead.

Below is a shot of my motion state machine with the workaround fitted in, and a shot of my blendspace once fixed;

I had at this point, implemented everything I had been provided resource on, with only two features missing, this is a damage buffer for whilst the shield is raised, and an ultimate attack.

I am quite happy with where I am but I will be continuing to make tweaks as and when I get time amongst other work prior to my deadline for this unit.

I will almost certainly be blueprinting in a damage buffer whilst the shield is raised, to either stop damage being taken completely or minimise the damage received from projectiles only. This will be a design decision made on the basis that my NPC is a large mutant/alien and could easily breach the defences of a small shield with melee attacks.

I have made a design decision to not add an ultimate attack at this point in time as I do not think the ultimate attack variants I have been shown are either suited to my character, or appropriate for my theme. This is based on my character being a humanoid Bounty Hunter, with no superpowers to make such ultimate attacks work, only heart, determination and the will to succeed driving him onward to capture his targets.

The main features I am looking to implement right now, are a jumping animation and controller support. The jumping animations are not in any way necessary taking my level into account as every surface is mountable already so jumps are not really a requirement. I am looking to add the controller support so that my level can be played not only with a keyboard and mouse, but with a controller also. To test this functionality, I will be using both the Wired Xbox 360 Controller for Windows, but the Wireless Xbox One Controller for Windows also, dependent on my location and the operating system I have at my disposal.

Any further implementations I make from this point onward will be detailed in changelogs.

Idea Generation for Computer Games - Rage Meter

In addition to the health and energy bars within the UI, I have created a rage bar (Note the final product is not currently in use due to a design decision). This bar is set up somewhat like the health bar, however when attacks hit the player, rage is gained as opposed to lost.
Another difference between the two is that the bar fills from a central position, and not from the left hand side.

The damage dealing nodes within the script have a woven in "Get Rage" node, which call to a custom event that controls the Rage. The custom event itself decides how much damage is taken, in comparison to how much rage is received.

Below is a shot of a section of code, from the character blueprint, referring to the 'get rage' node and custom event;

The UI was all fairly straight forward apart from one minor hitch in the process that I should have noticed was wrongly placed sooner than I actually did, other than this though, the widget setup was simple and I had no other problems with the setup.

Idea Generation for Computer Games - Health and Energy setup.

The next pieces of the puzzle which needed to be made functional were the health and energy bars, represented in a HUD Widget using progress bars.

This was set up in exactly the same way as the widget which was applied to the NPC character implemented earlier in the overall procedure, only with more elements.
I added two progress bars and created progress bindings to allow the progress to be reflected based on a series of blueprints.
Once the levels of health and energy had been determined, I implemented the script within the character blueprint to allow these to interact with the respective 'min dmg' and 'max dmg' values which had been previously implemented into my system within a damage application string.

Once functional, I turned my attention to the energy depletion, and set the attacks to deplete my characters energy as previously seen, this further development however added some restrictions and varied amounts of energy required for specific moves.
Within each of my special attacks I simply set two extra nodes, one of which was a "Set energy' node attached to a minus float, and the other was a branch instructing the engine that if my characters energy was under a specific amount, any special moves could not be triggered. These branches made use of '>=' floats as I have used before in things like my distance check.

Below is a shot of a section of my blueprinting, showing that the special attack string can only fire if the energy levels meet the requirements, also shown is the dependency on certain moves within a primary combo to be active for the special attack to trigger;

Idea Generation for Computer Games - Energy Regeneration.

To implement a proper health and energy setup into my character, I needed to add in another set of functions, the first of which was designated to the restoration of energy following special combo attacks which use up energy.
Within the function itself, the maximum energy and amount restored in each chunk are set, this is then referred to by a custom event in the Character blueprint which sets the energy restoration speed, this is the speed at which the set amount of health is restored.

A stop on the regeneration is then implemented within the character blueprint, via a branch set so that the regen cannot occur whilst the player is attacking.

Below is a short clip of my energy bar setup, showing the restorative effect upon the use of a special attack through the heads up display in the lower left corner (The creation of which is elaborated on in the following post.);

Idea Generation for Computer Games - NPC implementation: Speed Debuff

Another effect I have chosen to use within my NPC setup is a speed debuff, cast directly at the player.

This is created through a Blueprint Interface, within the blueprint a speed debuff function is set and applied in blueprint class settings.

With the blueprint set appropriately, the NPC character blueprint can be rigged to cast speed reduction, this would be in the form of a call to a custom event, in this case named 'cast_speed_reduction', this in turn is linked to a message node, utilising the Speed Debuff within the NPC Debuffs blueprint interface.

Switching from the NPC to the character blueprint, this is also linked in turn to the NPC debuffs, casting a straight reduction in speed reflected in character movement in game. This is set using a simple branch, with the condition being set to Sword 2 mode, therefore allowing two different speed reductions.

Once the duration of the debuff has passed, the player will return to the respective normal running speed for the weapon they are carrying.

Below is a snippet of the blueprinting setup used to make the speed debuff function;

Having completed the movement and attack setup of my NPC, I feel as though I have learned some more, albeit not as much as I learned through the creation of my own playable character. This is only down to the fact that the character attacking sequences are somewhat still fresh in memory, and I am sure I'll still benefit from the knowledge of setting up NPC attacks.

On reflection I feel I have learned a lot more vital information about pawn sensing, debuffs and projectiles, this is all information which will be transferable, along with everything I have learned into any projects going forward from this point on.

Idea Generation for Computer Games - NPC implementation: Projectiles.

As an additional attack, I have incorporated a projectile which is thrown as one of the long range NPC attacks. This consisted of creating a static mesh to be imported and made into a blueprint itself.

With again, an AnimNotify set inside the respective animation I had chosen to use for the projectile attack, I again referenced it through from the animation blueprint into the NPC character blueprint.

The reference is made through to a Custom Event which fires a variety of nodes which set the direction in which the rock is hurled (directly toward the player) and toggles the visibility of the rock, as by default the projectile is visible within the NPC setup.

The projectile itself is set to disappear on impact once thrown, leaving behind an explosion and after full damage setup functionality, a portion of health removed from the player's health bar. taking the projectile further, I may set the damage to not be cast provided the player has their shield raised, this is however, further work and as it stands I am happy with the projectile causing damage as standard.

Below is a screen grab taken from a portion of the blueprint used to implement the projectile, the damage, the explosion and the destruction of the actor;

Idea Generation for Computer Games - NPC implementation: Collision Detection.

To apply collision values and with that, damage, I needed to bring in three more components to the character blueprint, these were all collision capsules, placed on the hands and the right foot of my NPC.

Within the attack animations I had made into Animation Montages, I needed to implement AnimNotifys for enabling and disabling the collision on each of these capsules, with these AnimNotifys set, these were, in the exact same way as linked with the playable character, linked to a custom event through the animation blueprint, these custom events, located in the character blueprint, were linked to "set collision enabled" nodes, with each of the new collision capsules being given their own set of enable and disable nodes to refer to.

To make sure that the collision was registering on overlap with the character, a series of 'cast to character' nodes were added, which followed with a reference to more custom events, which were simply linked to print strings to show that the collision was happening, ready to have damage functionality implemented in later.

Below is a screen grab of one portion of the setup, showing the collision capsules being both enabled and disabled;

Idea Generation for Computer Games - NPC implementation: NPC Activation.

This is one of the very simple features within the implementation process, the activation of the actual NPC itself via a trigger box within the level.
This basically consists of two elements, the trigger box itself, and a custom event named Activate NPC. A begin overlap event is assigned to the trigger volume, and is built so that only the playable character can trigger the overlap,  this then fires through to the initialise chain to activate the NPC, telling the engine that the NPC is alive and can begin moving and attacking when the trigger volume is breached.

Below is a screen grab of the custom event to which the overlap is eventually linked, showing that the NPC is classed as alive;

Idea Generation for Computer Games - NPC implementation: Flow Control.

After making the NPC function as far as firing attacks and following the player were concerned, there were a couple of tweaks that needed to be added to the blueprint to round off the movement and tracking specifically.

The main specific alteration which needed adding at this point was the 'Face Character' setup, which was constructed to make the NPC face the character if it ever loses track of the pawn. This is a simple setup, fired by a custom event which is then linked into the earlier tracking procedures.

The custom event is linked to a standard 'Set actor rotation' node with a 'Find look at rotation' linked directly to the player character through a 'GetActorLocation' node.

This did present me with some more problems in the sense that sometimes the NPC would end up angling inappropriately in effort to face the player. This resulted in the NPC tipping forward or backward often, which looked wrong.

This in itself reruired a fix, which again was only a couple of nodes worth of work.

The blueprint solution for both the initial problem, and the additional problem which arose from that solution, can be seen below;

Idea Generation for Computer Games - NPC implementation: Health System Preparation.

To begin setting up the NPC health, another float variable must be added to the blueprinting setup.
The float, titled Health was then linked to a widget which was set to display the boss name and health on screen upon triggering activation of the boss.
Within the widget is a progress bar, which has the percentage bound to a simple piece of code, in which the amount of health is reflected in the bar.

The colour of the bar can also be modified to change colour as the percentage decreases and/or increases, this is an added effect I have looked to add but it did not work as intended in my project, as the colour did not change, I will be looking to implement this again at a later date for extra visual emphasis.

Below the health bar can be seen in widget form, with the binding for the percentage and the colour set accordingly;

Idea Generation for Computer Games - NPC implementation: Attack Setup.

After the distance detection system had been set up successfully, I began to implement a similar system as I had previously done with the playable character, from a perspective at which I was creating multiple Anim Montages and applying various Anim Notify actions within them.

The difference within the setup of the NPC as opposed to the character was that I had to choose appropriate moves based on the distance check, these changed somewhat through the development process to allow for other effects and elements to be added into the NPC.
As the NPC's moveset consisted of singular moves, there was no setup for combos, as this may have tipped the game balance somewhat negatively as later implemented damage values were added in and the combos may have started to amount to too much damage being transferred to the player.

After the Anim Montages had been created, they needed to be set into a similarly constructed blueprint as my character attacks, and needed to make use of a new boolean variable called "in combat".
This would in turn stop the NPC from firing off attack animations whilst it is not in combat, or whilst it cannot physically see the player and actively trace its location.

Below is a small section of blueprint post-modification (to allow for debuff moves and projectiles) to highlight the above explanation, essentially showing that the NPC is in combat, and able to fire off one of two animations as a result of being at the specific range;

Idea Generation for Computer Games - NPC implementation: Attack distance check.

The next step in configuring the NPC to follow my player, was to construct a blueprint so that the AI could competently tell the distance it was from the player.
This needed a Function to be created within the character blueprint, from here a set of distance based branch decisions were placed, besed on the length of the vector drawn between the NPC and my player character.
For example, using a '<=' or '>=' float within the blueprint editor allows us to set a condition based on whether or not a distance is more than or equal to a specific number, and also less than or equal to a specific value.
Based on these values, Long, Mid and Close range were set and represented on screen in play in form of a print string, which would fire each "Long Range", "Mid Range" and "Close Range" call  when the AI breaches the vector distance based condition plugged into the branches to determine at which range the play currently stands.

Below is a small snippet of my blueprint, showing the basic theory behind the work, in which if the distance is less than or equal to 999 units between the AI and the player, the branch then fires true, setting the range to close range and firing the appropriate print string to be displayed on screen.

Idea Generation for Computer Games - NPC implementation: Foundations and Pawn Sensing.

To begin the NPC implementation within my work, I needed to first source another set of animations, as my NPC was planned to be humanoid, yet an alien of some sort.
I sourced a character mesh and animation set and imported them directly into a new folder within my file structure, followed by the creation of a blendspace as I did with my main character.

With this set up, I created an animation blueprint tied to the NPC's character blueprint and placed a NavMesh Bounds Volume ready to be utilised by the AI in engine.

To make the NPC track the character, a pair of different pawn sensing setups were implemented.
The first was set up by adding a pawn sensing component into the NPC character blueprint itself, which allowed me to set a field of view within which the NPC would be able to trace my character.
With the cone set appropriately, the blueprinting was set up fairly simply using an "AI MoveTo" node, linked into a few component references and a 'get player character' node.

The second iteration of the AI moveTo setup was configured slightly differently, in the sense that when the AI could not see the player, it would fire off a node to a custom event called Find Player, this would set the rotation to face the player character and the AI would then begin its approach again toward the player.

Below is a screen grab of both of a portion of both pawn sensing setups, the first not being currently in use, has been disconnected;

Idea Generation for Computer Games - Character-based extras: Dodge Roll

The final addition to my character before moving onto the implementation of an AI character was a diving roll, with the idea being to evade enemy attacks.
The diving roll animation was again sourced from Mixamo as it is separate to the previously downloaded animations, imported into Unreal and made into an Animation Montage. Within the montage, a launch and reset AnimNotify were implemented to allow the character to forcibly move as the roll is performed.

The diving roll in terms of blueprinting was implemented similarly to the the actual launch functionality, with a simple boolean being put in place prior to the launch taking effect, making sure that the character is not attacking or switching weapons, as this would void the animation being able to play.
There was an option to add a backward roll also, but I only implemented a forward roll as I feel there is no need for a backward roll, as it looks awkward and could not be performed in a battle with the animation provided.

My dodge roll can be seen functioning below;

At this point in the implementation process, I feel I had learned a lot, some more simple things and some not so simple, some of the implementations confused me at first but I was able to work through the confusion and produce a somewhat functioning character for a game, with an NPC yet to be implemented, and damage to yet be configured across characters.

Idea Generation for Computer Games - Character-based extras: FOV Zoom

The third of the four added functions after the general attack setup was a Field of View zoom, this was set up in the exact same way as before, except the custom event contains a timeline, which zooms the camera in and out again.
This custom event is fired just like the other features, making use of an AnimNotify, a call node and the Custom Event mentioned previously.
As this is fully operated through the custom event itself, it does not need an extra node within the attack setup to be implemented.

The FOV zoom has been implemented on one of my attacks, as I do not feel it is necessary to apply more camera movement to more of my attacks, taking into account the Camera shake function also.
The one attack it is implemented on can be seen below;

Idea Generation for Computer Games - Character-based extras: Cam Shake.

The second in the group of extras which I added to the character blueprinting system was a shake applied to the camera.
This was again managed through an AnimNotify, call node and custom event within the animation and character blueprints, with the exception being that it required its own blueprint to function as intended, this was a simple implementation of a "CameraShake" blueprint.
The values are edited on Ocscillation, Pitch, Yaw and Roll amplitude and frequency then set through a 'client play camera shake' node within the character blueprint.
With the appropriate values set and the right nodes in the right places, all that remains is for the shake value to be set wherever the user requires the camera to shake.
For this specific character the shake was applied into the attack blueprinting alongside the (currently not in use) launch force nodes. As the AnimNotifys were set in the places I required them, on some strikes within some of my attacks the camera will shake as the character makes contact with the implemented enemy.

Some camera shakes can be seen in my attacks below;

Idea Generation for Computer Games - Character-based extras: Launcher.

As extra work built on top of the functional attacks used thus far on my character, I implemented some extra features, some of which are in use, some are not.

The first of which is a launch feature, this is set up using character based vectors inside of a custom event, both a forward and up vector are used to apply a launching force to the mesh.
This, as before with the attacks, is fired at a specific time within animations using an AnimNotify, which is then linked into the animation blueprint and connected to a call node to the appropriate custom event.
This also makes use of nodes like 'Ground Friction' and necessary character movement references.

Idea Generation for Computer Games - Adding special moves.

The final addition to my physical attack setup, without delving into added effects, was special attacks.

It was already decided that the functionality of the special attacks was to be allocated to the input from the right mouse button (RMB), as such the process only needed to be blueprinted into the schematics.
The beginning of the process was much the same as the standard attack combo, in that the selected animations were used to create anim montages and set to the body slot within the animation blueprint so that they would fire as intended.
When woven into the blueprint system, the special attacks were made to be dependent on the stage at which the standard combo stood, for example, the character would use a different follow up attack for each of the right mouse button presses after each of the first, second and third attacks in my 'sword and shield' combo.
The exact same is implemented into the secondary weapon, with the exception of there being a different amount of standard attacks in the combo, affecting the amount of special attacks needing to be incorporated into the blueprint.

These special attacks were all later set up to have a negative effect on the stamina bar, which will be detailed in a later blog post.

A few examples of the special attacks as the game currently stands (with Stamina/Energy functionality in place) can be seen below;

Idea Generation for Computer Games - Combo preparation and functionality.

To begin the attacking functionality, I chose three attack animations from the sword and shield animation set, these were to take main stage as the primary weapon combo. These were set up inside the character blueprint so in a manner that would trigger the the moves in sequence on the press of a button.

The three chosen combo attacks were used to create Animation Montages and the slot was set to Body, which was pre-determined by the animation blueprint.
Within the animation montages a group of AnimNotifys were set to give the engine a precise moment in which the combo can physically continue, this means that at a specific point within each of the animations, the AnimNotify will fire, giving the user a window in which to press the attack button again, triggering the next move in the combo.
In addition to this, there is a combo reset feature linked into the animation blueprint alongside the combo start node, this is added to allow the combo to reset itself, meaning the player can re-trigger the combo whether successfully completed or not.
In this case, the left mouse button (LMB) was designated as the Primary attack button, with this allocation in place I could begin to make the combo function in-game.

The combo was then mirrored with similar values, and identical AnimNotifys, applied to the secondary weapon, which in my character's case, is a Sledgehammer.
Both combos can be seen below functioning in-game via screen capture;

Idea Generation for Computer Games - Switching Weapons: Booleans, Events and AnimNotifys.

To physically make the switching of the weapons function, a group of booleans, events and anim notifys were needed. All of the aforementioned nodes items are important to create a cross blueprint communication, allowing the AnimNotifys to be cast across to the animation blueprint's event graph.

These ultimately act to show a visible representation of whether the character is in 'Sword 1 Mode' or 'Sword 2 Mode', by switching the visibility of the sheathed and unsheathed weapons.
For example, when switching from Sword 1 to Sword 2, an AnimNotify is set mid animation, which when referred to in the animation blueprint, is set to call a sheath command in the character blueprint, this would then be assigned to the primary weapon (sword 1) and the shield via a 'set hidden in game' node with another 'set hidden in game' node applied to the sheathed variants of the primary weapon and shield, with the difference being that the set hidden node is unticked, allowing the meshes to appear sheathed
.
The following call would then be made to make the secondary weapon visible in line with the point at which the appropriate AnimNotify has been placed within the draw animation for the secondary weapon.
This can then be reversed to switch back to the primary weapon, with the correct AnimNotifys in the right places.

The resulting in game shots represent the post switch effect of hiding and showing the appropriate meshes at the correct times within animations, and referring across to another stance which was created using another BlendSpace identical to the primary, but using the appropriate animation files for the weapon type.

This process as a whole did confuse me initially and is not perfect, as this is both my first implementation process of a character within a game engine and there is no solid sheathing animation for the shield, with this in mind I cannot fix this right now without taking extra time to extensively change the animations provided to me within a software like Maya.
As I have little knowledge right now of actual animation cleanup, I will be leaving the animation as it currently stands with a view to possibly alter the animation or make my own at a point further down the line.
Looking positively upon this criticism, I have learned through this process ways of switching equipped weapons, which I would be able to apply in a multitude of game types, not only melee based third person action games but shooters and some elements of the role playing genre too.

Idea Generation for Computer Games - Movement Blendspace.

To begin to apply movement to my character, I implemented a singular directional BlendSpace, this utilised the idle and running animations to be reflected in game when the character is standing still and moving respectively.

I started with a simple two animation blendspace, but later added a third animation, using a Walk, and extended the values within the blendspace, this then allowed me to utilise multiple methods of walking simply by setting the max walk speed in blueprints further down the line.

This was to come in useful not only for slowing the character's movement to a realistic walking speed on the press of a button as seen above, but also for things like forced walk volumes, in which I can expand on narrative without a player being able to run around at will. These may feature in cutscenes further down the production pipeline also, providing further expansion on the narrative of my level.

Once the BlendSpace had been configured, I created an animation blueprint. Within the anim graph inside the animation blueprint a new state machine was created, to allow me to make the character switch weapons, visibly hiding and showing the alternate weapons as and when necessary, these were to be referred to through the use of booleans just a little later into development.

Idea Generation for Computer Games - Weapon socket preparation.

To begin the preparation process, before the implementation of any physical animations, I needed to apply the previously made weapon meshes to sockets within the skeleton, for this purpose I needed to make sockets in both the drawn and sheathed positions for the weapons.
The values once placed, were zeroed out to lock the mesh into position within the socket and I was prepared to implement animations on top of the idle animation which was already in place upon import.

Following the parent socketing procedure, the skeletal hierarchy can be seen below, sockets and meshes included;

From a further pipeline standpoint, these meshes and sockets have been placed well, as the animations do not result in much clipping between the character and his accessories.

Idea Generation for Computer Games - Pre Production and Cultural Context

Through this unit, I have been tasked with implementing a fully functional character into Unreal Engine, utilising a multitude of processes and functions within the blueprinting system to bring the character to life.

Much like work I have done previously with regards animation, I had to take into account the animations I would be needing, for this purpose, I referred back to an earlier mindmap I had created, this would serve to give me ideas for animations I could implement into the flow of my work alongside any animations which are to be mandatory to this unit.

The mindmap can be seen below;

For the purpose of this unit, I have carried my character over from my previous work and have also been provided access to multiple packs of animations from Mixamo. From these packs I took a Sword and Shield animation pack, and a Greatsword animation pack. These were downloaded and imported into Unreal Engine along with my character, ready for the implementation process to fully begin.

Along with the animations, I was also tasked with making a few quick meshes to act as a primary & secondary weapon and a shield. for this purpose, to fit with my character, I created a baseball bat, a sledgehammer and a riot shield. These will all fit well with the animations to be used in terms of proportions and locations to which the weapons will be socketed within the character.

---------------------------------------------------------------------------------------

Cultural Context is an important part of every stage of games development, and as such must be considered right from the get go when mind mapping and brainstorming, putting together mood boards also.

Within cultural context research and responsibilities, developers must all take care that they are not planning to create content which may be offensive to a group of people, be it of any size, this means any topics which may be considered sensitive to any race, religion, gender or other are generally best avoided if it is showing them in a negative light unnecessarily.

For example, a videogame clearly depicting acts of terrorism could use a character of any race or religion, preferably based in a country in which terror attacks have not recently happened, as this is not only sensitive to the race and/or religious citizens, but also if depicted in a specific location, could upset a whole city or even country or people.

For this reason, I have considered obligations to make the setting fictional, a random post apocalytic setting, inspired by multiple sources including the TV show 'Defiance' and the film franchise 'Mad Max'. Keeping the setting fictional means anything can happen within the region to an extent without affecting people negatively.
I have decided my boss will be an alien or mutant of sorts, as this is still a humanoid type of violence which I will be implementing, but as the enemy will not be human, the rating for a proposed end game would not necessarily need to be as high, as long as the violence was not extreme.

I have however, decided to design my level with a higher class and lower class area incorporated into the design, bearing this in mind, I would intend further down the production pipeline, to implement characters of all different races, aliens and/or mutants alongside humans, with no direct correlation to whether any specific races would be lower or higher class.