Some of these commit notes are from memory as I have found out that Git Desktop does not save the description that I created between launches of the program. Once the program is closed the information is lost. Very irritating! So, from now on I will work in Workflowy to take the notes that I need and just paste them into Git Desktop when I am ready to make a commit. Bah.
Macros are cool
This is my first macro. I dont mean the macros that you can set up in an actor that are a little like functions, only at compile time the nodes themselves are pasted in where ever the macro is used. No. I mean that this is the first macro that I have created that is part of a custom Macro Library. Yes, I feel very grown up right now. I know its simple but it turns out that this little guy is really useful. So, now I am looking out for logic that I an duplicating between blueprints, as thats really the issue to solve with this. I also finally know what a ‘wildcard’ is. Its anything. Simple. More specifically and as I understand it, a wildcard is used as a placeholder at time of creating the logic so that when the macro is used, it will determine the type of what has been passed to it and work with that. Perfect for an array operation like this as it does not matter what the array contains, only that it is an array.
Fixed the macro that was supposed to be fetching a random element from an array
Imported some new blood splatters for testing
Started to set up the gore profiles
Created Enum called Gore Profile Struct that contains a Name field and an array of will be – Gore Pieces. This should allow me to set up things like ‘HeadShot’ as a profile and then determine that eyes and brain gore should be included in the list of gore.
Created Gore Pieces Base that I will use to make children Gore Pieces. The functionality like audio on hit and spawning decals or drawing them from a pool will happen in here.
Created Gore Piece Eyeball just as a test really as I have not changed the model to an eye although I do have them. Its just to start building the Profile idea out.
I am really getting a lot from using version control. Being able to look back over the commits and see what was updated and what was changed is very informative. I know that in the software world this is standard but there is always a first time for experiencing even things that turn out to be ordinary.
Imported the UE4 room from the content examples project as it will look nice for videos showing features
Fixed an access none error that was happening when a soldier who is not part of a squad is killed and tries to reach for a squad mate to shout ‘man down’.
Fixed access non error when the killed soldier tries to check that the fire team is dead but he does not belong one.
Moved the squad and fire teams into the new space and all the decals and features seem to work except for the squad clean up
Squad leader was being spawned outside the room and was not dead when the player was entered the clean up volume
Added is valid check to the ‘Dex lost’ call to the Dialogue Manager, as it runs on a re-trigger-able timer and the owner can be killed before the timer cycle runs its course.
Added is valid check to the ‘found soldier body’ call to the Dialogue Manager as there is a delay to that call in which the caller can be destroyed.
Added is valid check to the weapon base class for when the reticle is trying to cool down but the owner may have already been destroyed.
Added an ‘Enable blood’ bool on the bleeding component that can be set in the details panel of any actor that uses it.
Took out the behaviour in the Soldier that was polling the Music Manager so that it would change stat at the right time, this needs to be changed to Event Dispatchers instead.
Began setting up the Gore Profiles in the Bleeding Component but its not finished yet.
Just a quick note to say that I went through the content examples project on the Unreal Marketplace and found out how to add physical hit responses to the Soldier characters. It would be better shown in a video but I dont have the time to sort that out at the moment!
Added a very rough version of physical hit reactions. I think it needs more work but its a good start.
Spotted a problem with the logic that makes that soldiers hang in the air. when they are thrown using the fling ability, and the collide with anything that causes the hit event to fire, they are executing the ragdoll in air feature. I need to come up with a way to validate the thing that its striking.
Continuing the work on making a component with a Single Responsibility, there has been some updates to the Bleeding Component. There is a link to the SOLID principles smart goal here.
So that this component is as portable as possible I have used variable types that are as high level as I can. Ultimately, I suppose that I would be able to pass the Bleeding Component a location vector only and that might be the way to go thinking about it. However, this is an Unreal BP and I would only be putting this on an Actor as its a Actor Component so I really don’t have much of a choice there! My point is that the only thing that I am passing to the events in that component that are specific in any way are Actors. Actors are defines in Unreal as ‘anything that can be represented in the world’. I think in this case that is high level enough. It makes the component very flexible and I’m happy that it would be able to be added to any type of character, robot, turret, vehicle or anything else, and work fine. The event prototypes are:
The ‘Projectile’ input is an Actor object reference and not an actual projectile blueprint class. That means that anything thats in the game world should be able to be used as the initial location for the trace.
Again, the Actor is just an Actor, but I think that’s a bit more obvious here! This event just traces straight down and find the first positive response to the Valid Blood Surface channel.
This one is a little more specific but I don’t think that its a problem. It needs a hit result to break inside the event and I am comfortable that a hit result is a standard UE4 data structure and would be valid in most situations. This could be changed to use the impact point and impact normal which now that I type this might be worth considering. Thats what I like about journaling, its that moment when I am thinking something like this through in order to explain and you spot some obvious improvement that could be made. However its worth mentioning that the Blood Spray is totally optional and if the user does not specify one, one will be chosen from the array that should be populated when the component is used.
This event is the one that would be called by the actor that was using it when that actor registered a hit event and determined in its own logic that a blood splat should be placed there. Again, this may be able to be slimmed down but to be fair, the hit event that would have triggered it in the first place would produce a Hit Result so it may as well just be passed right in, unless I find out that’s really expensive for some reason.
Drawing blood under the soldier when he is hit now happens from the bleeding component.
Drawing blood from projectile penetration from the bleeding component.
Enabled all of the physics bodies for the UE4 guy so that they generate hit events. I was only using the chest and head and then testing the velocity of the hit, but if he hit with his shoulder for instance, he would lose a lot of that force and not draw the blood when the chest did make contact with the surface.
Changed the penetration check to that if it does not draw blood, blood is drawn underneath the location of the projectile instead.
Added the suspended in the air effect to the weapons so that they can be plucked from the air. – Updated the weapon suspend in the air feature so that they can rotate a little, looks more natural
This is the problem. The Soldier actor is a crazy mess of tons of functionality, some of which is right, some of which is wrong and some of which just needs the plain ol’ delete key. But, I have a SMART goal regarding SOLID principles that is tackling this atrocity of a class. Ok, Blueprint. You know what I mean. I am applying what I am learning on the course and my own research to fixing as much of it as I can.
Single Responsibility Principle
This is the idea that each component, class, actor and so on is responsible for one, defined, activity. I understand this to mean that it should make common sense that a Weapon object could not reach into the Character object and make changes to the character directly, that sort of thing. If the weapon was heavy and needed to change the characters speed then there should be some other method by which that can happen without the Weapon being made to have a hard reference to the character or some logic that requires that the Weapon ‘cast’ to a very specific implementation of a character. Now, I may have some of this wrong at the moment and thats because I am still very much a beginner in thinking about these kind of design choices but I thought that I would start with something easily defined, not super complex but could be very portable if designed well.
The Bleeding Component
I decided to remove the following features from the Soldier actor and implement them in a component whose ‘single responsibility’ was producing gore in the world. Its a dark place to start I know, lets get on. So the functionality that existed was
Spray a blood particle from a location
Draw blood directly under a projectile hit location
Draw blood that would travel due to projectile penetration
Produce gore at a location, usually in response to a head shot or explosive going off.
Its not quite finished but now that majority of this is being handled in the Bleeding Component. This means that there is one place to edit the blood samples that are used for decals, one place to handle the tracing and other environment querying logic and so on. The other benefit of this is that is does not have to be just red, human like gore. It could just as easy be blue, dragon gore in another game and thats the point. I have really tried to take the Single Responsibility principle to heart and think in those terms now. I am very keen to start the course I have found on Pluralsight. I talk about that in the SOLID principles post.
Added logic to be able to track if the bullet casings are suspended in the air or not.
Added a new sound set of light metal taps that can interact with the weapon when it taps the casings when the casings are suspended in the air.
Used the velocity that the casing is travelling with to determine how loud the audio should play, this worked well and I would like to apply this to all the other sounds that are ‘hit’ based
Added a small delay to triggering the suspended in air effect so that the casing could leave the barrel a little further and it looks really cool, give the player much more of a chance the notice the feature
Came across a node called ‘get reflection vector’ and have used it on the kids bullets shield to properly deflect bullets and its better than the implementation I was using before.
Created a ‘BleedingComponent’ that I hope to use the centralise all the blood effects that are spread throughout the soldier actor. That way I could make anything ‘bleed’ like a robot that bleeds black oil and so on.
Have soldier’s body impact blood working from the new bleeding component – Have soldier’s blood spray from wounds working from the bleeding component
I am very, very happy with this session. There are two reasons to that. The first is that the feature, which I will talk about in a second is just really cool. The second is that its a solid example of the learning that I have doing about programming patterns at play. I have a SMART goal about learning about design patterns that you can see here.
The observer pattern
One of the most useful patterns that I have learned about is this observer pattern. When I first started learning Unreal and the blueprint scripting system I could not get my head around event dispatchers (or interfaces for that matter, both I am using prolifically now though I’m pleased to say). Well, it turns out that event dispatchers enabled me to use the observer pattern before I knew that was what it was called. So in short this pattern is based on one object registering with another so that upon some being evaluated or some event being triggered, that actor can let the registered actor know ‘something’ has gone on. That something could be anything, a boss has been defeated, the player is at a certain location or, and in my case, the game is in coming out of slow motion. Anyone not familiar with event dispatchers, read on and I will tell you how I am using them in the logic too.
How I have implemented it
I have implemented this feature on a few things now, although I think in this commit its only the Soldiers, but I am catching up a touch with the journal. Soldiers, weapons, the explosive mine and bullet casings. I am going to talk about and show how I did the bullet cases. The first problem is that every single time a bullet case is spawned (sorry Jamie, I will pool them I promise) it, as the bullet case actor, needs to know if it should hang in the air or just fall as normal. Here is the logic from the shell casing actor that happens as soon as the little blighter is born:
The first part of making that happen to ask the game state if slow motion is active. This is a bool that I keep updated from the Slow Motion component that I created a while back to handle all of the time dilation. If the game is in normal time, nothing happens. However, if it is in slow motion, then the first thing (and this is the observer pattern at play) is that the shell casing registers itself with an event dispatcher in the Serial Link Game State using that Bind Event To node. From there I created a custom event that would fire when the event dispatcher fires. You can see I called it Drop Shell Casings.
This is the event dispatcher set up in the game state:
The one that we are registered with is the one that will be called when the game comes out of slow motion. Each actor that has been ‘bound’ to that event will get a call from the game state at the right time to say ‘hey, that thing you were listening for? Its just happened’. So, when its fired, my custom event will fire and the shell casing will be updated. When that happens, I am unbinding from the event as that particular shell casing never needs to know about the state of the slow motion again.
What I am using it for
This is quite simple really. I am only using this set up to determine what the values for linear and angular damping should be at the time that the shell casing is created and then I am using the observer pattern so that the shell casing can be updated with the normal values for those fields if needed. Very high numbers for those two properties lead to the effect of the air feeling like tar to those actors.
What I intend to do with it
I think that one of the best ideas I have had with this but have not had the chance to try out is linking it up with the combat teleport feature for the player. I would really like a simple way to have the player just hang in the air when teleporting so that should he teleport over a group of enemies, its not gravity that brings him down but choice or running out of power for that ability. I think that being able to hover in the air like that would lead to some really cool and satisfying combat scenes in which the player could teleport up, take out some guys, teleport back to the floor and carry on. I think that I would start with playing around with the player capsule as I am not sure that the updating the damping settings on the mesh would work because the mesh is under the hand of the animation system at that point. I would also try disabling gravity for some period of time if it if confirmed that the player is in the air although that could lead to the character being affected by other forces like radial explosions…
Used the logic that controls whether the ‘body hitting the floor’ foley gets played to limit how many times the blood decal can draw. Its hacky but its works well enough for now
Updated the damping on the gore pieces so that they dont roll around so much.
Stumbled across something very cool. Its a work around for having physics bodies look like they are in slow motion when they are not.
Updated Ragdoll character event with the ability to set the linear damping and the angular damping to a very high value, this makes the air feel like tar to the skeletal mesh.
Bound to an event dispatcher in the slow motion component so that the ‘ragdoll character’ event can be notified when the player is out of slow motion, then, the normal values for the damping are re-instated. This makes the characters who were trapped in the tar effect, fall to the ground as normal.
Updated the explosive mine so that if it goes off when slow motion is being used, the victims hang in the air.
Updated the Inferno-mine so that if it goes of when time dilation is active, the victims hang in the air.
Updated the Fling ability so that if slow motion is enabled when the body hits the wall, the victim goes into ‘tar mode’ so that it hangs there until the slow motion. They are returned to normal when the time dilation goes back to normal
Casings for the SMG now hang in the air in slow mo!!! When time comes back to normal they all drop to the floor at the same time and it looks epic.
Also noticed that the bullets casings can be moved in the air with the gun, as that has physics enabled. So the player can tap the shell casings as they hang in the air!
This commit was a good one. I learned a ton and I was also able to notice that I think about this stuff more clearly now. I really enjoy recognising that my skill level has moved on, its very satisfying. I talk about it because its one of the pleasures of being involved in something like game development, where the pit of available skills to learn is so deep that you could just go on forever. Sometimes, I think its very rewarding and motivating to tackle some problem that you tackled a while ago and find that your tool kit has grown in the mean time. Thats what happened to me in this development session. The main issue that I was solving was that the line traces that were being used to work out where the blood decals should go were returning hits from and ever increasing array of things that I had to declare as ‘actors to ignore’. Weapons, gore pieces, other soldiers, it was a right mess really. Then, upon coming back to this issue for the first time in a while my first thought was ‘I should set up a custom trace channel that everything blocks be default called something like ‘Valid Blood Surface’ then I could just go round the project setting what should not return anything in that trace to ignore’.
Well, thats what I did.
Now, there were quite a lot of actors to go through an set that they and some of their components ignore this channel but thats only because its late to the party. From here on, when I create something new, I can set it to what ever I need. Very pleased with that.
Tracking the head location
The next issue that I had was that because I had been using the ‘head’ bone as the starting location of a 360 degree ‘what should I draw blood on’ test, if the poor fella that the test was coming from found that his head had been smashed into a wall in that frame, the return from that process was less than desirable. It looked as if all the decals had been draw at various rotation from exactly the location in the world that the head had been at the time. Then, there was a kind of ‘slicing’ effect that was happening and I needed to sort it out.
So, I decided to track the heads position every so often so that I could use it as a location delta (I hope that my terminology is right there). Then I could decide whether or not to carry out the scan from the head location or the location delta I had tracked. I decided to always use the delta (I think, I am writing the retrospectively). This worked the vast majority of the time. I was using the last know head location and the current head location to create a unit vector that could be used as the direction that the trace would go. This lead to the blood always being in about the right place. But…
… It turned out that I could have saved my self all of that work as I decided to play with doing things a different way instead and that worked out much better.
Setting up gore to work with hit events
So, having thrown all that work away (thats not quite how it happened but I like a little drama), I did this instead…
Well this lovely bit of logic caused this mess…
I am tracking the gore pieces velocity when the hit event is thrown as in earlier testing they just painted the scene red, leaving decal’s at every single location that they came into contact with regardless of how brief that contact was. Tracking the velocity really helped with that. I also intend to link the size of the decal to the velocity, seeing as that value is already being tracked for the gating side of things.
There are some other things that need to change with this though. I am only using one sample of blood and I would also like to be able to turn the blood and think about some ways that I could make it fall in a more realistic pattern. Anyway, for now that takes care of the gore pieces and stops most of the slicing effect that I was getting. Onto the bodies them selves.
Soldiers causing blood on hit event
I tried to implement this approach immediately on the soldiers but had a bit of a problem. I didn’t know that hit event had to be enabled from the physics asset and so spent plenty of time trying to get ‘I’ve been hit’ printing out from the hit event on the skeletal mesh from the soldier actor, silly boy. Anyway, this was the problem…
In an effort to not have a million decals in the level thanks to all the hit events and the fact that testing only for the velocity would still put blood on top of blood, I needed another way to control the ‘flow’ a little more. I can up with the idea of tracking the last location that there was blood drawn and then not allowing anymore unless the requested location of the new blood was at least x amount of units away. That worked quite well and was not too jarring, but I think there might be a better way that I will talk about when I try it out.
Added a custom trace channel called ValidBloodSurface. Now when the line traces go out to find places to draw blood, they are only looking for this. That has stopped most of the blood decal slicing effects we were getting. Changed multiple actors and component responses to allow this to work.
Have solved the blood decal slicing issue by tracking the head bone location every so often, line tracing from that to the actual head location while looking for surfaces that block the ‘valid blood surface’ channel set up earlier. Then, step back 50 units from the surface normal and start the actual blood splatter tracing event. Seems to have solved all the slicing problems.
Changed how the head position is tracked so that we are not polling for it. When the player uses the push attack, the current head location is passed to the victim soldiers for use in the blood events.
Updated the blood events so that it can still be triggered using the head bone without first having provided its snapshot location so that the line trace can run.
Changed all the components collision settings in the Base Mine class so that they ignore the ‘blood surfaces’ channel too.
Made a separate event for spawning gore and blood for the explosive mine as there was a problem with deciding whether or not to track the current head location.
Fixed a problem with the math for the blood gen location vector. Works properly now.
Added functionality so that the gore that is generated can leave its own blood impact decals. Need to balance this, as its too easy to just paint the whole level red!
Added functionality to allow the soldier to draw blood when he hits a surface hard enough.
Work is still needed in the new approach to blood and gore but I think that general approach of creating decals on hit events looks more natural.
There isn’t really much to say other than the mighty Kanban board now says that its time to work on the gore again… Mwahahaha! I intend to centralise the gore into an actor or an actor component so that I can bolt it onto anything and have is bleed or produce gore. So, I would like to able to add it to say, a robot who’s version of blood would be globulous black liquid and who’s gore would be metal shards and sparking circuits. Im sure we will see how that goes in the next posts…
Fixed the blood decals not showing up when only in indirect lighting.
Enabled the features in project settings
Changed all the blood decals translucency settings
Updated the translucency settings on the bullet holes decal so that they now show up under static lighting like the blood.
Changed the ‘screen fade size’ when bullet decals are created to 0 so that they dont fade away when you walk away from them. It would be better to have this set to something like 20 meters, but the only value that does anything is 0 and that means that they dont fade out at all…
Added a fade to the bullet hole decals to clean them up after about a minute – Added a fade to the blood decals to clean them up after about a minute
There is not too much to report in this commit, just some bug fixes and some balancing really. At the time development I was on the task ‘Weapon Basics’ and the last part of that running through the Kanban board was to balance the weapons and make sure that they were distinct from one another. I do like the way that the Kanban board has kept me totally focused on making sure that the weapon features are all finished (at least to a certain standard) before moving onto the next major task which is ‘Gore’. The ‘Weapon Basics’ tasks broke down into lots of sub tasks including…
Having weapon clatter when dropped
Being able to collect ammo
Being able to exchange your weapon with one on the floor or on a body
Being able to hold an extra weapon
Tying up the levelling component so that improvements and skill gains were shown on the screen via some messaging system
Implementing Gaussian randomness to the bullet spread
Implementing the grip change from rifle to pistol in the animation BP
Balance Assault Rifle
Implement UI for all features above
This links in with the Agile methodology well as by focusing on just the weapons they are now a complete feature and it feels right to move onto something else.
Fixed bug where the weapons would not show the right ammo pool count because another weapon had altered it. Now shows the right count when the weapon is drawn.
Changed the psychic push so that it no longer works on dead people, it was getting in the way of the ammo and weapon collection stuff and felt odd.
Changed the direction of the shell casings from the pistol as they were working on the world direction and not the sockets.
Decreased the rate of fire on the Assault rifle as the weapons need to be more different –
Decreased the ammo in the clip for the Assault rifle to 20 as its strength is that its more accurate than the SMG
Set the spread range for the Assault rifle to -5 and 5 – Set the spread range for the SMG to -10 and 10
Created PistolProjectile for use with the pistol as it was using the SMG ammo which made it difficult to change the damage that it was doing.
Made the Pistol slow but causing a large amount of damage, 80 pts
AI now switches between the SMG, Assault rifle and the Pistol.
Added new fire sound for the pistol to make it stand out from the other weapons
This development session focused on having the bullet spread feature that was already built in, represented to the player via a pretty standard (but first for me) dynamic reticle. From there I wanted the shell casings to be a little more noticeable so I updated the orientation of the ‘ejector’ socket on each of them and added a little torque to the casing as it came out. I made sure that the player gets a much better look at the casings as the come up and out of the weapon and it worked really well.
There is information coming from the players Levelling Component (yes you can level up in this game) so that allows the users skill with that weapon to be represented by the growing and shrinking of the reticle. Pretty cool.
Now have the dynamic reticle expanding with the bullet spread and it feels right.
The reticle shrinks properly now too.
Fixed the problem with the pistol animation although I am still not satisfied that the weapon feels good to use.
Changed the position of the main player cam so that the weapon is more prominent.
Changed the location of the ammo counter UI so that it can still be seen on the SMG with the new camera position
Changed the near plane clipping from 10 to 1 in the main project settings
The pistol has been changed to 1.4 in scale and looks much better
Added torque to the shell casings in the pistol
Added torque to the shell casings in the SMG and changed the location of the ejector socket on the mesh for a more dramatic feel to the shooting
Added torque to the shell casings in the Assault Rifle and changed the location and rotation of the socket that spawns them