Corona-cation (Day 4)

Git Commit: 976a232

"Added first person HUD"


Added first person HUD:

    Still no updates on the main design doc, so today I have decided to finally tackle UI. For the main reason that it was getting really annoying having to do print strings and 'watch this value' to see if my code was working the way I thought it was.
    I started out with health. Simple enough as it was consistent across all players. My goal was to have a single widget blueprint that would work across all players regardless of their class. Just hiding and showing certain elements that were relevant to the class that the player is. After health though things got a whole lot more complicated. I wanted to have:
  • Mana bar (cleric only)
  • Ammo (sharpshooter only)
  • Main attack cooldown indicator (different timings per class)
  • Special attack cooldown (same story)
  • Revive indicator (while writing this I realized I forgot to add this one)
The mana bar was similar to the health bar just class specific; no big deal. The sharpshooter ammo, same thing just in text form for now. Where things got difficult was the elements that had to follow a time. The way that I had been doing attacks like these that needed a cooldown was just to delay for x seconds then open a do once command. This completely screwed me when I needed to get the value of the remaining delayed time for the UI. The only other way I could think to do it was the way it was done for the creative jam. This was to have a custom timeline for each attack that on update would change a float value that could then be used to make the UI change. I greatly disliked this though as it was cumbersome to change timings and was unnecessarily large in the blueprint editor. 
    After googling around for a bit I found the answer to my problem; "SetTimerByFunctionName". It was absolutely perfect, allowing me to execute functions on any object after a set duration. On top of that, if you have a reference to the timer you can get the time elapsed or remaining which was exactly what I needed for the UI.
    The only challenge now was to refactor all attacks and anything using delays to work with the new timer system. This was a pain but well worth now that it's done. Also during this refactor I made primary and special attacks have more consistent functionality across the classes but that's less important. The current widget looks like this:

Comments

Post a Comment

Popular posts from this blog

Polishing the Foundation

Image
     This sprint was relatively uneventful; mainly cleaning up the existing foundational elements of the game (the first person character and spell component) and continuing to improve the necessary elements of the game like the pause screen. Player Character & Spells      The improvements to the player character come in two parts; the ability to have, use, and change spells, as well as interaction via an interface. Both of theses are as simple as I could make them. Utilizing inheritance from USpellBase using the spells is only really a single line, and changing out the spells we can use the NewObject factory to make a new spell very simply. FirstPersonCharacter.h FirstPersonCharacter.cpp      As for the interaction interface, it only consists of two functions right now, one to fire an interaction event and one to check if the object can be interacted with. This second function is used mainly to show UI on the player's screen like...
Read more

Progress Update #13

Image
  Niagara Asteroids in UE4     These past few days I have continued work on asteroids. Only that now I have ditched instanced static meshes in favor of getting my hands on the new-ish Niagara particle system.  Learning Niagara     I have decided that since this is an entirely new subsystem of the engine I would do everything in blueprint first, then transition everything to C++ when I knew it was working reliably. Additionally, because Niagara is still relatively new, the official documentation is sparse if existent at all. So with most tutorials at this time geared towards blueprint implementation, starting in blueprint will give me the highest likelihood of finding a solution to any problems I may come across. The Niagara Workflow     The first thing I learned about Niagara is that the workflow has changed significantly from what cascade was. Where in cascade (to my limited knowledge) you worked in one particle system where e...
Read more

A New Chapter

Image
     This week has presented the biggest change probably since the release of Mini Solar System; I was offered a full-time position as a junior programmer at Studio 369 which I was happy to accept. I start on Monday and I couldn't be more excited to work with the team there! However, this did mean though that my priorities shifted quite instantaneously. I went from working full-time on "RPG_Game" to preparing for this new job. This mainly meant getting up to speed on networking as that is the one area of Unreal Engine I feel I have a lack of knowledge in (I'm already proficient in UI, AI, gameplay, materials, and general backend work), and since 369's specialty is networking I figured I would come prepared. I did do a little work on "RPG_Game" but it was minimal just to tie up some loose ends. Unreal's Multiplayer Framework      As explained by the Unreal Engine documentation, "multiplayer programming [is] inherently more complex than programmin...
Read more