Work Log

Git Commit: afb9a0e "Added ScarabSwarm enemy" Added ScarabSwarm enemy:     What I thought would be a simple enemy turned out to take up all my time today. The basic idea was that it would be an enemy that would just be a hitbox that once overlapped would do damage every interval of time. That part wasn't so bad, it was the movement that took the longest.     I started off thinking that the actor itself would be static and the actual swarm would be a particle effect that would give the illusion of movement. Turns out I was wrong and the designers said that the entire thing "moves in erratic patterns". So I had to convert the actor to a pawn then add an AI controller, blackboard, behavior tree, etc. then tell it to pick a random point close to around it and move there. The problem was, it didn't move. I struggled for a while until I noticed that I had forgotten the most important thing that I had always taken for granted when making human type enemi

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

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

Git Commit: None     Today I made a realization; I still don't understand some fundamental ideas of networking in UE4.     I started out the day with little direction as the designers haven't updated any of the design documents or given me a task to work on after our meeting on monday. This turned out to be a blessing in disguise as it meant I found a huge bug with the core of the game. So since I don't necessarily have a deadline to meet I decided I would try to implement the reviving system I thought about yesterday. I started this out by making sure the healing from the cleric worked so that later I could use that as a reliable point of gaining health in case something went wrong with the new system.      But as I tested the heal aura I found it wasn't doing anything. I checked the blueprint and didn't see any logical error so I went to the output log to dig up errors or warnings. And indeed I found some. The first one that directly told me what was ha

Git Commit: 8e3012c "Fixed players damaging enemies, Added the ability for enemies to damage players, Added SmoothSync to players and enemies" Fixed players damaging enemies:     This was a very odd issue that I found today. Yesterday I had only tested the damage system in the DungeonTest level which I did not realize had a different gamemode and therefore an entirely different server-client system. So today when I tested in the Island level the damage system didn't work. I was able to eventually figure out that the problem had to do with the client trying to set the enemy's health which should only be done by the server. To remedy this I added a custom event that would execute essentially the same code just on the server instead.  Added the ability for enemies to damage players:     Just a simple recreation of what we did for the creative jam game. When the enemy is close to the player it will wait an amount of time, attack with a given damage value

Git Commit: 9e45555 "Enabled plugins, Added enemy health bar, Finalized cleric" Enabled plugins:     I just enabled the SmoothSync plugin for later use as well as the SurfaceFootstepSystem plugin. I also disabled the VR plugins because it was annoying having SteamVR open every time I opened the editor.  Added enemy health bar:     More substantial than enabling plugins was the health bar that I made for the enemies. This health bar is connected to a socket on the mesh so hopefully it will look better by moving relative to the animating mesh. The major feature of the bar though was that it would only show when the player is looking at the enemy (I still have yet to disable this through walls) and will rotate to always face the individual players. Finalized cleric:     After I made the health bar I decided now would be a good time to make sure that the players can do damage and kill the enemies correctly. I started out with the shar

Git Commit: f59f36b    "Added main menu Settings, Added class selection, Changed hosting" Added main menu settings:     The main menu settings screen is not even close to complete but this is where it starts. The only working settings currently are the color deficiency options. The reason for this was that Unreal's built in implementation of color blind settings was super simple. With one 'Set Color Vision Deficiency Type' node doing all the heavy lifting; taking in every input and changing accordingly. The color palette on the side was just to make sure it was working. Additionally, the 'Display Subtitles' checkbox is not functional and I am not really sure right now how that will interact with the cutscenes. In the future I plan to add other more basic settings like display options, sound, inputs, and the like.  Added class selection and Changed hosting:     This section took by far the longest to get working and I ran into two m