Chronicles of a Sofa Ninja

Hanging in the air…

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…

Commit

• 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!

Trace channels

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.

Commit

• 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…

Commit

• 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 SMG
• Balance Assault Rifle
• Balance Pistol
• 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.

Commit

• 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.

Commit

• 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

I am pleased with how the information panel on the right of the UI works. I am trying hard to step back from things being too specific and I am trying to make things as abstract and flexible as I can. Sometimes it works and sometimes it doesn’t but this time it was a success! So the logic above it always looking actors with the interface ‘IsContextSensitiveUIElement’ and then should it find one it throws the message ‘ShowUI’ I wont give a detailed explanation of all the little things that stop it breaking, just the overview. Questions? Tough. I mean, ask.

The part I want to talk about though is that UI Info panel that appears to tell the player the options about how to interact with the thing that he is looking at.

I like this as there is no casting and should the player character change for any reason it would still work. Also by passing in an array of UI elements, its easy to change what is displayed from different actors that implement the interface. I know that there is no multiplayer option to be built so I know that the player is going to be player zero so I think that accessing them in this way is fine considering the project. On the Controller side…

Commit

• Updated the look of the ‘collect ammo’ and the ‘out of ammo’ UI widgets.
• Updated the ‘out of ammo’ to say ’empty’ instead
• Found out that I cannot use an emissive in the UI without sorting some other things out. This is to do with the order that Unreal draws and applies post processing.
• Added and UI info panel to the main HUD.
• Making sure that the UI info panel is spawning its widgets and organising them so that I am free to add what I need in the future.
• The info panel is now to the right of the cross hair although I would like to have it in the bottom right corner, I didn’t work out how to have the vertical boxed position change to accommodate its children.
• Can pass an array of UI elements to the info panel now and they are removed when the player looks away from the weapon.
• Added ammo pool and ammo clip UI widgets to the base weapon class
• Created widget assets for those components
• Now have ammo in clip displayed on all weapons in the calculator font. Looks cool!
• Ammo status UI to change from ‘collect ammo’ to ’empty’ when the ammo is collected by the player is still looking at the weapon. Competed
• Make sure that only the players currently equipped weapon shows the UI for ammo. Complete
• Made the UI on the assault rifle a bit smaller.
• Added the ammo pool from the weapon component to the ammo in the clip counter so that it can be shown on the weapon too. Looks really good.

I wanted to start posting more frequently about the development work that is going into Serial Link as that is where I am putting the lessons I am learning into practice. The first of course if that of version control. I have talked already about the project copying that I thought was version control and I suppose to a certain extent it is, but its cumbersome and stinks of amateur hour (as do a lot of the things I do at the moment, but thats why Im here).

So the first thing was setting up the repository which was straight forward enough. Then it was the LFS part which I found just a little trickier as it could not be set up in the GUI Git Desktop and had to be done via the Git Bash tool. If I am wrong about that and have missed something, please do let me know. I then, nervously, made the first commit. This. Took. So. Long. I started to get a little worried that all was not well in the land of Serial Link and its visit to version control but after what seemed like an age, the commit was done. I pushed it to the repo on Git and bam, first commit to a remote server. Didn’t I feel proud.

The other reason that I would like to keep the journal up to date with Serial Link is that during one of the webinar’s the conversation turned to the question ‘when should one commit ones work’. So, I thought that posting how I do things here might open that discussion up for me/us/them whoever, and allow me to explore some of the other options regarding when to commit. I have started this process at commit 4 because it did not occur to me to take proper notes until then. I am very pleased that I am taking better notes though as it is making it easier to see just how much is going into making this game!

Commit

Commit notes…

• Updated the weapon base blueprint so that it can choose whether to show a E: pick up ammo UI element or a red OUT OF AMMO element instead. I solved the problem of hitting the player and the players weapons by creating an array of ignorable actors.
• I set up an event dispatcher in the weapons component that is triggered every time the weapons array is updated. This keeps that array of actors to ignore up to date for the player without having to recreate the array at each tick.

This commit was focused on the UI I have been implementing so that the player can actually interact with the game space in a more predictable way. The issue I was solving was that the line trace that is looking for things in the world that it can interact with was hitting the weapon instead. This was before I know how to implement custom channels for trace responses so that may have been a better way to do it.

Thats is for that commit. 😉