Unreal Engine DevLog #22: Reaction Shots & Prototype Cover System

I've been meaning to write down this dev log for quite some time. It's the last update on the X-COM:EU clone prototype that I was working on a while back. I would love to return to working on it sometime later, but for now, I'm concentrating on making tool kits for the Unreal Engine Marketplace.

The last update on the project was about an LoS based visibility system, which is covered here: http://unrealpossibilities.blogspot.in/2015/07/unreal-engine-devlog-19-line-of-sight.html

Since then, I had implemented Reaction Shots for the player controlled units, as well as a prototype cover system that displays the cover value of each corner of every tile.

Reaction Shots Preview Video:



Prototype Cover System Preview Video:



So that's going to be the last update on the project for quite some time. It's been a great learning experience for me as a starter experience in Unreal Engine 4. Also special thanks to Knut Overbye for creating one of the best products in the Unreal Engine Marketplace, without which the project wouldn't have made it this far. I've provided a link below to his toolkit. Feel free to check it out: ttps://www.unrealengine.com/marketplace/advanced-turn-based-tile-toolkit

FPS Tower Defense Toolkit v4.11 Basics: Wave Spawning Systems

The FPSTDT's Wave Handler class (starting with v1.4) supports 3 types of wave spawning systems: Unit Based Generator, Group Based Generator & Threat Based Generator.

1. Unit Based Generator

Provides maximum direct control over the wave spawning systems. Best suited for creating games with small waves by setting the properties of every unit on an individual basis. 

- The 'Enemy_Type' variable provides a dropdown to select from any of the 3 default enemy units.
- The 'Delay' variable determines the spawn time of the unit relative to starting time of the active wave.
- The 'SpawnPoint' variable can be used to choose from any of the available 'BP_EnemySpawnPoint' actors in the level.
- The 'WaveNumber' variable specifies the unit's associated wave number.



2. Group Based Generator

Provides good control over the wave spawning systems and easier to test different wave formations. Bots are spawned as automated groups and hence best suited for games that require large number of units in a wave, while still providing designers with the control of the unit types and the number of units in a group.

- The 'Enemy_Type' variable provides a dropdown to select from the 3 default enemy units. A group can contain only bots of a particular enemy type.
- The 'SpawnDelay' variable can be used to specify the time delay between spawning of each bot in a group.
- The 'SpawnPoint' variable can be used to choose from any of the available 'BP_EnemySpawnPoint' actors in the level. All units in a group will spawn from this spawn point.
- The 'WaveNumber' variable specifies the unit's associated wave number.
- The 'SpawnStartingTime' variable determines the starting time for spawning the first unit in the group, relative to the starting time of the active wave.
- The 'NumberOfUnits' variable specifies the number of units in the group.


3. Threat Based Generator

Provides least direct control over the spawning system, but facilitates automated generation of random wave formations. Bots are spawned randomly based on the specified enemy types until the threat level of the wave reached the specified value.

- The 'Enemy_Type' variable can be used to select all the bot types to be considered while generating the wave.
- The 'Delay' variable can be used to specify the time delay between spawning of each bot in a group.
- The 'WaveNumber' variable specifies the associated wave number.
- The 'ThreatRating' variable determines the maximum threat limit of the wave. Can be used to increase the difficulty of each wave automatically.




In order to facilitate creation of large number of waves, the 'NumberOfCycles' variable can be used to repeat the waves for a specified number of times, each cycle increasing the health of enemy units based on the active cycle number. Setting this number to zero can be used to create Endless waves.

Unreal Engine Diaries #10

  • To display the AI Perception range in the editor, go to Editor Preferences >> General >> Gameplay Debugger & tick the 'Perception' parameter. Also in post processing, set AA to 'FXAA' or none to display the debug lines better.

  • In the widget blueprint, select multiple widgets from the Hierarchy panel & then Right click >> 'Wrap with' to wrap the selected widgets within another widget like Canvas Panel, Border, etc.

  • Add 'Rotating Movement' component to actors to have them rotate automatically. The rotation rate for each axis can be set from the component. This could be used to create interactive objects like weapon pick ups in a shooter or effects like rotating coins in a side scrolling game.

  • Wrapping widgets with 'Invalidation Boxes' can be used to increase performance as they get executed only at the time of creation & not every frame unlike other widgets. This could be especially useful when there are lots of static UI elements that do not get updated at run time.

  • The 'Random unit vector in cone' node can be used to get random line trace target locations for creating shotgun spread patterns.

VR Tips Compilation #2

As mentioned in the previous post, I've been collecting tips about working with VR from the Unreal Engine Livestreams & GDC Talks. This is the second of the two VR Tips Compilation posts, while the first one can be found here: https://unrealpossibilities.blogspot.in/2015/12/vr-tips-compilation-1.html

  • Using force grabs to get objects from the environment is a good alternative to actually having the player grab the object, due to the awkwardness & differences between how it works in real life, compared to the lack of physical feedback in games. Also adding to this factor is the design of the control device used to accept inputs.

  • Remove all motion blur effects as using them in your game can give rise to Simulation Sickness.

  • Since run & gun is generally not an option in VR games, teleportation is one of the interesting viable alternatives. But even here, it is better to slowly fade the screen to back & then fade everything back in at the new location, instead of instantaneously shifting the player from one place to another.

  • In Unreal Engine, it is better to use screen reflection captures & disable screen space reflections from the post processing features.

VR Tips Compilation #1

I've been collecting tips & advice about working with VR, from the various Unreal Engine Livestreams & GDC Talks. Even though I myself have never even used a VR device, it seemed like a good idea to get to know more about it from the people who are already working on it. This post is the first of two VR tips compilations based on the data that I've collected so far. 

  • The first and most important thing that I've heard in almost all the talks is to never take the camera control away from the player. This would mean that traditional methods like moving the camera to shift the player's focus on to important game events, would probably be a bad idea. So would changing the camera angle to reflect the action from different perspectives.

  • Many games use Depth of Field & changing Field of View to zoom in on important/relevant targets while blurring out the edges. It seems that this is not going to be of much use when working in VR. Players might create this effect naturally by closing one of their eyes while aiming at a target. It would be a better practice to cut down on the rendering costs of DoF & use it elsewhere where it's truly required.

  • When fading the screen, it's better to fade to black than fade to white. Unlike reality, the player cannot put his hands to cover his eyes if the screen is too bright. On the other hand, if they move their head as a natural impulse, it wouldn't create the necessary response thus creating a break in immersion. And I believe that immersion could be the most important advantage of VR, and when it breaks, it's probably going to be more frustrating than in traditional gaming experiences.

  • During this early stage of VR, when the general public haven't been accustomed to the experience enough to make it feel natural, it would be a good idea to not make the experience too scary. Again, the natural response of covering your eyes don't work here & that could potentially create unfavorable experiences.

With that, I conclude the first post. The second and final post should be uploaded soon.

Unreal Engine Diaries #9


  • 'Shift + F1' can be used to gain mouse control & jump between the different game instance windows during multiplayer testing in the editor.

  • While working on VR, try to match the size of in game objects to their real life counterparts, as not doing so could make them stand out and reduce the immersion.

  • In the Material Editor details panel, turn on 'Fully Rough' [prevents reflection rendering pipelines from executing] & turn off 'Light Map Directionality' [both under the the 'Mobile' category] to make materials that are less expensive to render.  This is a pretty good option when dealing with far away objects in the level that do not require a lot of detail. Setting the Shading Model to 'Unlit' can also increase performance in instances where the additional detail is not required.

  • In PIE mode, press 'Ctrl + Shift + .' to bring up the GPU Profile. It would be a good idea to start looking for elements that cost more than a millisecond.

  • 'Switch has Authority' can be used to determine who is executing the script: the server or the client.

Unreal Engine Diaries #8


  • When adding new input parameters to a function that's already being called multiple times throughout the project, it's always better to immediately check every instance of the function call to make sure that the new input parameter is connected as required.

  • Drag & drop a variable from the variables list onto a get/set node of another variable to automatically replace the second variable with the first.

  • When attaching moving physics actors to the player character without physics handles, disable it's gravity & set the linear/angular velocities of all of it's components to zero in order to have it simulate physics & collision on the move.

  • Under default conditions, when a character changes it's direction of movement, it instantaneously turns to face the new direction. To change this behavior and enable smooth rotation based on direction changes, first go to the AI character blueprint >> Character Movement Component >> Enable "Orient Rotation to Movement" & set "Yaw" of the "Rotation Rate" based on how smooth the bot turning movement has to be. Then under the default attributes of the blueprint, disable "Use Controller Rotation Yaw" and it should now start having smoother turning movements.

  • If you're experiencing automatic brightness changes in your game, you can disable this effect by going to your viewing camera component >> Post process settings >> Auto Exposure >> Set min and max brightness to the same value.

Unreal Engine Diaries #7

  • While working on the Top Down Stealth Toolkit, I noticed that sometimes the character animations that worked in the PIE mode did not work in the Standalone mode. One of the solutions that worked for me was to connect the 'Event Blueprint Update Animations' in all the child anim BPs to their parent update animation events.
  • To find the angle between two rotator variables, it is better not to use normal subtraction to get the difference as this could give odd results in certain scenarios owing to the fact that the rotator values for actor rotation and world rotation follow the (0,180) & (-180,0) range. For example, when you add two positive values, it could produce a negative output and vice versa. In order to work around this situation, the 'Delta (Rotator)' node can be used to get the absolute angular difference between the two rotators.
  • When working on Top Down games, the 'Orient rotation to movement' parameter in the character movement component of the player character can be unticked to have it face the direction of mouse cursor instead of the movement direction.
  • The following method can be used to get the dimensions of a landscape actor:
    1. First create a reference to the landscape actor either through the level blueprint or using the 'Get All Actors of Class' function.
    2. Get the landscape actor reference and then use 'Get Actor Bounds' function to get the box extent.
    3. Break the box extent vector into it's float values representing the magnitude on each axis and then multiply each by 2 in order to get the length, width and height of the landscape actor.
  • In the default First Person template, if we do a line trace towards the world space equivalent of the center of the screen, it could be seen that the impact location of the trace and the crosshair location on the screen are offset by a certain amount. This is because the logic used to draw the crosshair on the screen from the HUD class does not take the texture size of the crosshair into account during calculations. To rectify this issue and display the crosshair at the true center, we can subtract both x and y location by half the corresponding dimensions of the texture used for crosshair, before plugging it into the draw texture function. In the default case, that would mean subtracting both by 8 units. Doing so should make sure that the trace hit locations match with the crosshair location.
    [ExtendedFirstPersonTemplate_PreciseAim Project Files link: http://unrealpossibilities.blogspot.in/2015/10/extended-first-person-template-improved.html]

Unreal Engine Diaries #6

  • In the editor, you can select actors from the 'World Outliner' panel, right click and select 'Move To' >> 'Create New Folder' to group your actors into a folders. 
  • The 'Project World to Screen' function can be used to check if any point in world space lies within the screen space of a player's camera view. Just pass on the said world location and the player controller reference as input parameters and you can get the corresponding screen position data as the output. Break this struct into it's x and y values, then use the 'Get Viewport Size' node to get the actual screen bounds and check it the aforementioned screen position values lie within 0 and the screen bounds values that we just received using the viewport size. If both x and y values lie within this range, then the point is within the visible screen space, else it's outside the camera view.
  • When adding a vector to an actor's world space location to get the vector result of a location near the actor, do not add them using the values that you'd want to increase in the x, y and z directions. It only works in the relative location calculations. What you see as the forward direction in the actor blueprint viewport may not be the same as the forward direction in the world. So in this case, what we need to do is get the forward, right and up vectors. Then multiply them with the required distance along each direction and add/subtract this vectors from the main world space location.
  • The console commands 'stat startfile' and 'stat stopfile' can be used to record the performance stats of all gameplay logic that happens between the commands. On completion, it saves the data to a new file in the HDD. In order to retrieve this data, go to the 'Windows' tab in the editor >> Developer Tools >> Session FrontEnd >> Profiler Tab and click on the 'Load' Button. It'll take you to the folder location where the file was saved. Open the most recent file in the folder to see the visual representation of the performance stats of the CPU [Game & Rendering thread] as a graph in the editor. Select any part of the graph where it's spiking and see all the game logic and rendering processes that's being called within that timeframe, to get an idea of what's causing the performance drops in your project.

Unreal Engine Diaries #5: GPU Profiling & Rendering Optimizations

  • The 'profilegpu' console command can be used to profile the GPU for a single frame.
  • The 'r.xxxxx ?' command can be used to get the tool tip for the particular rendering command that is being passed on as parameter.
  • Shaders can get really expensive when using World Position Offset and Tessellation. And speaking of World Position Offset, it can be used to manipulate the vertices of a mesh from it's material.
  • If there are lots of skeletal meshes in a game, the 'SkinnedMeshComp Tick' can get expensive. Reducing the number of bones of the skeletons or the complexity of the anim blueprints can help improve the performance in these scenarios. Also if you do not need the animation to update when you can't see the skeletal mesh consider setting the 'Mesh Component Update Flag' in the details panel of skeletal mesh component to 'Only Tick Pose when Rendered'.
  • The 'Smoothed Frame Rate' option in the Project Settings [under General Settings category] is used to render a No VSync frame capped version of the rendering. While doing GPU Profiling, it's a good practice to test it out without using this Smoothed Frame Rate.

Unreal Engine Diaries #4


Material Editor: In the material editor, we can add the 'Noise' node to display noisy patterns on the surface of a mesh. However it's very expensive and hence best used for prototyping or in rare scenarios where using an actual texture isn't justified.

Material Editor: The 'Particle Position' node can be used to get the location of a particle in space.

AI: The 'Bind Event to ReceiveMoveCompleted' in the AI controller can be used to automatically receive the status of a bot once it has completed it's movement order. It's got different states like success, aborted, blocked, invalid, etc and these can be used to have the AI respond to different situations with different behaviors. But if we have multiple events waiting for it's reply from different places, like say from different tasks in a Behavior Tree, all these bound events will start executing. And that might not be a desirable outcome. So in order to work around such a scenario, it would be a good idea to have a check on the current state of the bot in all these events and proceed based on that result. This could help ensure that even thought multiple events maybe fired, only the one that is suitable for the current state of the AI will see through to it's completion.

AI Perception: When using the 'OnPerceptionUpdated' event to detect potential targets, you may have noticed it does not give any details regarding the location of the source of the stimuli. But there is actually a method to retrieve this data. Just loop through this array of actors and for each actor, get it's actors perception ['Get Actors Perception' node], then break down it's output 'info' struct and loop through the 'Info Last Sensed Stimuli' to get all the necessary details like stimulus location, age, tag, etc.

Editor: Press 'Alt+C' in the map editor to see the collision data for all the meshes.

General: In Unreal Engine, most of the physics calculations are done by the CPU.

Unreal Engine Diaries #3

  • If we're displaying the game over screen as a widget that's added on to the viewport while the game is running, make sure that the game is paused using the 'Set Game Paused' command. Not doing this would mean that the actors in the level are continuously being updated in the background. Now sometimes it's fine to have the enemy actors move around the screen in the background, but even in those scenarios, it'd be a good practice to make sure that any constantly updating game element that's part of the player character/controller are turned off. An easy example to think of would be an actor in the level that is responding to the mouse cursor. So it might move around the screen, even while we're trying to click that restart button.
  • When creating a widget from within a task in a Behavior Tree, it's a good idea to make sure that it's not being called continuously. It's generally better to create widgets outside the task flow, within normal blueprints, but certain situations might demand widget construction from within Behavior trees in order to use some of it's functionalities that are not natively available in the blueprints. In such situations, there is a way to handle UI changes from the behavior tree tasks. Just add a 'Do Once' node inside the task before calling the widget construction logic. This makes sure that the subsequent iterations of the task don't create the widget unless explicitly specified. In my project, I've used this only in an end game scenario as one of the conditions for it was handled from within a Behavior tree task. It has since been replaced with a game pause call. So this makes sure that the Behavior Tree stops executing altogether, but the 'Do Once' node might be useful in other situations where you can't pause the game.
  • The world rotation of actors in a level, when broken down into their  x,y,z components lie within the range of (0,180) & (-180,0). When doing calculations based on actor rotation, this change in the values from positive to negative have to be taken into account. If we treat it like normal repeating cycles of (0,360), it might yield strange results in certain types of calculations.
  • When aborting a subtree in Behavior Trees, any task within that subtree that is actively running at that moment will not be aborted midway. It will see through to it's completion and if the task has delay conditions or code that changes some important data, this could lead to unexpected results if not taken care of. However it is possible to shut down these tasks at runtime through the use of conditional checks that gauge the current state of the game based on some external variable or blackboard values. Once we have determined that the task is to be aborted, we just call the 'Finish Execute' node to stop and get out of the task.

Unreal Engine Diaries #2

  • Useful Material Editor Hotkeys [Press these keys & click anywhere on the mat editor]: B = Bump Offset; E = Power; I = If condition; O = OneMinus; P = Panner; S = Scalar Parameter; U = Texture Coordinates; V = Vector Parameter
  • If you change any of the member names of a Struct in the Content Browser, the connections from the aforementioned members in all blueprints will get cut. As a result, you'll have to go around each of these blueprints and manually connect them again. So it helps to actually note down where you need to reconnect before making changes to a Struct.

    Also note that in v4.8 of Unreal Engine, these renamed members will have their input pins invisible the next time you check out those structs in your blueprints. In order to make make them visible again, click on the struct >> go to the details panel >> tick the checkbox next to the changed element to see it again. You'll however have to do this for every instance of the said struct.
  • An Unlit material means that we are only dealing with the Emissive and Opacity inputs.
  • Useful Material Nodes:

    The 'Radial Gradient Exponential' node can be used to create a circular gradient.

    The 'Particle Color' node provides data about the current color of a particle.

    The 'Depth Fade' node can be used in materials of particle emitters like Fire to have them smoothly fade away when they come in contact with any meshes. This node when connected to the opacity helps remove the hard edges which would be otherwise evident when a mesh obstructs the emitter.

Unreal Engine Diaries #1

  • When you're calling the function 'Get Random Point in Navigable Radius' [see link below], make sure that you store the vector return value inside a variable if you intend to use it in multiple scenarios later down the line. Otherwise, it ends up creating different randomized vectors each time it's used even though you're taking the same return value. It's kind of obvious as those are different function calls, but sometimes in the heat of the battle, it's easy to overlook small things like these.
  • Blackboards can be cleared from within blueprints using the 'Clear Value' function [see link below]. This is especially useful in scenarios where you're dealing with vector blackboards. Setting it to zero in this case is not ideal as it actually represents a location in the game space. 
  • Basic workflow for creating splines: Create a spline component in your blueprint >> Set it's world points by passing in the vector data [see link below] >> Add a spline mesh component >> Set static mesh >> Set material for the mesh >> Get the location (and tangents, if necessary) at the stored spline points [see link below] and use this data to set start/end points as well as tangent vectors for the spline mesh. [Do a for loop with the spline points data, if you have more than two points]
  • Select a group of blueprint nodes, right click and select 'Collapse to function' to have the editor automatically create a function encompassing those nodes.
  • It is possible to increase or decrease the rate at which an animation is run, by adjusting the Rate Scale in the details panel of the anim sequence.

Documentation Links: 

FPS Tower Defense Toolkit for Unreal Engine Marketplace

The FPS Tower Defense Toolkit is a pure blueprint framework that enables quick & easy creation of Tower Defense games from a first person shooter perspective.

Unreal Engine Marketplace Product Page: https://www.unrealengine.com/content/6f8c5ece7d39402b8b402119a9798eb6

Official Unreal Engine forum support thread: https://forums.unrealengine.com/showthread.php?79300-FPS-Tower-Defense-Toolkit

Preview Video:




Features:


- Basic FPS Movement & Combat. 

- Seven types of Towers: Tower Base, Shockwave Tower, Machine Gun Tower, Laser Tower, Sniper Tower, Boost Tower & Trap. 

- Three types of Enemy AI: Core Bomber, Melee Bot & Ranged Bot.

- Three types of AI Wave Generation systems, with support for endless waves & repeating wave cycles with dynamically escalating difficulties.

- A Focus Fire system that enables the player to request towers to focus fire on a designated target.

- Automated resource allocation between waves provide players with the abilty to Build, Upgrade, & Sell towers. 

- A Mission Stats system that provides the player with the damage & kill stats information at the end of a level. 

- Spline driven navigational paths display optimal enemy AI routes from the spawn points to the Power Core. 

- Includes a loadout menu at level start with player driven tower selection.

- Modular Grid Generators with drag & drop support to create grid cells for tower placement. The Grid Generators support grid snapping & 360 degree rotational freedom, thus facilitating placement of towers & traps on inclined surfaces & walls.



Technical Details:

- The Wave Manager allows complete customization of waves through parameters like EnemyType, NumberOfUnits, SpawnPoint, SpawnDelay, etc. 

- Variables are categorized into 'User Defined' & 'Automatically Set' to facilitate identification of customizable parameters.

- The Enemy AI is driven by a combination of modular components, thus facilitating the creation of new types of AI bots with ease. 

- The Creep AI Manager keeps track of all potential targets for the creeps, thus freeing them to focus directly on the targets. 

- The Game Mode handles initialization of all core gameplay actors from a single central location using a linear workflow design.

- The Player Controller acts as a conduit for all low level HUD update requests, while the Game Instace & HUD classes manage high level HUD changes.

- AI Spawn Points support precached & runtime generation of randomized spawning locations.

- Event driven logic used predominantly over continuously ticking services for HUD updates.

- Blueprint function library employed to easily retrieve references to core gameplay actors from all blueprints.

- All static Tower parameters are store in a centralized Tower Data Array, thus requiring only dynamic parameters such as DPS, Range, etc to be stored within the tower actors.

- The Tower Selection menu is populated dynamically based on information specified in the Tower Data Array, thus eliminating the need for manual HUD changes when adding/removing towers.



Intended Platform: Windows

Optimized for: Unreal Engine v4.12 & v4.13

I have not tested the toolkit on Consoles/Linux/Mac OS. Theoretically it should be possible, maybe with some modification. But as it's not confirmed yet, I chose not to add that in the target platform.


Here are some preview screenshots as well:














Unreal Engine DevLog #21: Prototype UMG Menu Update 4.2 [Free Source Code]

Hey, I'm back with another quick update for my Prototype UMG Menu system. This update replaces the placeholder 'Load Game Button' with a working 'Continue Button', that loads the last played level from it's starting point. A new map has been added to demonstrate this feature and you can switch between the maps in-game using '1' and '2' keys. 

The button will be disabled when you first load the project. But once you load any of the levels, you'll notice that the 'Continue Button' will be enabled when you return to your Main Menu for the next time. But for this feature to work in your own custom projects, you will need to add the level names data to a new array in the Game Instance blueprint, and make some changes to the save game settings as shown later on in the post. So let's get down to the details about the changes.

Update 4.2

- Continue Button to load the last played level from the Main Menu
- Current Version: 1.4.2
- Optimized for Unreal Engine v4.7.6

Listed below are the changes to the different blueprints in detail:
  • As you can see in the screenshot, three new variables are added to the Game Instance blueprint. Some changes have been made to the logic behind loading levels, in order to incorporate the data necessary for the Continue button. If you're adding more maps or wish to add this to your own project, you will need to populate the 'MapNameArray' with your map names. This includes the Main Menu map name as well, which needs to be stored in index '0' of the array.
  • The 'SaveSettings' function in the Game Instance blueprint now saves the level index necessary for the 'Continue Button' as well.
  • Some extra text information displayed using the Game Screen Widget. Not necessary though.
  • New code in the Player Controller blueprint to tell the game instance to load new levels based on the player inputs.
  • Add the following code in the Main Menu Widget to facilitate the working of the Continue Button.
  • The following code saves the data regarding the current level index, when the player exits from a game level to the main menu or the desktop.

That's all for this update. As always, feel free to grab the source code at: https://github.com/Stormrage256/UMGMenuSystem



Unreal Engine DevLog #20: Prototype UMG Menu Updates 4 & 4.1 [Free Source Code]

Welcome to yet another update on my Prototype UMG Menu system for Unreal Engine 4. As always, it's free to use for both non-commercial and commercial purposes. No attributes required. You can find the source code at: 


The official thread in the Unreal Engine forums:
https://forums.unrealengine.com/showthread.php?63037-FREE-UMG-Menu-System-Prototype-Source-Code

Anyways, if you're using it for the first time, you can go ahead and grab the source right away. But please do let me know if you encounter any bugs in v4.7.6 or higher. The rest of this post details the changes made in the latest updates. So it's more useful for people who have been using an earlier version of this menu system in their projects already. So now that's out of the way, we'll first get to the changes made as part of the Update 4. 

Update 4

1) Persistent graphics settings across multiple instances: First of all, as promised, this update brings persistent graphics settings into the mix. That means that your graphics settings once changed will be saved and retrieved in future instances of the game. You do not need to keep on changing it every time.

2) Scrollbar Bug fix: I came across a bug that prevented scrollbars from closing down when the user is moving on to other menus. Well, that has been fixed and you will not leave any scrollbars hanging after this.

Listed below are screenshots depicting the changes made to various blueprints:
  • A new blueprint 'BP_SaveSettings' derived from the SaveGame class. After creating the blueprint, just initialize the variables shown in the class along with their corresponding values. Make sure that you give the 'SaveSlotName' variable a name to recognize the save game slot as shown.
  • 'Event Init' logic in the Game Instance blueprint. Copy the entire connected logic to your project. This makes sure that the game retrieves saved settings, every time you launch the game. If there are no saved files, it will go for the default values stored in the variables as before.
  • Add a new function 'SaveSettings' within the Game Instance blueprint. This function takes care of saving the current video settings. 
  • And here comes the final part of the logic for the save system. Just call the above function from the video settings widget when the user goes back to the options menu.
  • This next piece of logic takes care of the scrollbar bug mentioned earlier in the post. Just call the 'Collapse Scrollbox' function when returning to the options menu from the video settings menu. Same blueprint network mentioned in the previous screenshot.


With that, we're at the end of changes made in Update 4. I've released a very minor 4.1 Update to fix an issue that arises when you try adding this project into other projects.

Update 4.1
  • Create a new Game Mode blueprint named 'MainMenuGameMode'. Set this as the default game mode for the Main Menu map. Now under this game mode settings, set the HUD to 'BP_MyHUD'. Make the same changes in Project Settings >> Maps and Modes as well. That's all.

Alright, so that's it. It's currently built in v4.7.6 of Unreal Engine. I have done a couple of tests in v4.8.2 and it seems to be working, but I can't confirm yet until I do more tests. So if anyone comes across any bugs, do let me know. I thought that we'll put official version numbers from now on. So this one is officially v1.41 of the Prototype UMG Menu System and we have come to the end of this post. Have a great week.

Signing off.

Unreal Engine DevLog #19: Line of Sight based Visibility

Hi, it's been quite a while since the last dev log on Project Horizon (yes, got changed to a less generic name). I had been working on my FPS Tower Defense Toolkit and some other experimental stuff for a few months. The toolkit has been submitted to Epic Games for Marketplace review and we're done with all the agreements. There has been some delay as I had to convert my project to v4.8 midway and there had been an engine bug that I had to find a workaround for. With the new code submitted, I'm awaiting their response regarding further details. 

Meanwhile there had also been some major updates to Knut's Advanced Turn Based Tile Toolkit, which makes it much more optimized and well structured than before. So rather than integrate all those changes into my project, it was much easier to transfer my code into his updated toolkit. And that took a while to implement and finally it was time to add some exciting new features to the project. First in line, was Line of Sight based visibility. An earlier unannounced version of this was already working partially in my old project. So I ended up using that, did some optimizations and finally we have something that works pretty fine. It's using a mix of grid based calculations and collision meshes to achieve this. The grid calculations are mainly used in places where the LoS will have a direct impact on player actions. For scenarios which are mainly important from an aesthetic viewpoint, I've used a collision mesh to reduce the time calculations. It's quite accurate, but I need to add a small line trace calculation at some point in the future. So here's a video demonstrating the new feature:


That's all for this update. Next time, we're gonna see if we can add the Overwatch ability from XCOM: EU. Until then, goodbye and stay classy.


PS: For anyone interested in Knut's turn based tile toolkit, you can check it out here: https://www.unrealengine.com/content/a22867b136314748af7437c635b9ddba

The Precursors

I've been going through my Dropbox files to delete old unnecessary files and came across some of my first projects. They were all created using Unreal Development Kit and Blender and most were abandoned at some point. Just thought I'd put up some of the final screenshots here:

Helm's Deep and the Fortress of Hornburg




Temple Ruins




Castle on the Mountain


Unreal Engine DevLog #18: Prototype UMG Menu Update 3 [Free Source Code]

It's been quite a while since my previous post. I had been busy working on my FPS Tower Defense Toolkit for the Unreal Engine marketplace. It was submitted for initial review couple of weeks back, but then v4.8 came out and a certain engine bug in v4.8 prevents it from running one of the core functionalities in the toolkit. So I would have to wait until a fix arrives for it in one of the future updates. Anyways if you guys want to check it out, here's a video link to the preview:
  


EDIT: The FPS Tower Defense Toolkit is now available in the Unreal Engine Marketplace for $29.99: https://www.unrealengine.com/content/6f8c5ece7d39402b8b402119a9798eb6
   
Meanwhile, I had made some improvements to my Prototype UMG Menu while working on a freelance job. Just updated the first set of those changes to the Github source. Here are the major changes in Update 3:
  • General Optimizations for Pause Menu and Video Settings workflow
  • Bug Fix for loading screen freeze
  • Bug Fix for Video Options scrollbars populating duplicated child widgets
Below listed are the changes to the different classes in detail:
  • In Game Actor

  • In Game Menu Widget
  
  • Player Controller
   
  • Video Options Screen Widget
  

Well, that's all for this update. The next update will include persistent settings using automatic save functionality. You can find the source code for this update at:

Unreal Engine DevLog #17: Prototype UMG Menu Update 2 [Free Source Code]


The Prototype UMG Menu system is getting another update. Unlike the previous one, this is kind of a minor update focused on patching up some bugs and code optimizations. Keeping with the tradition established by Update 1, screenshots are provided to show the changes made to the code. This should help smooth out the transition to this update. Before we go to the matter at hand, here are the links to the previous posts and the thread in the Unreal Engine forums:

Unreal Engine DevLog #15: Basic Menu Interface using Unreal Motion Graphics

Unreal Engine DevLog #16: Prototype UMG Menu Update 1 [Free Source Code]

https://forums.unrealengine.com/showthread.php?63037-FREE-UMG-Menu-System-Prototype-Source-Code&p=274798#post274798

And here's a video demonstration of the menu system:


Changes in Update 2:

1) Fixed a bug that disabled removing pause menu through keyboard input.

2) Code and design optimizations for Scrollbar buttons in the video settings.

3) Supported resolutions now taken from the game instance class along with other default settings whenever needed. [Note: Using Rama's Victory plugin, you can get all supported resolutions and store it here if you don't want to use hard-coded default resolutions. I have tested it and it works smoothly]

Below listed are the changes to the different classes in detail:
  • Effects Quality Widget [Similar changes in AA Widget, Shadow Quality Widget, Textures Widget and Screen Resolution Widget]

  • Player Controller

  • In Game Actor

  • Video Options Screen Widget


Alright, so that covers all the changes made in this update. Here's the link to the updated source code in Git Hub:

https://github.com/Stormrage256/UMGMenuSystem

Unreal Engine DevLog #16: Prototype UMG Menu Update 1 [Free Source Code]


About a month back, I released the source code for my prototype UMG menu in GitHub. The menu was basically intended to be a prototype that I could use on all my projects from the get go. So once I got the menu system set up and running, I had not worked on it apart for a couple of minor bug fixes. Since I got some free time this week, I decided to improve the menu system and fix some issues with it that has been bugging for the past few weeks. The idea of this post is to provide some sort of documentation related to the changes that had been included in this first major update for the menu.

For those of you who haven't seen the previous update, here's a video demonstrating the menu system in action:
        



Over the past few weeks, I've noticed from the unreal engine forum thread that some people have actually started using it in their projects. Assuming that the people who have started using the menu system have already made changes to meet their requirements, I'm documenting the changes made for the 'Update 1' in the form of screenshots wherever the code has been modified or added to.  

First of all, here are the major changes in brief:

1. Added support for manual default visual settings.

2. Fixed a bug with scroll bar not collapsing when interacting with other buttons.

3. Visual settings now shown as literal text instead of numerical values in the default version.

4. Improved the code for maintaining persistent visual settings throughout the active instance of the game.

5. Fixed the disappearing loading screen bug in standalone and packaged versions.

And here's the list of known bugs,limitations and plans to fix them:

1. Widget spacing works properly only for 16:9 resolutions. This will be rectified in future updates to accommodate 16:10 and 4:3 resolutions as well.

2. Default visual settings can only be set manually at the moment as the 'Scalability Auto' function in UE4 doesn't provide any means to retrieve the changed setting. I've been assured by Epic that a feature request has been added for the same.

3. Support for changing Audio and Gameplay settings aren't included out of the box. Will be added in future updates.

4. Soundtrack starts playing before the main menu loads. Will be fixed when audio settings are added.

Below listed are the changes made to different classes in detail. Textual cues are used in screenshots to describe the changes. 
  • Game Instance Blueprint 


  • Main Menu Actor



  • Video Options Screen Widget






  • Shadow Quality Widget [Similar changes in Texture Quality Widget, AA Level Widget and Effects Quality Widget]



Alright, I think that represents all the changes made in this update. Here's the link to the source code in GitHub:

https://github.com/Stormrage256/UMGMenuSystem

If you have any doubts related to the menu system, feel free to contact me here or in the forums. If you notice any bug apart from the the ones I've specified above, please do let me know as I haven't had much time to test it.

With that we come to the end of this update. Meanwhile feel free to check out my Youtube channel for more of my UE4 experiments.

https://www.youtube.com/channel/UCzvzhcyARRwQZ3YDnrujnEA