Project Opening - Week 1 - 2

NOTE: All blueprint images from in this post are the final variants of the blueprint in question. Blame my organisational skills for that.

Well, since the first post was so long, here we can talk about Blueprints! If you're reading this you probably know what blueprints are, so as much as I feel I should go into what they are, I won't. Just know that I am in love with the blueprinting system. 

With the last part of week 1, I went over what I had created - the character, a small environment, the camera, the enemy and the teleportation. I'll ignore the environment and enemy in this post, since I created much better (and more interesting) ones in later weeks. For now though, I'll go over the core mechanic of my game, the short-range blink.

An image of the (final) teleportation blueprint, in all it's low-res glory. EDIT: Important Blueprintue link - take a look at the BP!

So, that image above isn't all that useful here. Unfortunately. What I can do, is tell you what I had at the time. When I first created the blink/teleportation system, I originally created it with the orthographic camera. Moving over to Perspective had it's own problems, but I'll go over that in a moment. 

The way I did the blinking originally was through this: When the player left clicks, it gets both the mouse's world position and the player's world position. It then takes away (vector - vector) the player position from the mouse position to get a vector value relative to the player (the distance from the mouse to the player). After that, it then clamped the vector to a specific value (it has changed over development, I believe it started at 750 and is now currently at 1000) and then added this resulting vector to the player's world position. I made sure that the SetActorLocation was set to 'sweep' so it would take collision into account and stop the character before it went through things.

However, after creating this, I then realised I wanted to use a perspective camera! Simply changing the camera to perspective, setting the FOV to around 15 and moving the camera about 10859 units away from the player caused some issues. Basically, the camera was not correctly getting the world position of the mouse! So if I were to click at the very edge of the players teleport range, the player would only go about 1/10th of the distance to the target location. This wasn't very good.

A visual example of the issue, after adding a perspective camera.

The reason for this was simple: When using an Orthographic camera, like in the image in the previous post showed, it rendered the window on a simple flat plane. However, with a perspective camera, the effective 'layer' of the image expands as distance increases. This skewed the mouse world position - I was never sure why this was the cause. but it definitely broke the blinking.

This is where George (our tutor) helped me out. He introduced me to two things: Object channels and Line traces. The combination of the two allowed me to fix the blinking! The first thing that was made was a Box Collision in the player blueprint's viewport - this box was changed to a new custom Collision Channel named BlinkMouse, which was set to ignore by default. This meant that everything ignored this new Box Collision, but I could still use it in other ways.

The 'Blink Plane' in the viewport of the player blueprint. Note that the first Axis is the camera, and the second is the player - it's pretty big (there's a reason for that!).

What I could do is use a blueprint node that George introduced me to, called 'Get Hit Result under Cursor for Objects' - with a name that really rolls of the tongue, you know it's specialised. This does exactly what it says in the name, it detects any object with specified channels under the cursor and returns a hit result with information, including if it hit something, the object hit and, most importantly, the location of where the mouse hit! THIS was my saving grace, and allowed me to get the correct location value for when I want to teleport. Voila, fixed blinking, right?  Not so fast...

The super specific node in question is at the top, with the 'BlinkMouse' object type used as the type of object to look out for! EDIT: Blueprintue link.

There was another thing that George showed me - a better way to do the teleport itself that also helped with an issue later down the line. Instead of using some simple math to get the teleport result (which was kinda un-controlled, as you couldn't teleport through ANYTHING with collision), I could use a LineTraceForObjects. Which functioned similarly to the mouse node, but instead took a start location and basically drew a line between there and a destination vector - stopping giving a hit result for any specified collisions on the way. This not only taught me about Line Traces, but also allowed me to do something specific - specify the collision it detects. In this case, it was WorldStatic, which was one of the default channels that Static Meshes come default with - this was what I was using for my environment, perfect! This also meant that the player ignored any enemy with collision. I could teleport through them!

The Line Trace used in my final version of the teleport! Ignore the other stuff. Look at the cool thing. EDIT: Blueprintue link.

The result of all this is that I can teleport through anything but things listed as WorldStatic. This means I can use different methods to detect enemies, walls, and other things like that to make my goal of the combat system possible - to damage enemies by blinking through them.

To make sure that the player wouldn't just blink away, a stamina system was needed! If you were able to read the blueprints, you may have noticed parts of the system used to create it. I created the stamina by using a float that is capped to a ceratin amount, and cannot go above the max. When using a blink, the stamina bar loses a large chunk (about 32%), and then begins regenerating. This means there's a limited amount of blinks that regenerate over time - leaving you vulnerable if you use it too much!

Now, I know that a lot of this isn't from the first week. But really, I don't have much else to show - all I can do is tell what I used to have and show what I have now. Week 2 may be less interesting than Week 1 in terms of blueprints, but I have more pretty things to show.