Monday, February 23, 2015

Unreal Engine 4 Dev Update #14: Real Time Grid Generation & Unit Attribute Effects

Hi, I'm back with another update. The project went through a major design change with this iteration. As I had mentioned many times before, the design of my game was heavily inspired by XCOM: Enemy Unknown since the beginning. Maybe it was because of the fact that I was playing it in my iPad right around the time I started messing with Unreal Engine 4. The fact that it was one of the few mobile games that I really liked might have contributed to it as well. Anyways, anyone who has been following my blog would have already noticed that my design and gameplay decisions were mainly based on the iOS version. Recently, I tried out the PC version of XCOM. I really like it, some parts better than the iOS version, while some not so much. Playing the iOS version first probably  was the culprit, but I saw certain design elements that just felt right in that version. Like how there was a command prompt before issuing movement commands, instead of the real time movement command in the PC version. And that thought inspired me to align my design direction in a way, that I felt would be able to incorporate the best of both versions. It finally resulted in me creating some backups, making some logic changes, stumbling upon some issues, again making some changes and finally writing this blog post. So without further ado, I present to you the next update:

Real Time Grid Generation

Before getting into the details, I'll just show you a screenshot of what it looks like in-game. It'll make it a lot easier to understand for those who haven't played XCOM.


As you see here, I have now replaced the localized grid system (active grid with all the adjacent valid grids) with a singular grid system. Now this obviously provides less details, if I were to show the cover data. But the current design, being real time offers faster data interpretation compared to the earlier model. So you can just move the grid around instead of clicking on any particular location to get the data. I now understand why the developers Of XCOM decided to use the localized touch event based grid generation for the mobiles. In order to negate the lack of real time grid generation, they decided to present more data to the player in one go. I still have the old system ready, just in case, I want to try it out in mobile devices later. 

Anyways, getting back to the update, the command issuing works similar to what it was earlier. As in, you need to click somewhere, then issue the move command in order to move the unit. I decided to keep it because, a real time movement command sometimes feels too quick when compared to the pace of the rest of the game. When playing the PC version of XCOM, I came across situations where I wanted to assess the situation based on my command order. Having the grid anchored to any particular space then gave me the freedom to see the whole game space from multiple angles before making my decision. I've also added the option to cancel the order so that the player can check out other options before proceeding any further. My final inference is that the game feels a lot smoother now. Here's a video to showcase the new grid generation system:


Fire Action Points

In an earlier update, I had talked about my implementation of movement action points. I've just extended that to include Fire commands as well. Unlike the movement commands, issuing a fire command does not subtract a certain value from the action points pool. It just directly reduces it to zero, meaning that's going to be the last thing that particular unit will do in the said turn. I have not explicitly stated it in the video, but you can see it in action in the video above.

Unit Attribute Effects

Again as mentioned in a previous post, I had added three basic sets of unit attributes: Aim, Health & Movement Points/Dodge Chance. And back then only the health actually mattered as far as the gameplay was concerned. Now I factor in all these attributes in, when I make gameplay calculations. The 'Chance to Hit' an enemy unit is now based on probability. A unit with higher aim has an advantage in that matter. A unit with higher HP can stay longer in combat. A unit with more movement points can tread longer distances in any one turn. And finally a unit with increased dodge chance has a reduced chance of being hit when it is fired upon. All mainly theoretical stuff, hence not much to show in terms of gameplay at this point.

And with that, another update comes to an end. The next update will be about the menu that I created with Unreal Motion Graphics (UMG). Until then, you can check out my Youtube channel (link below) for more updates. Feel free to like/subscribe if you're interested in the development of my game. Thanks for your time, and have a nice day.

Stormrage256' Youtube Channel

Saturday, February 21, 2015

Unreal Engine Experiment #1: Gravity Gun

A few weeks back, on one fine saturday, I decided to take some time off from my main project and do a small side project. I decided to do something using Blueprints that I could wrap up within a few hours. The plan was to then put the source in GitHub so that anyone else interested in it could build on top of it. Since I've been watching some of the 'Spoiler Warning' Half Life 2 episodes around that time, I was kind of all excited about the game once again. Probably because of that, there was only one thing that I wanted to make: a Gravity Gun. But I knew that it needed physics, and I haven't done shit with physics in UE4. So I did some R&D on the basics, and came upon a tutorial by Epic's T.J. Ballard in the Unreal Wiki, for lifting objects and such. Here's the link for the tutorial:

Unreal Wiki: Pick Up Physics Object Tutorial


Most of the building blocks that I needed for the project, were already laid down in this tutorial. I went through it, studied what did what, and luckily he had explained everything quite well. I just made some changes to it, in order to reflect the primary and second fire of the Gravity Gun from Half Life 2.



Within a few hours, it was well and working, except for too much momentum and rotation calculation issues for the physics object. Increasing the mass of the meshes fixed the momentum issue, but the rotation issue would require more work. But I got the basic functionality working. Here's a video of it running in the editor:


It's still not complete. As I mentioned, it's still got some issues with physics calculations. About a week back or so, I uploaded the source code into GitHub. It's available as free download for anyone interested in it. So anyone wanting to check it out or fix it up and use in their projects, can get it from here:

GitHub: Unreal Engine 4 Gravity Gun Experiment

Alright, that's all for now. Feel free to ask in the comments, if you've got any doubts regarding it's implementation. 

Tuesday, February 17, 2015

Unreal Engine 4 Dev Update #13: Added Movement Action Points & Automated Turn End Logic

In my last update, I had talked about my implementation of path distance based grid mapping. Following in it's wake, I started working on implementing action points for unit movement. I'm working on a system similar to what's done in XCOM: Enemy Unknown. For those of you who haven't played that game, it means that the nearby grids have a movement cost of 1, while the long distance accessible grids cost 2 movement points. All units get 2 movement points by default at the start of a new turn.

So getting back to my implementation, I started off with adding an action point attribute for all units. Every unit will have 2 movement points at the start of the game and it will be refilled at the start of every new turn. The fire command is also supposed to draw from the same pool of points for it's execution. However, at the moment, the fire commands are free of cost. Only the movement is restricted to the availability of action points. Based on my grid mapping logic and the player input, I'm getting the cost of movement for any targeted location. If it's in the blue grid space, I subtract 1 action point and move the unit to the location. Since the unit will have 1 action point left, it can move once more, but it will be restricted to only the nearby grids this time. On the other hand, if the target location lies in the yellow grid space during the first movement command, the unit loses both it's action points on command execution. As soon as any single unit has depleted it's action points for the turn, the AI controller checks if any other units have action points remaining and possesses the first unit that satisfies the condition. The camera then moves to focus on the newly possessed unit.

However, if no unit has action points left during the check, the end turn logic is automatically called in. The enemy AI Logic is turned off at the moment, so it just prints out a string. Following that, control reverts back to the player as all of his/her units receive full stack of movement points. The AI controller then possesses one of the player units and camera moves to focus on the said unit. There's nothing new to be shown with screenshots here. So I'm going to leave a video to demonstrate the functionality:


Alright, that's all for this update. I'm kind of exhausted from trying to get some new features working. So I'm going to have the rest of the updates in another post, after I get some time to make the next dev video. Feel free to check out my Youtube channel for more videos. See you at the next post.

Sunday, February 15, 2015

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.

Inheritance

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.



Saturday, February 14, 2015

Unreal Engine 4 Dev Update #11: New Character Models, Unit Highlights, Mouse Based Unit Selection & Context based HUD system

Finally, for once, I've managed to put a development update within the deadline mentioned from my previous post. Alright, we're having a cluster of small changes for this one. So let's get right down to it.

New Character Models

   
I had started off this project from the Top Down Template. So I've been using the default Unreal Engine character until now. A while back, I had bought the 'Prototype Characters' pack by Ying Pei Games from the marketplace. Since they fit the theme of my game better than the blue guy, I decided to use them for my units. Blue for the good guys, and red for the bad guys. If you've been following my posts, you might have come across the fact that I'm already using Epic's Animation Starter Pack in my project. I had some of the basic animations running already, so I did not have much work with adding the new models after re-targeting the skeletons. Here's an in-game screenshot:
   

And here's one up-close:




Unit Highlights and Health Display

Up until now, there was no cue when the cursor was focused on any interactive object, say, when I hover it over an enemy unit. So I decided to add unit highlights for enemy units. The idea was to have them highlighted, when the mouse cursor is over them. I'm using 'Hit Result under Cursor' and Custom Depth with a highlight material to achieve this. I actually got this idea from Tom Looman's Switch Development Blog. He's got a tutorial for the same as well. And btw Switch is probably the most awesome UE4 project that I've seen so far. It's hard to miss for a UE4 developer, but if you haven't seen it already, I'd highly recommend it. Here's a link:

Tom Looman - Switch Development Blog

Anyways, once I got the highlight working, I decided to add a Health Bar over the highlighted unit. So I got into UMG, made a health bar widget and added it to the character blueprint. At the moment, it's using a progress bar that changes according to damage received. You can see it in action in the video link towards the end of the post. I've also made the floating health bars to always face the player, no matter which angle he/she is looking from. For player units, I set these health bars to be visible all the time.
  
  
Mouse Cursor based Unit Selection

As mentioned in one of my previous posts, I've been using the number keys to select different units under the player's control. Being able to select units using the mouse was part of the plan for a while. So I just added that as well. Feels a lot better to use it this way, compared to the keyboard. Again, this is being demonstrated in the video as well.

Sounds Effects for Weapons Fire

As the title suggests, I've added the weapon fire sound effects from the Shooter template. I just play them along with the muzzle flash emitter when a unit starts firing upon another unit.

Context based Command HUD System

Lastly, I added a context based HUD display system. What that means is that, the interaction with the Command HUD happens based on what the player is trying to do. Right clicking on a location on the grid space to move the player only allows the player to interact with 'Move' button and 'End Turn' button. Similarly, right clicking on an enemy unit will allow the player to issue only 'Fire' commands and 'End Turn'.

Alright, so that's all for this update. Here's the video demonstrating the features that have been added, as per this update:


You can check out my other videos from my YouTube channel (link given below). Feel free to subscribe to my channel, if you're interested in the development of my project. And have a happy weekend.

Thursday, February 12, 2015

Unreal Engine Dev Update #10: Meet my new Player Character - The Camera

As usual, it's been a while since I put up a development update. In my previous update, I had mentioned that I made some major changes to my project. Oh and btw, since this is basically a learning project for stretching my understanding of game design, I'm just calling it Project Horizon. Current plans are that I'll be releasing it for free. This is kind of an experimental game project for me. So I'm just gonna through around some stuff at it and see if they work. Alright let's get back to the changes. First of all, I'll just note down the two major changes here:
  1. I've set the RTS Camera in my game as the default player character. 
    2.  A new AI Controller to control the player units.
                        
So I'll get to the first one in detail now. For starters, I've been using my player units as the default characters in the game. And that would seem like the sensible thing to do. Accessing the active player units are also a lot easier that way. And as mentioned in my previous posts, I've been using a custom RTS Camera (not the one that comes with the default character in Top Down Template) to move around the map. I noticed that when I'm playing the game, I'm just moving around the camera most of the time, while issuing commands based on a UI. It's almost as if the camera is the unit that the player is controlling. It's the only thing in the game over which I have almost constant control. The units that I command, move on their own and fire on their own, once I issue commands to them. And that kind of leads to the thought behind the reasoning for the second change. But getting back to the camera implementation, I'm still using a character blueprint for the camera. As a result, I can easily access the camera from any place. And I'm doing that a lot since I need it to automatically follow the units when they are executing their commands. But apart from this change, the core functionality of the camera remains the same as before. I had written a brief account of it's implementation in one of my earlier posts. Feel free to check it out here:

Unreal Engine 4 Dev Update #7: RTS Camera System for Top Down Turn-Based Games

Now let's get down to the second major change. As mentioned above, I'm currently using AI Controllers to control all the units in the map. One version for the AI  and another for the player units. And why would I do that? Two reasons: Utility and Efficiency. The Utility comes in the form of Behavior Trees. The AI Controller puts the power of Behavior Trees at my disposal. I did not have this luxury when I was using a player controller. The Behavior Tree enables me as a developer to not spend unnecessary resources on checking player state, since it can take care of it much more efficiently. The code that I had implemented prior to Behavior Trees for handling player state involved checking lots of conditions at every tick. Basically, the logic was not simple. It was not elegant. It was the type of code, that you want to change right from the moment you implement it. I was happy to push all of it into the Behavior Trees. So in hindsight, it is the transference of the player unit control to the AI Controllers that propelled me to use the camera as the default player character. It took some time and confusion to get through these changes. But things look a lot cleaner now. Plus the game is working fine. And I'm actually happy that I got rid of that code. Before I end this post, I hope this will do justice to the title:
                   
  
With that I'm rounding up this update. I don't have any videos directly related to this as both these changes were mainly under the hood. The gameplay basically remains the same as before. There have been a lot more changes since, but I think I'll have them in another post. Meanwhile feel free to browse through my Youtube channel (link below) as I've already uploaded some of the new gameplay videos following this update. 


Alright that's it for now. I'll hopefully have another update before the end of this week. See you soon.