DEVLOG #2

Devlog#2: 5/18/2026 - 5/23/2026 -SO. Yesterday I decided not to do development, and just rest, however I still wanted to play the game-like demo made thus far, and really mess around with the glide to really decide what I did or did not like about it, especially the rescue glide. Despite playing around with the variables, RescueUpSpeed, RescueLaunchSpeed, (variables that were suggested in the tutorial) and even the offset; it'd still launch me heavensward. So I tried clamping the vector before the launch node. This sort of worked, but then it made everything slow, and it didn't feel good anymore. It was reaching the approximate height that I wanted most of the time, but in a terrible way. So I removed the clamp and just lowered the speed to almost reflect the same product of the clamp, and I somewhat succeeded, but then it was also still slow; and not to mention, if I dropped too low I had to spam press glide and slowly "walk up" the stage till I got to safety, which definitely was NOT what you’d do in supervive; you'd just pop up to the same height every time no matter how low you were when you activated your glide. This is when I realized that I wasn't really putting in intentional number variables, I just kept plugging stuff in till it reached the height I wanted, but that was really hard to predict, and the inconsistent launching made it even harder. So then I plugged in a print node to see what heights I was actually reaching, and my Z-axis "high-score" for the rescue glide was around 50,000 on the z axis. However, my regular jump and glide would only get me between 550-600 on the axis regularly. So then I decided to see how exactly the launch node works: what do the numbers I plug into this node actually do for my character's location? So I hooked a keyboard event of X straight into a Launch node and started adjusting the vector numbers to see how it affected my Z-axis positioning for my character. It was predictable when I was standing still, but as soon as I jumped and then pressed X... Straight to heaven. And this is EXACTLY when it hit me. The Launch node is NOT setting my height. The vector numbers you're giving it is NOT telling it to make your character's position equal to whatever the vector numbers are inputted, because those are VELOCITY. That's why the RescueUpSpeed node controlled the height, because it was feeding the launch node velocity/momentum: "I want to go this fast, which will launch me this far." NEVER was it saying, "launch me to this coordinate exactly on the Z axis". So I was asking for the wrong thing. Launch is not easily predictable because it's about how fast you're going and how much velocity you want to be launched at. The vector nodes are just describing at which direction and what force to use. So then I stepped back and asked myself, "what am I actually asking the compiler to do? Right now, I want it to take me to a certain height no matter how far down I am." That's when I realized, that's not a launch node, that's a "set actor location" node; essentially the same logic as the dash (wasn’t mentioned in the dev log, but I worked on this in devlog week #1), but with a set Z axis location. So I still kept all the trace channel logic inside the rescue glide, but I changed the launch logic after it. Now it goes to custom event "Pop up", which sets the pop up start location using the get actors location node, and then sets the pop up end location using get actor location > break vector > make vector > changes the Z axis to 500 (because that's how high up I want them to be reset to), goes into a time line, updates characters location using the pop up start and end location, and then feeds the velocity in the function that was made that injects the "finished TL" data into the player movements velocity, and now it finally works! The glide feels great! 

-I created the event "burn out", which makes them vulnerable to getting "spiked", a mechanic that shoots the player to their death if they're in the air while taking damage that lasts until they refuel their glider. 

-In the new event, variable "IsBurnOut" is set to true, and material changes to black (material is set back to normal once fuel is back to 100 and burn out is set to false). 

-Then I added another new event: Spiked, a super core mechanic to supervive. 

-I made the Takes Damage function always lead to the "Spike" event, where it checks if IsBurnOut is true, and if it is, it then takes characters current location, and sets end location to -10000 (some arbitrary negative number), goes to a timeline, and then sets actor location. 

-and it works! FINALLY TIME TO ADDDDDD THE ABILITY KEEEEYYYYSSSSSSSSS!!HBUBEY!BUB! -I started remembering that when you fall, the camera doesn’t follow you, so I had to fix that. Just made it so the camera doesn’t follow when it comes to Z location. However, that made another problem. If the character goes too high, it still doesn’t follow you. So I had to create a branch for a situation that if you’re too high, then it will follow you. But then this made it so that once it would go high, it wouldn’t come back down. As soon as I realized that, I created a variable to inherit the cameras Z location at the start of begin play, and then it’d use that Z location to reset it back to normal height. The big thing I found out about here was VInterp To nodes and FInterp nodes that make vectors super smooth looking. I love it. -Last thing I added was the camera. It works, but it was via tutorial, and I’m tired right now, so I don’t really entirely understand how it works, so I’ll talk about it later. But it’s basically the same thing, but something about subtracting the cursor or whatever idk.

5/19/20

-Worked on the “sneak” mechanic and camera today. It was pretty easy, it’s essentially just setting two floats for spring arm length in the Camera pawn, and then plugging them into “Target” for FInter To node, and then using the spring arms target length arm component as “current”, both are based on ctrl pressed and release events.

-For my final bit of work, I started making UI Elements. It’s hard because I’m having to create what I think I’m gonna need, while being completely unsure of what I need. One thing I noticed was that Supervive characters all have super random kits. Shift is always a dash, R is the ultimate, but then everything else sort of seems up to what they wanted for the player. E can be random, Alt Click is kind of random and behavior can change, and then sometimes they have alternate abilities that don't even have control names, like “bash”. Once you play the character, I think it becomes intuitive, but it’s kind of weird how there wasn’t really a set standard of what keys everyone would have like most MOBAs. Gonna do UI tomorrow, hopefully everything goes well.

5/20/2026

-SUPER later start today, life things happened. Let's make today fast and easy. 5/21/2026 -Honestyl, yesterday was just not it, so I went to bed and decided to try again tomorrow.

-All the UI is in, everything is where it needs to be and looks how I want it to.

-The sizing system in UE widgets is weird, complex, and not super intuitive, but once you understand what to do it becomes easier; it’s just a pain in the butt is all. The only advice I can really give is to have it in your viewport already while working on it so that you can constantly be checking in on it; otherwise, you risk the possibility of thinking it looks good, adding it, and then realizing that all the sizing is off and you now have to go painstakingly though everything to resize it. I found out the hard way. I know there is a size box, but it doesn’t really work how you’d want it to.

-I finished up tying the health/mana/armor to the events of taking damage and “spending mana”. I actually don’t have “mana cost” incorporated into the base blueprint just yet, so it’s there for once I decide to add that. Doable, it’s just another thing to add to the list of things to do. But the UI actually makes it look Supervivy ish, so I’m excited to share it this coming Saturday with reddit. Also, to fix flying over the abyss and the character losing the ability to stare at the cursor, I made a giant block that blocks the trace channel, so now he’s always looking at the cursor. Everything is going good, but it does feel like everytime I advance with UI, I forget 50 other things. 5/23/2026

-I didn’t really write anything yesterday, although that was essentially the bulk of everything I’m finishing up with. After being able to update health, mana, armor, I went for cool downs. All of UI isn’t hard in the sense of understanding what math does what, or what data needs to be considered, or what a reference is actually saying. It’s hard in the sense of that it needs to be connected in the right locations, it’s INCREDIBLY tedious, and it’s super easy to mess up one reference and have everything going from working perfectly, to not working at all; which might be able to be said about more things, but I felt it to be way more evident for UI and their display functions.

-Cool downs were particularly hard because they had to utilize the event tick node, which I have been warned multiple times to use as little as possible, so it sort of made me cringe. I did more research as to how bad it is to use it, and from what I can find it really only gets bad when multiple actors or separate entities are using the tick node. Apparently CoolDown sort of ticks don’t matter as much? I guess we’ll see eventually. 

-I did see other people store even tick’s delta time as a variable to use elsewhere, but unless the execution wire was involved, it didn’t matter. The variable would end up just referencing whatever that delta time was when it was fired.

-It’s hard to say exactly where things connected, but conceptually speaking you’re creating functions inside the widgets that mainly just grab current and max (health, stamina, mana, armor) and then divide it, set current XYZ. However for cool downs, it gets a bit more complex. It’s the same thing, but you need to also include widget visibility when you want greyed out images and visible cool down timers. I think I’ll start uploading pictures to the doc, because otherwise trying to write every single step will be the end of me.

-The biggest win was definitely the floating health bar and glider stamina. The radial progress bar is actually a material, because why would that be a default? That’d be too easy! I’m happy it works, but I had to frankenstein the tutorials to make it work, so I’m not at full confidence with it. Confidence it will work, low confidence that it’s the best way of doing it. 

-I still don’t know if I want to do a level system, but I’ll consider it.

-Next goal post I want to focus on actually making a unique character, which will essentially be shrike, and character stats.

-Also started a trello board: https://trello.com/b/uzxpkXTP/superrevive