Skip to main content

Unreal Engine 4 Dev Update #12: Path Distance Based Grid Mapping, Inheritance & Unit Attributes

Welcome back for another update in a series of steady barrage of dev logs, where I'm trying to catch up with the actual development process of my game. We've got one major update for grid mapping and a couple of other minor updates. So let's get to the important one first:

Path Distance Based Grid Mapping

Well tackling this one has been in my peripheral vision since the beginning. Now that I've got some of the other systems implemented, it made sense to jump right into this. As you may have seen in some of my videos, pathing had only a single rule until now: grid based movement. It didn't differentiate between short distance movement and long distance movement. And now, the grids change color according to the distance. At an aesthetic functionality level, it's very similar to the mobile implementation of pathing display in XCOM: Enemy Unknown. When a player clicks anywhere on the navigable space, it calculates the distance and spawns grids in that region based on it. Grids closer to the player are depicted in blue, while the longer accessible ones are displayed in yellow color. Go even further, and no grids are spawned. One thing to note is that, grids accompanying the center blue grid will all be blue; meaning only those on the same category as the center grid are spawned. If any of the surrounding grids fall to the long distance category, it will only spawn if you click on that side of the fence. In order to show this more clearly, I've added a couple of screenshots.

Short Distance Grids (Blue Color)

Long Distance Grids (Yellow Color)

A working implementation of this feature is shown in the video at the end of the post. You may notice that I'm using the default models in the video. This is because I had uploaded the video quite a while back, so some of the aesthetic changes are not implemented in it. Now let's move on to the second update.


I have been using separate character blueprints for my player controlled units and AI units. Since I was planning to add unit attributes that function pretty much the same way for both parties, I decided to reparent both of them to a single custom base character. Similarly, I based both my AI Controllers off of a new base AI Controller. Same goes for the weapons, even though I have only one weapon at the moment. This is already making it easier for me to make changes that are reflected throughout the game. I also restructured the entire folder system, which was a royal pain. If it was just moving around to new folders, it would have been fine. But lot of the code got messed up with references going here and there. Since I had a backup, I checked that to create most of the Blueprints from scratch again, mapped them to folders and changed their names according to functionality. I'm just happy that I didn't delay this any further, because I really do not want to do this shit again. It is a totally boring process with no fun element or reward, except at a very abstract level. I highly recommend anyone planning to make a game in blueprints, to get this sorted out as soon as you have a base idea. Add more stuff keeping this in mind, even at a mid tier prototype phase. Always.

Unit Attributes

Well, this has been exciting. Being a fan of RPG games, it felt good to actually make custom attributes for my game characters by myself. Even the thought process that goes into it is very interesting. I wanted to restrict it to 4 sets of attributes from the beginning, leaving aside stuff like critical chance. I'm only talking about base attributes like health over here. It was more like a internal mind debate between which attributes made more sense, and which of them needed to be chucked out. Finally I settled with the following attributes: Aim, HP and Movement Range/Dodge Chance. Movement Range and Dodge Chance kind of fall under the same set for my game, since I've kind of made them as a single package feature. The fourth attribute which I've already decided hasn't been implemented yet. It's a bit higher level attribute that I want to test with EQS first. So I'm gonna wait for it until v4.7 hits the marketplace. These attributes do not impact the gameplay as of now, except for health which was very briefly shown in the video from my last update.

Oh and here's a video showing my implementation of Path Distance based Grid Mapping:
With that, we come to the end of another update. As always, feel free to check out my YouTube channel (link below) for more dev videos, and do like/subscribe if you find them interesting. Thanks for you time, and goodbye.

Popular posts from this blog

Unreal Engine Tutorial: Create Circular Ring Material without Textures

Hi, welcome back for another tutorial. It's been quite a while since I put up a tutorial as I've been busy working on toolkits for the Marketplace. One of my earlier tutorials [link: Unit Selection Decals for RTS Games] had focused on how to create ring materials using textures, as well as using them to display unit selection decals for RTS games. However, a drawback associated with using textures was that it prevented the user from changing the inner & outer radius of the ring. And during prototyping stages of a product, it's far better to implement structures that can be changed easily from within the engine so that you don't have to create a new asset from an external package every time you need to test out a new idea. I've found this approach quite useful while working on my own products. Hence, this tutorial focuses on creating a ring material that can be adjusted both from within the material editor as well as dynamically at runtime.

Alright before we get …

Unreal Engine Diaries #11: Nav Mesh Configuration

[This episode of Unreal Engine Diaries focuses primarily on nav mesh configuration, nav areas & configuration of agent types.

Source: Unreal Engine 4 AI Support Twitch Broadcast with Mieszko:]

1. The Recast NavMesh has a couple of attributes named 'CellSize' & 'CellHeight' under the 'Generation' section in it's details panel. Together they determine the resolution of the nav mesh & lowering these values can create more precise nav meshes. It could be especially useful when there are lot of holes in the nav mesh due to the surface properties of the terrain. However, lowering them also makes the nav mesh calculations more expensive.

2. If runtime nav mesh generation is enabled, it would be best to set the 'Tile Size' attribute of Recast NavMesh to the minimum viable amount.
3. The 'Min Region Area' parameter which can also be found under 'Generation' section of Recast NavMesh can be i…

Unreal Engine 4 Tutorial: Smooth Zoom using Mouse Wheel for Top Down Template

Well, I had already written a tutorial for implementing Smooth Zoom functionality for Top Down Template. But it was based on keyboard inputs. Since most Top Down PC games use mouse wheel for zoom, I decided to make a tutorial for the same. The core logic here is the same as the one implemented by Ryan Jon for the custom camera in his RTS Community Project. If anyone's interested, they can get the code for the RTS Community Project here:

UE4 RTS Community Project

Anyways, he has replaced the default camera for the characters with a general camera since that's more ideal for developing an RTS game. Since a basic Top Down game with a single playable character does not need a separate custom camera, I decided to implement the same functionality for the default player camera in UE4's Top Down Template. So let's get down to it.

First of all we need to make a custom curve from the content browser. We will be using this curve to define the smooth camera movement while zooming …