Sunday, January 25, 2015

Unreal Engine 4 Tutorial #4: Basic HUD Based Command UI for Top Down Turn Based Games

Hi, welcome back for the next tutorial. And in this tutorial, I'll be explaining how to create a basic Command UI for top down turn based games using HUD blueprints. By the time we reach the end of the tutorial, we'll have a Command UI with movement and fire action commands, and a player character that responds to the commands. Here's a screenshot showing the end product: 


Oh, and this tutorial is gonna be quite big, compared to earlier ones. So I advise everyone to go through the screenshots, before reading through. If it's clear, there's no need to read through the whole thing, partly because I've written this with a beginner audience target in mind. Ofcourse, if you have doubts, I hope they will be clarified in the written description. If not, feel free to ask me in the comments.

So let's get started. Again, I'll be starting with the top down template. First of all, we need to create a new HUD blueprint. If you're a beginner, you can find this by first right clicking on the content browser, then selecting 'Blueprint' and search for 'Hud' under 'All Classes'. Click on HUD and select it. So now that we have one, we need to set it as the default HUD class for your game. For that, we need to go to 'MyGame' blueprint and set your new blueprint under the 'HUD Class' in the defaults tab. 

Now let's get back to the HUD blueprint. First, we need to create a function for drawing the buttons for our UI. Let's call it 'Draw Button'. So basically, creating a button involves 3 parts: first we need to set it's texture; second we need to set the font (if you need to specify the button name); third and last, we need to set the hit space which would trigger the button functionality. For this function, we need 4 inputs:

1) Button Screen Location (Vector 2D)
2) Button Text (String)
3) Hit Box Name (Name) - [Helps us identify the clicked button by name, later on]
4) Button Texture (Texture 2D)

From now on, it'll be easier if we have a screenshot alongside as well. So her's one shot of the function body:


Before diving in, there's one thing you should know. In this case, when we specify the button coordinates, Unreal actually takes the center point of the button into consideration. Whereas for the button textures, it actually means the top left corner of the texture. As a result, we need to get the button dimensions, divide it by two, and then subtract from the button location (center), in order to give the location for the button texture. Similar considerations have to be taken into account for the font as well. 

So now, if you notice the screenshot, you can see that I've done the above mentioned calculations, before drawing the texture and font. I've hard-coded the button dimensions to (x,y) = (256,128), as seen in the the input for the hit box node. As you see, we first use the 'Draw Texture Sample' to well, yea draw the button texture. Based on the calculations, we specify the location of the texture relative to the button location (Button Screen Location input). We then assign the Button Texture as input to the node as well. Next, we move on to the font, and we use a 'Draw Text' for that. Inputs include the actual text data (Button Text input), text color, screen location and the font. Before setting the font, we use the font type and text to calculate the location of text relative to the button center. Finally, we add a Hit Box to specify the button hit space. As mentioned earlier, the hard-coded button dimensions are set as the input. So with that, we have the 'Draw Button' function ready.

Now let's move back to the Event Graph of out HUD Blueprint. First let's create a bool variable that let's know when we need to display the HUD. I'm gonna name mine as 'DisplayHUD'. Then we use the Receive Draw Hud event to draw the buttons. We check if the 'DisplayHUD' is set to true. If it is' we call the 'Draw Button' function twice; one for the move command and one for the fire command. Here, we specify the function inputs including button screen locations, button text, hit box name and button texture. Again here's a screenshot to avoid any confusion:


We need a custom event to call our hud functionality from the player controller, based on player input. Everytime the player right clicks on the navigable space, this event will be called in to display the hud. So let's create one, as shown in the previous screenshot, with 3 inputs:

1) Hit Location (Vector) - For storing the clicked location in the level
2) Actor Location (Vector) - Player Location
3) Forward Vector (Vector) - Player character's forward vector, for getting the firing direction and projectile spawn location.

We store all these values into local variables inside the hud blueprint, whenever the event is called. Alongside, we set the 'DisplayHUD' variable to True.

Next, we need to call this event from the player controller. So let's go to the event graph of MyController blueprint. This is what it's gonna look like, by the time we're finished with our controller:


As you can see, I'm using right mouse button click to get the player input. Every time the player right clicks on the level, I get the hit result under cursor by channel, break the hit result in order to get the hit location. This data, along with player character location and forward vector and used to call our custom event from hud blueprint: Event Toggle HUD. Now all we're left to deal with are the workings of the fire and movement commands. For implementing that, we head back to the HUD blueprint once again.

We're gonna use the Receive Hit Box Click event to see which button the player clicked. And this is the reason why we used the Hit Box name earlier while making our button function. We add a switch node with custom pin names equivalent to our button hit box names. No matter which button the player clicked, we will first set 'DisplayHUD' to false. If the player clicked on the move command, it's pretty easy to handle it. We just get our controller and use the 'Simple move to location' node with the hit location we received earlier as the input. Handling the fire action command is a different story. It would make sense to have a screenshot over here first:


Before we spawn the projectile for firing, we're gonna rotate the player to face the direction of the hit location. In order to achieve this, we first get the forward vector, multiple it by say 100, and add it to the actor location. We then use this data along with the hit location and find look at rotation to get the necessary yaw value of the new rotation value. We then get the actor rotation and change it's yaw value to this new yaw value. We then set actor rotation using this new yaw value. I'm using a delay of .2 seconds after this, so that the player has finished turning to face the new direction before firing the projectile. Then I go to MyController and create a new function - 'Fire at Hit Location', with the three vector inputs shown above. I then call this function after the above mentioned delay. As you may have noticed, I'm getting the forward vector again, since the player character is now facing a different direction. Now here's a screenshot of the function:


I'm not going into the details of it's implementation, as I have already explained the process in one of my earlier tutorials. You can find it here: 


With that, we have implemented a working HUD based Command UI for the Top Down template. Just to make it a bit more realistic, you could add the logic from the screenshot below, to your projectile blueprint, the making of which is explained in the above link.


This code, makes sure that your projectile is destroyed after impact with other actors. I've also added a particle system to be spawned at impact.

Alright, that's all for this weekend. See you at the next post.

Thursday, January 22, 2015

Unreal Engine 4 Tutorial #3: Unit Selection Decals for RTS Games

Hi, welcome back for another UE4 Tutorial. This time, I'll be walking you through how to set up unit selection decals for RTS games. So the decals need to be visible, when a particular unit is selected, and set to hidden as soon as the unit is deselected. For this tutorial, I'm gonna start off from the Unreal Top Down Template.

First of all, I'll be changing the default controls a bit. Instead of using left mouse button to move the units, I'll be using right mouse button for character movement. I already have a decal texture, that I created in GIMP. If you don't have one, you could get my decal texture from the link below:


So once you have the texture ready, next step is to set up your decal material. For creating a decal material, we need to set the 'Material Domain' in the details panel to 'Deferred Decal'. I'm also setting the blend mode to 'Emissive' in my case. Then we multiply the texture with the required color and connect it to the 'Emissive' input for the material. I then connected the texture to the opacity as well, since I only want the white space of the original texture to be visible. Here's a screenshot of my material:


Now that we have the material ready, it's time to move on to the 'MyCharacter' blueprint to add the decal component to you character. In the components tab, go to 'Add Component' and add a decal component. In it's details panel, set the material to the decal material that we created earlier. Also set the 'Hidden in Game' attribute under the Rendering section to true. This way the decals will be hidden by default. We only want them to visible when the unit is selected. You'll probably need to adjust the transform settings to get it to display properly. For now, you can use the same settings that I'm using, as that will definitely work out of the box. 


Next stop - handling the show/hide selection decal based on character possession. So in the character blueprint's event graph, add the events 'Event Possessed' and 'Event Unpossessed'. Get the Selection Decal and set it hidden in game to true for event unpossessed and false for event possessed. It's fairly straight forward, but here's a screenshot anyways:


Now we're gonna handle the player input inside the player controller class. First, add an input button event for selecting units. Then we get the 'Hit Result under cursor for objects' and set it's object types to 'Pawn'. Then we break the Hit Result, get the Hit actor and cast it to my character class to see if it returns true. If it does, we have our player controller possess the character. So everytime the player clicks on a unit, the player controller will possess that unit, which will trigger the selection decal to become visible.


So with that, you should be having a working decal material for your character. But just so that we can try it out in an RTS scenario, I'm gonna add one more character to the level. In order to do that, just go to the Level Blueprint and use 'Spawn Actor from Class' at 'Event Begin Play' using the default character class. Just set some transform values and everything's set.


And here's a screenshot of my unit selection decal while running the game in the editor:


So that's it for now. Over the coming weekend, I'll try to make a basic Command UI tutorial for the Top Down Template using HUD Blueprints . Until then, goodbye.

Tuesday, January 20, 2015

Unreal Engine 4 Dev Update #9: Navigation Path Display for Pawn Movement

In one of the earlier dev updates, I had written about the movement grid system that I had implemented. If you haven't checked it out yet, here's a link:

Unreal Engine 4 Dev Update #5: HUD based Command UI, Grid based movement system & Dynamically Spawning Grids

Basically all the pawns in the game are moving based on grids of 100x100 units. In it's current form, it only works for plane surfaces. I'll have to modify it to meet the requirements for curved surfaces, but for now, it's working fine for prototyping on flat surfaces.

Unlike most Turn-Based games, where units moving from one grid to another travel along the path connecting the grid centers, I plan to have free movement between the grids. This is very similar to what was implemented in XCOM: Enemy Unknown. I feel that free movement is the way to go for Turn-Based shooters, as otherwise, the movement feels very constrained. As a result, I'm using Unreal Engine's default navigation system, instead of going for a custom A* pathfinding algorithm. There are some occasional issues with the navmesh, when it comes to finding the shortest path. But I'm guessing that I can deal with the very obvious issues through adequate level design measures. If it proves too buggy in the future, I'll probably check out Monokkel's custom pathfinding algorithm that'll release soon in the marketplace.

So anyways with the current setup, as you might have seen from earlier posts, I do not have a permanently visible grid system. It's spawned dynamically based on player input and destroyed after it's use. As a result, I wanted to give the navigation path details to the player, when he wishes to move his unit to a new location. And fortunately, there is functionality in Unreal Blueprints to find the path that the player's unit will take from it's current location to any other location. So using that I was able to get path points towards any accessible location as soon as player clicks over there. I then used this data to create splines from the starting point to the target location, along the path points that I had earlier obtained. As a result, the player can always see the path to this target location before he makes his move. More so than it's aesthetic function, this data will be really useful in order to devise a good tactical move, if reaction shot functionality is added to the game. In it's current form, the pathing spline is not very smooth at the turning points. That's something that I have to deal with later on. But apart from that, it functions kind of similar to the path display from XCOM.

Here's a recording of the path display in action. As I mentioned in my previous post, I have removed most of the materials and toned down the graphics settings.


Recently, I noticed that there were pathing issues when moving around other units. By default, the pawns placed in the level do not affect nav mesh generation. As a result, the pawns didn't take the other pawns into account when generating their navigation path. So they just collided with any other unit in their path, thus halting their movement before reaching the destination. At first, I set the pawns' root capsule to affect nav mesh generation. But even in this case, I faced an issue, as the pawns were moving too far from each other due to their combined wider region of effect on nav mesh. I had to enable run-time navmesh generation and have the pawns effect the navmesh dynamically in order to rectify this issue. I now disable the active pawn's effects on navmesh, while having the remaining static pawns effect the navmesh. This way the pawns are able to path around each other fairly easily. And that's where I'm gonna leave it for now, while I move on to handling the pawn attributes and combat.

That's all for this update. You can check out more unreal dev videos in my Youtube channel:

Saturday, January 17, 2015

Unreal Engine 4 Dev Update #8: New Rifle & Movement Animations

Hi, it's been a while since my last update on the implementation of an RTS camera system. Ironically, that was the part of the project that went through a major change over the past few weeks. More on that in the next update post. Meanwhile I've added the movement and aiming/firing animations from Epic's 'Animation Starter Pack' into my project. However I did not want to change all the character level code into the ASP character that came with the pack. So I just retargeted the skeletons and copied all those animations into my default player/AI characters. I had to create a few new blend spaces and make some changes to the Animation Blueprint, but finally I got the new movement animations up & running without much trouble. It's mainly a matter of getting used to blend spaces and the basic flow setup of animation blueprints. I would recommend the following tutorial series by Epic for anyone having trouble with this matter:

Getting Started: Introduction to Blueprint 3rd Person Game Creation

Anyways, attached below is a recording of the new movement animations in action. It looks so much better now that they actually move around like they have some purpose. Until now, it just seemed like triggered Brownian motions, there wasn't much sense in why the character was running around like that.


I have not done any new recording lately. However I do have a few screenshot around showing some of my work in progress since I uploaded this video. One among them, being the fact that I added the awesome Assault Rifle from the 'First Person Shooter' project in the marketplace. Attaching the weapon to my character did not take much time, but implementing those animations wasn't that easy the first time around. The method that I've implemented is not very efficient. I hope to rectify it once I move the AI code into Behavior Trees. And oh yea, I have added an AI of sorts, actually the most basic AI possible in there right now. I thought of adding the video here, but I'll add it in the next post. This post is already big enough for one of my normal dev updates. But first here are a couple of screenshots of the awesome Assault Rifle getting ready for action:

Locked & Loaded

Training Drill

So looking at the dates, I realize that I'm kind of lagging behind on my dev updates. So anyways, here's a shot of it in action. Added in a muzzle flash as well. Went overboard with a laser at some point as well, but I'm not using it until I get my Aim Offset correct. I keep putting it off since I'm really not interested in working on animations. I'll probably do it when I've taken care of the rest of the interesting/cool stuff. Or as we all know, if it becomes absolutely necessary.

Finally some theatricality and deception. However no moving bullets.

Well that's going to be the last screenshot with those textures and lighting effects. The project is going naked from here on. No more fancy reflections beaming off of the ground material or totally out of fashion materials on the character models. Just the bare minimum from here on. Unless I go prehistoric with the project, I don't think my PC can handle recording videos while running the editor in the background. Besides those were temporary materials anyways.

Anyways, feel free to check out my Youtube channel for more videos. And do subscribe if you feel that they're interesting. Nothing much is gonna happen in those videos, for now. But I hope things will get more interesting as I move on to AI & Turn-Based Logic. So, more videos will be coming up soon, and hopefully some tutorials in the blog as well before I myself forget what I've been doing. So here's a link to my channel:

Stormrage256' Youtube Channel

With that, I end this post. Feel free to comment below or mail me, if you need help regarding anything related to my work. And as usual, I hope to have a next post up soon.

Signing out.

------------------End of Captain's Log - 17th Jan 2015 (way behind schedule :|)-----------------