Corona-cation (Day 3)

Git Commit: 6646905

"Added revive system, Minor fixes and changes"

Added revive system: 

    Building off yesterday I figured out what was the problem. All of the characters do have owning connections but only the server can access them. Once I figured that out it seemed like a no-brainer but I eventually figured out how to make the heal aura work again. The only change I had to make was to have the actual actor be spawned from the server. This is what that looks like:


After that I got on to doing the thing I initially set out to do; the revive system. The hardest part of this was, without a doubt, figuring out the architecture. Trying to wrap my head around what scope was needed for everything, where code will be executed, and at the same time trying to make it as general as possible was quite difficult. I started out thinking that I wanted to do it with an interface that would do the same thing on both the reviver and the revivee player. I eventually figured out that I ran into the same problem as with the heal aura. The reviver was trying to heal the other player but because of the multiplayer model the client cannot set a replicated variable (health). Because of this I would need to call a server function, but the revive event was happening on both players involved in the revive so you would get conflicting information. It was becoming a nightmare. 
    I eventually scrapped the interface in favor of calling one event running on the server from the player doing the reviving. This event would just set the necessary variables on both players (mainly ReviveTime which will be used for UI later). This is the final system:


    With the revive system I also needed to rework some old code. This was to make sure the players couldn't attack, move, etc. when reviving. This was just really time consuming and I'm sure there's a better way to do it than what I did. I just put ifs before all of these events making sure that certain booleans were correct. 


Minor fixes and changes:

    Very descriptive, I know. Most of these were just removing annoying print strings, fixing numerical values, cleaning up blueprints, and just making the overall experience better. The biggest of these small fixes though was a bug I found with the class select that I thought I had squashed long ago. This bug being that if a player (player2) joined the session after another player (player1) had already chosen a class and was in game, player2 would see player1's class as available. This was simply fixed by adding a delay to the update.

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