Corona-cation (Day 8)

Git Commit: None


    Today was cut short by other responsibilities but I was still able to start on a new enemy. This was the Plague Doctor for the medieval area. I wanted to do this enemy because it would be the first (and most likely easiest) enemy that would have multiple attacks. According to the current design doc these were an AOE and cone attack that would poison a player for some amount of time and a slash that would do immediate damage. 
    The base of the enemy was pretty simple with most of the same code being used from the basic melee enemy until the part where I had to implement the multiple attacks. The idea was that when the enemy goes to attack it would execute a service that would set a random attack from an enum. This randomness was supposed to be weighted according to the design doc with some attacks being more common than others. I decided that this feature can wait until I know it is possible for the rest of the system to work correctly. 
    I got the random attack selection working, as well as the AOE attack. This attack will find all players within range by using a very useful node called SphereOverlapActors so I don't have to test the distance to each player. After it gets all players it needs to poison them. I am still working out how I want this to happen though.
One option I have come up with is adding a custom event on the player base class, but I feel that wouldn't be the best. My other option was to make a poison component that I would attach to the player that could handle all damage calculations. The problem with this is that I can't figure out how to do that in blueprint while I know it's possible in C++. We'll see.

    Other than the top-down game, I have been trying to compile the UE source code. This will be a long process as my internet isn't the greatest and it took just about two hours just to clone the repo from git. Hopefully it will be worth it.

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