Corona-cation (Day 7)

Git Commit: b6e0596

"Changed first person UI, Fixed enemy pathfinding"


Changed first person UI:

    The simple change of today had to do with the first person UI, namely the health bar. Our UI artist finished the first edition of the health bar and wanted to see how it looked in-game as to adjust anything necessary before he went on to make more. The first thing we noticed was that the .png file that was exported had really bug padding around the edges that made the scale wonky which really screwed with positioning and getting clean values. Right now, it looks like this:


Fixed enemy pathfinding:

    When I loaded up the project today I was prepared to work on the archer enemy. Before starting that though I wanted to make sure everything else worked up to that point. I added a standard melee character to the level to make sure they play nice. They did, but I noticed that the melee character would jump up to the statue's pedestal, and, given enough time, so would the scarab swarm. This was a problem as we didn't want just any old enemy being able to jump up there. 
    I started out on the nav link trying to find a way to restrict its use to only one class or something, but that didn't work. Google was also not helpful in the searches I made (Side note: throughout this whole process documentation was staggeringly unhelpful, only really restating what you could already see. As a bonus, the only somewhat helpful google search came when I new the lingo and only confirmed what I had already figured out on my own). So I set off on my own to try to figure out what would allow only the statues to use the nav link.
    The first thing I saw was that the link had a section that said 'Supported Agents: all'. I thought I would just be able to change some agent type but searching everywhere I found nothing. The next thing I saw was an 'Enabled Area Class' and this was the start of the right path. I figured out that I could change this value and even make my own nav area class. So I did made one, NavArea_StoneStatue, and set the nav link to use it. That alone was not enough though. I now had to find a way to explicitly tell the statue to use that new nav-area. 
    After more messing around in the editor I found nav filters. This allowed me to add different nav areas to it which, I assumed, would make the AI it controlled use them. It was not that simple though. Through a little trial and error I figured out that the new nav filter was working I just hadn't applied it in the right way. See, when it worked I was using the scarab swarm which uses a MoveTo node in blueprint whereas the other enemies use behavior trees. The behavior tree 'move to' (used on the other enemies) also has an area for nav filters but, here's the kicker: it just doesn't work. No matter if I restarted the editor, made a new filter, whatever, it just would not take effect. 
    So cool, now I can't use the built in nodes and have to make my own. Honestly though, it wasn't that hard, I just made a new task that would take in the same parameters as the built in node plus a nav filter and, ta-da works first try. The last thing that I had to do was check a checkbox that would make non-statue enemies unable to use nav areas marked as NavArea_StoneStatue. 

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